Re: so what? Re: Debian development modem
ok for me.
> So, in detail:
> Every three months (fixed date) we copy the current `unstable' into
> `frozen'. At this point `stable', `frozen' and `unstable' should all
> stay interoperable both in source and binary form.
alternative :
seperate place for new uploads and unstable, but well known packages.
package developers do uploads. they always go to the place for new packages.
"quality keepers" can promote a package from "the new place" to
"unstable". a sample guideline could be : this package has been in use for 10
days, and nobody complained about it, and there was no new upload of the
package.
this "unstable" will be frozen every 3 months.
also an old version shouldn't be thrown away automaticaly.
the additional step might save us some problems with "new xx is in, but new
libxx isn't", or "people found out that it's broken, but there was no new
upload since that".
the current testing scheme is :
a) one developer (or two or three) test a package
b) then all 300 developers test the package, because it's in unstable.
it would realy realy nice to have some group in the middle with ca. 30 people
or so.
too much time is spend by debian developers, because they need to be relative
up to date, but they get some broken packages and fail because of that.
> Bugfixes must be applied to frozen, and important ones to stable too.
> After one or two months of beta frozen should be stable enough to
> release.
not directly to stable. IMO the hamm/ archive and the cdroms should never
be changed after release. instead we should have an errate directory,
with a detailed explenation for every updated package (available as text and
html, so sgml could be used).
> We also need to make automatic building a real possibility.
till end of juli i'm busy but then i can work on this. maybe earlier,
but don't count on that.
andreas
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: