Re: How to define a release architecture
Hello,
> The Vancouver proposals satisfy all of these, potentially at the cost of
> removing some architectures from the set released by Debian. If we want
> to avoid that cost, can we come up with another proposal that solves the
> same problems in a way that satisfies the release team?
There was a proposal first made by Marc 'HE' Brockschmidt [1] and than
(independently) made by me [2] where we proposed to freeze testing even
if some architectures are not ready yet, and use
testing-proposed-updates to make the architectures release ready later.
As I have elaborated in [2] this approach has the potential to solve the
points addressed in the Vancoover proposal. As these proposals where
nearly not discussed and especially there were no objections/arguments
against it I want to bring up this proposal again as it might have been
lost in the noise because the posts were located in the original "Bits
(Nybbles?)..." thread.
For the sake of discussion I have attached my proposal (it is a little
more detailed than Marcs) at the end of this message.
If this is total rubbish please tell me why and refrain from using the
rough tone that has become so common in this list recently. As most
developers I would like to keep this place a friendly one and I want to
enjoy reading the list instead of bristling about it.
Greetings Ben
[1] http://lists.debian.org/debian-devel/2005/03/msg01372.html
[2] http://lists.debian.org/debian-devel/2005/03/msg01647.html
--- my original post ---
Hello,
as a non-DD I am not so tuned into the Debian project as many of you
are. However I would like to make a proposal about the "hot topic".
As I have noticed, most people ojecting against dropping architecures
feared for the coherence of the systems. They wanted to be able to have
the *same* debian on all there machines and wanted security support and
all this stuff for *all* archs.
The persons in favour for dropping archs noticed that they delayed the
release of sarge and caused a lot of extra work.
So I have given this some thought and come with a proposal quite simple:
Why not freeze the archive at a given time and make a release for all
architectures ready until then. As this code is frozen, the porters can
continue to work on the frozen codebase where only patches are allowed
which are needed fix the packages for the different architectures. This
seems to be the same the security team currently does. The ported
architectures would become available as soon as a new revision is
released (of course this should happen as soon as a new arch has caught
up).
This would allow a fast release and keep the burden of the arch support
mainly with the porters who would be responsible for making there arch
ready for release. It would allow to support each archs as long as there
are sufficient developers available who can keep up with porting. The
security infrastructure can be shared by all archs. Porters may even
decide to skip one release if they are not up to it - this is not that
bad if the release cylcle is around 12 month.
This is the rough plan, now I will list some details or afterthought
(skip them if you are totally annoyed by this proposal anyway):
* as there already is, the possibility to exclude packages from
archs is always possible making debian a little less uniform -
but why should debian fix the issues not properly adressed by
the upstream author anyways - if he does not care about the bugs
he receives from the debian package it should simply not be
relased for this arch
* there is no way to *force* the developers to accept the porters
patches or care for their concerns any more, but come on -
developers are not a community of assholes who want to keep your
architectures out of debian
* it is even possible to release with a subset of the packages
(only the important ones and increase each step
* People missing their arch in the first release will likely
complain, but the other option would have been to delay all the
other archs until this arch keeps up (which might indeed have
happened faster if the whole release was delayed because
everyone would press the obstacles - but I think that is unfair
against the archs which are release ready...)
* I intentionally disregarded the problem of the mirror size and
buildd because the mirror problem received a lot of good
suggestions and I believe the buildd problem could be solved
with additional hardware and if not architectures not up to date
could simply be considered release ready and will have to wait
another round...
Of course there is much to think about and to fine tune but it is a
proposal trying to combine the request of all users.
This might be totally unrealistic as I said I have no deep insight into
the debian architecture but _I_ think it is a good proposal.
Please let me know what you think about this proposal!
Greetings Ben
PS. it is only now that I've noted that a similar proposal was made at
http://lists.debian.org/debian-devel/2005/03/msg01372.html, so you can
consider this a more elaborate version of this suggestion. And please
forgive me if there are others who have made this proposal, its hard to
keep up with this thread
Reply to: