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

Re: Changes in release goals for Wheezy



Hi Scott

On 08/02/2011 05:39 AM, Scott Kitterman wrote:
> As the drafter of the proposed release goal for Python [1],  I will confess 
> some surprise when I read on d-d-a [2] that this had been dropped for Wheezy 
> without being involved any discussion or at least notification.   Regardless, 
> it's the release team's call, so it's gone.

It was marked not suitable as a release goal. I understood that to mean
that transitions are tracked anyway, without the need to be a release goal.

> I'm somewhat unsure how to proceed.

Why would it being named a release goal or not need to change expectations?

> There is a fair bit of work to get python2.7 as the default and only python 
> for Wheezy.  There is both a transition bug [3] and a usertag [4] (yes, I know 
> some consolidation is needed) and additional testing needed.  Without a 
> release goal, which would permit developers interested in Python in Debian 
> treat these bugs as if they were RC and to NMU to work towards this goal, the 
> only options I see are:

Hmm, I thought there would also be a python3?

Anyway there are about 25 packages blocking the transition. As it is
clear that python2.7 will become the default and only python2 (unless
anyone is questioning this??!), it would make sense to promote these
bugs to RC already even if python2.6 is currently still the default.

> a.  Wait until maintainers address these issues

Never a good idea to wait for others to do the work. We are all
volunteers, though if one has time and energy it's way better to try to
help (binNMUs, patches, contacting upstream...) instead of just waiting.

> b.  Upload python-defaults making python2.7 default so these become true RC 
> bugs.

I would first have a look at what would be the real impact if none of
the blocking bugs would get resolved: What would it mean to remove all
of the ones that are not fixed and their reverse dependencies from testing?

> I'm also anticipating that developers (all of whom have limited time 
> available) will reasonably read this decision as meaning fixing these bugs is a 
> lower priority (in fact, I think that instead of Important, they should 
> probably be Wishlist now).

I fail to see why it would be demoted as a transition as well? So I
don't see any reason why the bugs should have a lower priority than
important.

> I would appreciate knowing how the release team expects this to work?  I asked 
> about this on Niels Thykier suggested I write an email instead.

Above I've given my understanding of how it should work. It would be
good if someone could confirm or comment.

Cheers

Luk


Reply to: