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

Discussion: granting discretion to release team (was: Call for seconds: DFSG violations in Lenny)

Given that this is supposed to be the discussion period, I'd like to share 
my standpoint regarding one option.

Andreas Barth wrote:
> | We as Developers at large continue to trust our release team to follow
> | all these goals, and therefor encourage them to continue making
> | case-by-case-decisions as they consider fit, and if necessary
> | authorize these decisions.

I am extremely hesitant when it comes to this option. In fact, I think 
it's going to end up below "Further discussion" on my ballot.

The main reason for that is that IMO the main reason that we're having 
this discussion is that the firmware question was handled rather badly by 
the current release team (RT). They themselves bear a heavy responsi-
bility especially for the way the discussion started (IMO things have now 
settled down into a fairly reasonable discussion and voting process).

We've already had two releases where this was an issue and in both cases 
it was decided by a GR. Why should the current release team think they 
could handle it differently?
Just compare the way this started (by someone noticing that RC bugs had 
been tagged lenny-ignore without _any_ prior public discussion) to the 
way it was handled by the previous release team. For Etch, Steve Langasek 
*as RM* opened the discussion on debian-vote with this mail:


In summary: the previous RT anticipated on the resistance against such 
waivers, opened a discussion with the project and proposed a resolution 
to allow the release to go forward. This resulted in a very controlled 
vote (well, except for ...) and in the end the permission of the project 
was obtained without any real bloodshed.

It's no secret that I've not been happy with the way the current RT has 
handled a number of things, including for example removals from testing. 
They seem to think they are mandated a large degree of freedom to beat 
the archive into shape for the release, no matter the cost and the 
frustration this may cause developers. IMO this is fundamentally wrong.

Important decisions regarding the release, such as waiving structural RC 
issues, the support of architectures and the removal of packages should 
be made in discussion with the project at large and *not* by a select 
team. However careful they are it is impossible that they can correctly 
weigh all arguments all by themselves, even if only because they are just 
not aware of all the facts (for which of course they cannot be blamed 
given the size and diversity of the project).

It is especially wrong because the way it is done is largely silent. Only 
very few people will actually notice the removal of a package or the 
addition of a tag to a BR when those happen. Most developers will only 
notice later on, for example when things break.

Supporting this option on the ballot would effectively grant the RT broad 
powers and only increase the kind of problems we've seen in this release 

So, although I completely disagree with Robert Milan on his viewpoints 
regarding firmware, I do thank him for bringing the matter to the 
attention of the project.


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: