Re: Debian Etch Stable.
Alexis Sukrieh <sukria@sukria.net> writes:
> Anthony Towns a écrit :
>> Personally, I'd say that now would be the time for any anti-payment
>> people to say "we can do this better, and look, we'll prove it", and
>> make up their own target date for etch, and demonstrate how much energy
>> and effort can be mustered just by having a good idea and good people
>> and putting them together to get a goal achieved.
Er, this makes little sense to me. Much of the hard work for the etch
release has now been done. Comparing actions taken at this stage to
actions taken at an earlier stage doesn't make a tremendous amount of
sense. I don't think you'd be able to prove anything interesting either
way with that.
> 1. Paying Debian Developers seems to make (some of) them completely
> humorless, everything is taken a hundred percent seriously, as if the
> dollars in their pockets droped their fun hability. That's a pitty.
Huh, I didn't notice that. Maybe I'm normally humorless anyway. :)
> 2. You can pay DDs to boost up the wonderful project that is Debian,
> but you definitely cannot blame other DDs for not being as much involved
> as you'd like. Remember that a vast majority of us are people who
> contribute in their free time, most of them doing the best they can
> given their free time.
Yup. I would hope that everyone realizes this. Also, one thing that
should be totally clear, if it wasn't already, is that the very most that
anyone would ever be able to do with monetary contributions to Debian is
perhaps provide additional resources in very targetted areas, not even
fund a complete core task. There's a ton of unfunded release work going
on, just like always.
> 3. You seem to forget that the Debian Social Contract cleary defines
> two priorities for DDs: The users and the free software. I personnaly
> don't read "Our priority is to release quickly". To me releasing when
> "it's ready" is clearly better than setting up some
> "pretty-useful-etch-ignore" tags and stuff like that so the release can
> be out in time. Did we ever spoke about the overall quality of the
> resulting boosted-release?
etch feels to me (having been running it for quite a while now) as a bit
more release-ready than sarge was at this point. (Note that I cannot
comment on d-i at all; I only use the installer when I bootstrap a
completely new piece of personal equipment. I don't even use it at work,
since we use FAI for everything.)
Once you reach a particular size in a free software project, you can't
*purely* release when it's bug-free or you'll never release. I've seen
that time and time again in free software projects. Some of them die
because of that sort of perfectionism. Others devolve into an endless
cycle of betas and CVS snapshots. There are quite a few of those packaged
in Debian.
As soon as your project reaches a size where you will never be able to fix
all of the bugs (and it doesn't have to be very large for that), releasing
is *always* a tradeoff between fixing more bugs and calling it good enough
and kicking it out the door. *Both* actions help users -- fixing bugs
helps, as does establishing a new stable baseline.
It will *never* be completely ready.
> 4. Given that, be aware that I don't blame neither Andi nor Steve for
> trying the experiment, but I hope they can understand that beyond
> themselves, the whole experiment changed the game. That matters, that
> triggers reactions, and to me that is definitely understandable.
Yes, I think it's important to factor into the judgement of how this
experiment went the fact that it changes the game. It's not *only* a
question of how much work the people paid managed to get done.
So, we missed the release deadline. I'm not horribly surprised; paying
two people to work on it is helpful but not enough to actually release,
and I'm not sure that the schedule is that variable through adding more
manpower. Paying two people to work on the release full-time probably
sped up the release by a bit, though. Now, I'm curious whether the
funders behind dunc-tank (who are the people who actually get to make this
decision -- it's their private money, unaffiliated with the project, and
they can spend it however they want) felt like what was achieved was worth
the price.
Personally, I would go back to my feeling at the start of this whole
conversation and say that release management, while an important thing for
the project as a whole, is not an obvious thing to spend money on because
it's a repeating need. We need infrastructural improvements there, not a
regular infusion of manpower, because the latter doesn't help with the
scaling problem. I think dunc-tank would get more bang for its buck by
funding specific targetted development in large areas that would make
Debian better, such as dpkg 2.0, or a replacement init system with better
dependency management and faster boot times, or some sort of comprehensive
work on the shared library dependency problem that would make library
transitions less painful. I think that sort of specific contribution from
a third-party funding source would also be less controversial, leading to
less time lost in debate.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: