[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: