Re: Finding an improved release process.
"Miquel van Smoorenburg" <miquels@cistron.nl> writes:
> In article <[🔎] 20041128231206.GA8405@quux.local>,
> Graham Wilson <graham@mknod.org> wrote:
>>On Mon, Nov 29, 2004 at 09:44:05AM +1100, Matthew Palmer wrote:
>>> On Sun, Nov 28, 2004 at 01:25:49PM +0100, Cesar Martinez Izquierdo wrote:
>>> > Yes, we have more packages now, but we also have more developers to
>>deal with
>>> > them. And we always have a big pool of people that wish to become
>>DD, so man
>>> > power is not the problem, in my opinion.
>>>
>>> Manpower almost certainly isn't the problem with archive size, and I don't
>>> think it really ever has been. The problem is, primarily, the increasing
>>> complexity and size of the dependency tree, and the number and complexity of
>>> interactions between packages in the archive. Keeping that all straight can
>>> be very, very tricky -- and it gets increasingly tricky as the archive
>>> grows.
>>
>>Granted, the large archive size and the complex package dependency
>>changes make creating a new stable distribution a difficult process;
>>however, we seem to be managing well enough at this point. The release
>>blocker is, at this point, the lack of build daemons for some
>>architectures.
>
> If there's no working buildd for the m68k architecture, or the
> installer isn't ready for all m68k systems, it holds up the
> release even though only 20 people use it. Which is part of the
> problem - with so few users, who's going to fix that ?
I wager to say m68k is the one arch with the best buildd support by a
mile. The building takes a while but the responce time of the staff
beats every other arch.
There are other issues with the buildds that are completly unrelated
to the speed of the cpus involved or the number of users.
> OTOH, when sarge is finally released it will be without AMD64
> because that architecture couldn't be added in time- which was
> before September 2004.
The real (stated) reason why amd64 couldn't (and still can't) be added
to sid (and subsequently sarge) is mirror space. It is realy sad that
a few missing GB harddisk space do such a disservice to Debians users.
> I'm strongly in favor of releasing only for the 2 or 3 most
> popular architectures and whatever other arches happen to
> be ready. If one isn't ready to be released, release without it.
> That arch can always be synced at a point release, if the users
> and developers of that architecture care enough.
Look into the release effort and help out for a while. You will
probably notice quite quick that removing 5 archs will overall make
little to no difference to the problems involved.
I believe it would make it even worse to track bug severities since
you have to decide for each RC bug if it applies to a release
candidate or just seccond class architectures.
By the way, the most popular architectures are (according to popcon):
i386 : 5211
amd64 : 237
powerpc : 90
sparc : 56
alpha : 28
The 2nd most popular arch isn't going to be released with sarge.
MfG
Goswin
Reply to: