Noel J. Bergman wrote:
All I want is some discipline about what goes into a release, and then I'll
be a happy camper again. Stop telling me about releasing trunk, and start
talking about how we'll put together a safe, stable, reliable distribution
with all of the new features we want, and my doctor (who measures my blood
pressure) will be a much happier man.
I think I will use again the terms "release from trunk", "release based
on trunk", "based on branch 2.3" or something similar. I always used
that terms and I will use this again. I can try being more specific
every time, but now you know that when I say "releasing from trunk" I
don't mean "tag trunk one random day and make an official release" but I
mean "branch trunk at a decided day, start consolidation on the branch".
Trunk is not consistent quality. I just want to hear that we will have some
discipline about what we release. Today, I wouldn't trust trunk to pass gas
much less handle my e-mail. But whatever we pull from trunk to make the
next major release WILL be stable and reliable before we release it.
I have a lot of confidence in what we have currently in trunk: Norman is
already using it on a live site, and I'm planning to switch to trunk
soon (I just wanted to test some day more the 2.3.0 final).
Btw consolidation belongs to the branch: now we should concentrate on
the features without breaking the whole thing.
These are the issues I raised with Stefano, and he agrees with the concern
about being stable and safe. When he talks about releasing from trunk, it
is a language issue. It means one thing to me, but is another in his mind.
He's much more specific about what he feels should be copied from trunk when
we plan the release, and on those issues we are more in agreement.
To quote him: "I want to make it clear that I simply want to refactor James
so that it will be pluggable, and that the default should be backward
compatible."
I want to be sure you've not misunderstood me again:
I talked about "refactor James so that it will be pluggable" in a long
context. This is my main goal, but not the only goal for the next-major.
If you want to publish the whole chat we had on skype, feel free to do that.
About being more specific about what I feel should be copied from trunk
i'm a bit lost. My proposed plan is:
- branch trunk on Dec2006/Jan2007 (so everything there by that day will
be copied in the branch)
- start consolidation of the branch for the release (ETA 2-3 months later)
Consolidation means:
- fixing bugs
- changing default configurations
- ensure we have the best backward compatibility
- if needed disable portion of code we decide are not ready to be
released (e.g: IMAP)
If you have problems with a specific feature being included in trunk or
you have problem with a specific commit please let's talk about it, but
I don't want to start a commit-by-commit discussion to decide what to
bring in the release: and this is the sense of the "release based on
trunk" that I described in the currently running vote.
We also talked about discussions. He wants to know why when he posts so
many e-mails, he gets no reply. I tried to explain that one e-mail gets
replies, 100 e-mails get none. When there is so much volume, people feel
that they need to read more, and they don't feel that they have time to
reply to everything at once, so they reply to little if anything. I
reminded him about Bernd asking him to please try to say things in fewer
words because it was too much to read. I suggested that we try to pick a
high priority list of things to discuss first, and work through the list
rather than try all things at once.
I don't have a solution to this: we are moving much faster than in the
last 2 years, and this needs a lot more activity on the list.
It takes me a lot of time to do that, also, but I feel this is my duty
as PMC member: I don't have a proposal to fix this.
Danny is proposing a status file: let's see if this helps or it will be
another outdated wiki page.
Going to the specific, I would like to have a "next-minor" with some
fast-fail features there (like jspf and other filters) plus other minor
things
Agreed. And I want to incorporate Norman's patch for per-IP connection
limiting.
Until now everyone voted "+0 to next-minor" and everyone "+1 to
next-major". If you still believe in a next-minor please make it more
clear what you will include and maybe you will find more supporters.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
