[Python-Dev] Python 2.6.5

R. David Murray rdmurray at bitdance.com
Wed Feb 10 22:47:05 CET 2010


On Wed, 10 Feb 2010 13:57:31 +0200, anatoly techtonik <techtonik at gmail.com> wrote:
> On Wed, Feb 10, 2010 at 8:25 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> >
> > Besides, as Barry said, classifying a bug as blocker is also a good way
> > to attract some attention on it. Other classifications, even "critical",
> > don't have the same effect.
> 
> Unfortunately, not many people have privilege to change bug properties
> to attract attention to the issues. For example, this patch -
> http://bugs.python.org/issue7582 is ready to be committed, it is
> trivial, not a release blocker, but would be nice be released. How to
> make it evident if nobody except committers is able to add any
> keywords to the issue? I suspect that even committers do not receive
> this privilege automatically.

FYI, committers do (or at least should) have full privileges on
the tracker.  Other people can also get full privileges on the tracker
without being committers, generally by participating helpfully in issue
review and issue triage.

We give out tracker privileges more easily than commit privileges, but
we don't give them out willy nilly.  So the concern someone expressed
about issues getting set to release blocker "just" to attract attention
isn't an issue in practice, it seems to me.  If a committer or triage
person sets an issue to release blocker it should mean that they think
the release manager should make a decision about that issue before the
next release.  That decision may well be that it shouldn't be a blocker.

I think that the logic here is that it is all well and good if the release
manager has the time to review all critical issues pre-release, but since
they may not, those with tracker privs can help sort through the clutter
by marking as release blockers those issues that the release manager (and
others who are helping out) really *should* think about before the release
goes out the door.  I think that's what Barry was asking for when he said
"feel free to mark things as release blockers".

Of course there should be far fewer things getting set to release
blocker for a maintenance release than for a new release even under
this approach, and Martin's criteria are the ones that should be used
by the release manager when deciding whether to *leave* an issue marked
as a release blocker.

But this is just my perception of the process, and I'm willing to work
with whatever framework the community and release manager wants :)

Anatoly, if you want particular issues to get attention, start reviewing
issues on the tracker and helping move them along by commenting, and if
your work is helpful you'll get noticed and offered tracker privs and be
able to help even more.  Related to this is the offer that Martin made
and I have seconded:  if someone wants attention paid to a particular
issue, review five others and let Martin and/or I know and we'll review
the issue you care about.

--
R. David Murray                                      www.bitdance.com


More information about the Python-Dev mailing list