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

Re: Uploads to experimental instead of unstable

On Thu, 11 Dec 2008 12:43:03 +0100
"Sandro Tosi" <morph@debian.org> wrote:

> Hello Neil,
> On Thu, Dec 11, 2008 at 11:08, Neil Williams <codehelp@debian.org>
> wrote:
> > Unstable is also "closed" so that other packages can migrate more
> > easily. Uploads not related to Lenny should go into experimental.
> > New
> can you point to ufficial documentation stating this? (ok, it's a
> joke, I know there's none) While it's a wise suggestions, it's not a
> law and it's not strictly to be followed. The way you expressed it
> seems like "do not ever upload to unstable while we are in freeze"
> which is, of course, not true.

I did put "should" instead of "must" but I do believe that unstable
should be off-limits to the majority of uploads from mentors during
this very late stage of the freeze. Refs to guidance in the other mail.

I should have started a new thread really, I wasn't referring to this
specific package just that the subject came up in this thread.

> > with this upload then upload to experimental, not unstable (or don't
> > upload until after Lenny is released).
> so are you saying that it was time wasted? I don't think so, and I
> think this upload can go into unstable without problems.

An upload to experimental is not a waste - I haven't looked at this
particular package but, as I said, I have lots of uploads that I simply
will not make until Lenny is released and a couple that I will be
making to experimental soon.
> > It's a bit more complicated than that - 'testing-proposed-updates'
> > is for times when unstable already has a newer version of the
> > package that will not migrate and an RC bug is found in the older
> > version in testing. The preferred method to fix RC bugs is to be
> > able to upload to unstable and migrate with permission from the
> > release team. Uploading other cruft to unstable gets in the way of
> > that process.
> Cruft? so doing a QA upload trying to get the package in a good shape
> is "cruft" for you? nice judgment :)

Cruft as in unrelated to the task of actually releasing Lenny. It
wouldn't be cruft if it went into experimental. It wouldn't be cruft if
the same upload was made after the Lenny release. During the freeze
and targeted at unstable, it's cruft.

> Of course, while we are trying to "stabilize" the distribution in
> testing, we should try to fix RC bugs opened (avoiding to introduce
> new, ok) but that doesn't mean we have to stop all other activities
> waiting for lenny to be released. 

It would make things easier to release Lenny if all (or very
nearly all) activities in unstable that were unrelated to the release
*were* actually stopped. Lenny is my priority and it saddens me that
other maintainers and DD's don't seem to feel the same way. "Release
when it's ready" is not an excuse to let issues go unfixed ad
infinitum. We do need to release eventually and the last 60 bugs are
always the hardest to fix, so need the most attention from the highest
number of people. (People not spending time debating crufty packages
that have nothing to do with the release.)

> Consider the situation where a guy
> want help but doesn't have the skill to fix the opened RC bugs: is he
> not "allowed" to package new tools, do qa uploads or update his own
> pkgs?

experimental - why is that such a bad thing? Why do people react so
badly to a recommendation to upload to experimental? It's just a name,
a label. It doesn't have to mean that the package is experimental, it
simply means that it isn't suitable for what is currently happening in
unstable (which, in case anyone is still in doubt, is the final
preparations for the Lenny release). Everyone has to take account of
transitions and blocks in unstable between releases, the release freeze
itself is just another issue to consider with regard to unstable.
Unstable isn't 100% available every single day between freezes, there
are constant issues that mean that uploads need to be delayed or put
into experimental. That's why we have experimental.

> > The more differences there are between unstable and testing at this
> > time, the harder it can be to actually fix the bugs which then means
> > that the entire freeze goes on for longer. Ignoring this problem
> > doesn't make it go away - uploading random junk to unstable actually
> > prolongs the problem for everyone else. Stop it, please.
> Please stop be so rude to newcomer maintainers. It won't help you nor
> the guy willing to help: after such a reply I'll think twice the next
> time I want to help Debian. and we do not want this!

Some see it as rude, I do not intend to come across as rude but I
don't hide from the truth either. There is a lot of rubbish in mentors
and it doesn't hurt to be honest about the lack of quality in RFS
emails and packages in general across mentors. People complain that
their packages are not being sponsored and then complain when the
reasons are explained - that the RFS is crass or the package is just
borked. Not telling someone the real problem in an effort "just to be
nice to people" is selling them short.

As for whether we want it or not, I'm quite confident that Debian does
not actually want a proportion of what is available via mentors. It can
be hard to sift the wheat from the chaff. Some maintainers give me the
impression that they think they are doing Debian a favour and that
mentors is just a rubber-stamping operation. What Debian does need is
more people fixing bugs - packaging can assist in acquiring the
knowledge to fix bugs but, as in my sponsoring requirements, I'm not
interested in maintainers who do not want to join Debian. I'm not an
upload-robot for upstream developers who want a package in Debian as a
"badge of honour".

The average quality of RFS emails and packages in mentors does need to
be raised but, IMHO, some of the packages will never make the grade. It
doesn't do anyone any favours to pretend otherwise. Mentors is not a
mere queue, it is a review process and sometimes (quite a lot of the
time it seems), the request fails the review and simply has to be
dropped. Yes, maybe that has been a waste of time but it's better than
adding a crufty package to Debian and wasting even more time during the
next release freeze.


Neil Williams

Attachment: pgp1iwSNB8ul0.pgp
Description: PGP signature

Reply to: