Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 04/01/13 05:48, Gunnar Wolf wrote:
Uoti Urpala dijo [Mon, Apr 01, 2013 at 05:12:46AM +0300]:
No, that's not what I'm saying. But I think the release team is
primarily responsible for the policies that harm the work other
maintainers do on unstable.
A release must not be the only goal for package maintainers, and IMO it
should not be an overriding one either. Distributions that make latest
software available are necessary for free software development. It's not
responsible for Debian to say "development of new software should happen
on a distro like Arch, we'll just use the results". And Debian is too
big to be just for people that care about releases only
We Debian Developers might be backwards-thinking sometimes, and the
release process is surely not perfect. It is, however, one thing we
have agreed upon (although we keep working on it and trying to perfect
it) over many years.
It might be bad manners for me to put it this way: Your mail, although
it points out several issues (we are aware of them in the most obvious
ways: We work inside them!), lacks the knowledge of what has happened
and led to Debian to choose the procedures it has chosen.
Do you want to impact Debian's way of working? Great! We are always
short on manpower. But, often, getting *really* involved will explain
you some situations better than a long rant on a mailing list.
Please, do get involved in Debian. Do help us make things better. Do
point out at what is broken. You can even become part of Wheezy+1's
I think that the fact that unstable is frozen 30% of the time annoys the
hell out of several old Debian Developers^Members as well, so it's not
exactly fair to blame the new guy for being new for this. If anything, I
think new people's views can be really helpful sometimes, as the
old-timers may not be able to see our flaws at all. In this case, I
think Uoti's views have some merit, if you ignore and move past the
(unfair IMHO too) attack on the release team :)
Personally, I wouldn't blame anyone specifically, much less a
hard-working team of people that have to put up with everyone's crap for
months (case in point: an R transition two weeks before the release).
However, I do believe that our release process is flawed in some ways
and we need to course-correct. I think there are things we could do to
fix this which are orthogonal to fixing RC bugs faster.
This is something that we need a project-wide discussion for and not
something a release team alone can (easily) decide. Last time the
release team tried to affect large changes to the release process
(time-based freezes) alone, it didn't go too well anyway :)
I don't think the time for this discussion is now, so I'll restrain
myself from saying more. The release is near, and there's going to be
plenty of time until the next freeze :)