Re: Release management
Joseph Carter wrote:
> I would suggest refrigeration for the moment. Traditionally when we
> freeze we tell people not to upload new versions of software---not even
> new versions of stable software---unless important bugs are fixed by
> doing so. What I'd like to see is NEW software not being automatically
> accepted for potato. This to keep new packages from making it harder to
> get the bug count down.
Hmm, I am not happy with such an approach, because it leaves no place
for new packages to go. During a freeze, we can be selective about
what goes into frozen, because everything else can go to unstable.
Also, when I look at the release-critical bugs list, I do not
see many new packages. Or did you mean the total bug count?
Indeed, [archive maintainer hat] most new packages have a number
of bugs when they are first uploaded, and I've wondered if I should
be more eager to reject them.
> Hopefully this will help people concentrate on fixing bugs.
Will it? I think the ensuing flame war would be distracting :-)
(We've had this discussion before on this list, and I saw a lot
of disagreement.)
I may have misunderstood you. Did you mean actually freezing,
with a new unstable and all, and accepting updates to existing
packages in frozen automatically? That might work, if dinstall
ignores the "Distribution" header in the .changes file. Otherwise,
updates will effectively only go to the new unstable because they
are usually uploaded to "unstable".
> For an example of the problem, look at afterstep. [...]
>
> In such cases developers should be able to NMU these packages without
> worrying about complaints of package hijacking. Although in the case of
> afterstep, hijacking it doesn't seem like such a bad idea...
Maybe I should explain the Secret Master Plan inherent in my first plan :-)
The mails sent to each maintainer will specifically ask them if they
would mind an NMU to fix the release-critical bugs. Josip will keep
track of when each bug was asked about, and what the replies were.
Maintainers that have gone missing will not reply, and this information
will go appear in the release-critical bugs summary, thus making it a
handy database for the QA folks.
As for afterstep... maybe we should write out a policy for taking over
a package. It seems to me that if you have queried the maintainer a
number of times, and have allowed sufficient time for responses, and
have asked about him and the package on debian-devel, then it is
reasonable to take over the package. (I also think it is reasonable
in a lot of other cases, but this should be a minimum we can all
agree on :-)
Richard Braakman
Reply to: