Hi Andreas!
You wrote:
> As Steve wrote
> | The reality is that keeping eleven
> | architectures in a releasable state has been a major source of work for
> | the release team, the d-i team, and the kernel team over the past year;
> | not to mention the time spent by the DSA/buildd admins and the security
> | team.
> Considering the experience of the release team, the number of different
> architectures were _one_ part responsible for release delays - not the only
> one, and the others need also to be solved.
OK, but I doubt that dropping architectures is the only way of solving
this. Wouldn't it be possible for example to expand the release team?
Or by better collaboration between porters and the release team? Or by
changing or enhancing the infrastructure?
I find it a bit hard to believe that Debian isn't able to support 11
architectures while for example FreeBSD and NetBSD seem to manage fine.
> For example, the more architectures are included the longer the migration
> testing script takes. We are already at the limit currently (and also
> have out-of-memory issues from time to time). For example, currently we
> restrict the number of some hints to only 5 per day to keep up the
> scripts. Also, the udebs are not taken into account, which requires more
> manual intervention. With a lower number of release architecture, we can
> and will improve our scripts.
So to me the obvious thing to do seems to improve the scalability of the
testing scripts rather than dropping lots of architectures.
To summarize, I have the feeling that the conclusion that the number of
supported architectures is the real underlying problem, was made too
fast. As far as I've been able to gather from the other thread, two
problems were mentioned that need to be solved to speed op the releases:
1. not enough manpower/too much work for the ftp-masters, release team,
security team;
2. mirror bandwidth/space problems;
and you've just told about this one:
3. testing scripts scalability problems.
It seems to me that these are the real problems that need to be solved,
and it's not obvious to me that dropping 8 architectures is the way to
do it. For example, as the number of packages keep growing, the same
problems will resurface --- even if we have lots less architextures to
take care off --- and those will have to be solved in some other, more
fundamental way.
--
Kind regards,
+--------------------------------------------------------------------+
| Bas Zoetekouw | GPG key: 0644fab7 |
|----------------------------| Fingerprint: c1f5 f24c d514 3fec 8bf6 |
| bas@o2w.nl, bas@debian.org | a2b1 2bae e41f 0644 fab7 |
+--------------------------------------------------------------------+
Attachment:
signature.asc
Description: Digital signature