Re: Debian Re-organization proposals (was: Re: so what?)
Hi,
>>"Guy" == Guy Maor <maor@ece.utexas.edu> writes:
Guy> "David Engel " <david@ods.com> writes:
>> Ian has yet to reply.
Guy> Why does Ian's role as leader enter into it? Propose a motion as to
Guy> how you think releases should work. We don't have to wait to start
Guy> hashing out a consensus.
I agree. I think we can come to a proposal, at least, without
involving the Project Leader Role in all this.
To get the ball rolling, I think I like the idea Guy
presented: Have a continuosly updated set of stable and unstable
packages (maybe keep the last N versions of packages - but that is a
digression).
Packages are uploaded to the unstable pool. After a while,
when at least the maintainer has been using them for a while, and
there are no reported bugs, the package may be promoted to the
``stable'' distribution.
Every once in a while, the stable set is copied off
("Frozen"), tested, and released as a nerw version. Since there is
always a release ready set of packages, presumably one may release at
regular intervals.
There is another advantage to this: packages mature and reach
stability at a diffrent schedule than Debian releases, and this
method promotes *packages* from unstable to stable on their schedule,
rather than when We decide to ship a release.
This is predicated on the assumption that maintainers are
going to exercise judgement in promoting a package to stable; things
break down (but no worse than the current state) if people, either in
error, or impatience, promote packages to stable.
I vote we keep the previous stable version of a package in
safe storage until the newly promoted package has had time to mature
and perhaps be tested.
There are problems with this approach -- what about shared
libraries? packages in stable have to be compiled with libraries that
are stable too. And if the developer is tracking unstable, that means
the package may not actually be tested that well with stable
libraries.
So far, this has been done by having maintainers stick to
unstable for development, and stay with frozen until the hard freeze,
so everything in frozen has been compiled with frozen libraries.
If we go with a continuously varying pool of packages, with
both a stable and unstable set being updated, either we autocompile
packages on a known stable machine, so that the packages have the
correct libraries, while developers track unstable.
One may even say that one compiles on a stable machine, and
tests locally for a couple of days before asking the package to be
promoted into stable.
This is getting way too complicated.
manoj
--
So long as the least desire of a man for women has not been
eradicated, he is fettered in mind, like a sucking calf to its
mother. 284
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: