Re: All candidates: Development and technical issues and challenges
On 20/03/13 at 01:15 -0400, Michael Gilbert wrote:
> On Tue, Mar 19, 2013 at 3:14 AM, Lucas Nussbaum wrote:
> >> Maybe we could discriminate on the package's priorities. For example,
> >> about a third of the 49 packages *really* blocking the release (not
> >> waiting for a transition) are from "extra". Only 5 bugs affect
> >> required, important or standard packages. We could focus on those and
> >> tell the "extra packages" to hurry up or be shipped with packages that
> >> will need to be fixed in a point release... or simply removed.
> > That's something I already commented on in
> > https://lists.debian.org/debian-vote/2013/03/msg00020.html:
> > Another possible area of improvement is the focusing on the more
> > important RC bugs. One way to achieve that would be to remove as many
> > leaf/not-so-popular packages as possible at the start of the freeze.
> > If they get fixed, they could get back in.
> Even the suggestion of a testing removal can evoke negative feelings
> for those affected (sometimes from those on the sidelines too). A
> recent example:
> Do you have any thoughts on addressing the social aspect of this
> approach? In actuality, a testing removal is really not a big deal
> since the package can come right back once the RC bug is fixed. Even
> so, some see removals as a kind of judgement on themselves as
> maintainer. What can be said or done to qualm the fear and anxiety?
It is the release team's role to decide what's inside testing, and I
think that it's important to respect that.
However, I can understand that reaction:
> I also really dislike your recent habit of making discussions hard to
> follow by opening new bugs. Please keep things in one place so everyone
> can follow along.
(even if the tone is very wrong)
Maybe we should generalize the use of the BTS' "affects" feature so that
such bugs are properly "linked" to the original package?