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

Re: where do NEW packages go?



On Sun, May 19, 2002 at 12:40:54PM +0900, Junichi Uekawa wrote:
> Try GNU/Hurd.
> This is Debian.
> Debian is going to be released. 
> Release time is an "emergency", where people in Debian
> are required to be concentrated on releasing something useful.
> 
> Please get a clue.

I was going to ignore the "this is release time" issue, but it has been
repeated several times now, so I think it is appropriate to remind that this
is the first time a release ever had such an effect on the whole of Debian.

I was personally not too much interested in the past Debian releases, but was
more interested in developing Debian further, rather than stabilizing it and
hammering it together for a release.  It was easy for me to do this, because
the people working on the release could do so in the "frozen" distribution,
and the people working on the next release could do it in the "unstable"
distribution.  This was not without problems if you had to release a package
only for frozen, but anyway, that's how it was done.  There was a clear cut
where unstable was virtually copied into frozen and that was very much like
a branch in CVS.  After that, everything in unstable could hardly affect
frozen and vice-versa.  If you are used to CVS you will know that a branch
is very useful to split development (in the release branch, you maintain
stability, and in the HEAD branch you continue the unstable development).

This is the first release to use the "testing" mechanism with propagation of
individual packages from "unstable" to "testing".  According to aj this made
his job easier, but it is not without problems either.  The old problem of
releasing a package only for one branch still seems to have been
worsened.  I have heard that people don't upload new versions of packages
into unstable in case the testing version needs a bug fix, so it seems that
uploading only for testing seems to be quite hard.  I was even discouraged
to file bugs that were not critical for the woody release because maintainers
could misunderstood this as a request to upload a fixed package to unstable,
which then would be propagated to testing (destabilizing it) or stick in
unstable and prevent future updates to the version in testing in case a
release critical bug appeared.  This is how I understood it, and I am sorry
if I got some detail wrong.

When the release comes nearer, there are less and less people able to help
with it, because the problems become more and more localised to some
selected individuals.  For example, I can not help with setting up an
rbuilder for security updates.   I guess several hundred people in Debian
are with me on this.  This is probably not the very only thing to do, but
you get the idea.  Maybe this is a point where the release process can be
improved, to allow, as it used to be before, a more asynchronous development
process, which allows everyone to go at the speed they can rather than to
force everybody to go at the same speed.

See also the brief subthread starting at
http://lists.debian.org/debian-policy/2002/debian-policy-200205/msg00095.html

Thanks,
Marcus



-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de


-- 
To UNSUBSCRIBE, email to debian-hurd-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: