Tobias Ringström <firstname.lastname@example.org> writes:
> There are two reasons why I did not "take the lead and produce a
> release", the first being that I have only one vote. I thought my
> email would make people start voting, but it didn't work. The second
> reason is much harder to describe. I really honestly did not think I
> had the mandate to initiate a release without the consent from the
> long time developers. From where I come it's common to get wide
> acceptance in the group before proceeding, so when I heard nothing
> from people I expected to have an opinon I did not know what to do.
Voting is a very rare last resort. We use voting for two things:
1. For resolving disputes when we could not consense.
2. For choosing which changes to put in an upcoming release.
(1) hardly ever happens, like, maybe two or three times in the entire
history of this project. (2) is a normal part of the release process,
of course, but it's irrelevant here, since your question is "How do we
decide *whether* to do a release?" not "What should go into a release
once we've decided to do it?"
So, the first thing you should do is: forget about voting. That's not
how we do things, if we can avoid it :-).
On to the real issue: How do we decide whether to make 1.1.1/1.0.9
Answer: you say
"This regression is so important that I am going to make these
releases unless a full committer vetoes it. Any help is welcome.
I'm willing to discuss alternatives to this strategy, as long as
such discussions are constructive and not mere delaying tactics.
But one way or another, we've got to get a fix out for this bug
Now, can you imagine someone vetoing that :-)? Maybe some people
would register objections, or ask that you go a bit more slowly or
something. Such reactions should be discussed of course, but the
point is to start out from a stance of "This is important to me, and I
am willing to do what it takes to make it happen." That way, you get
the momentum on your side. Most people will get out of your way, or
even help you, once they see a clear intent to act. Don't worry that
you are somehow usurping a right reserved to long-time developers. If
someone has a real problem with it, they'll use their veto. (But I
highly doubt that would happen, since you would be volunteering to do
the work, and we're not talking about a permanent, controversial code
change or something.)
Contrast the above strategy with this one:
"I really think this bug is important enough to warrant a new
release. Does everyone agree with me? Let's make a release."
That's a good way to have a nice conversation, but not a good way to
start momentum toward *actually making* a new release.
It's also a caricature of what you wrote, of course. Please forgive
my oversimplification. I'm just trying to make the point as clear as
Don't think of yourself as somehow "junior" in this project. You've
been fixing a helluva lot more bugs than I have lately, so please
assume that you have as much right to initiate a release process as I
do. Or as Ben Reser does. Or Brane. Or Greg Hudson. Or... you get
the idea :-).
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Oct 12 03:32:19 2004