james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: Managing Changes
Date Fri, 02 Jun 2006 16:30:01 GMT
Noel J. Bergman wrote:
>> I thought that having a 2.3 branch and being committed to fix any bug
>> found on that branch would have been enough.
> Yes, that's great.  For that release.  What about the release after that?
> When would you like it, what would you expect in it, and how do you propose
> that we get there?  Allowing us to manage that sort of change is the purpose
> for this discussion.

I don't know and I don't care. I think our codebase should be always 
almost ready to be released. I'd like to think that if we want to 
release something at a given time we simply have to branch the current 
trunk or the trunk from a week before (not months before) and start the 
betas from there.

This is not my general approach to this problem, or a general best 
practice. This is my approach to *this* specific scenario:
James codebase, today, with the current committers, with the current 

>> Hmm i also saw the trunk as developing tree. So i have no problems with
>> big changes in the trunk if they make sense.
> I agree, but again with the caveat that big changes do mean more risk, more
> testing, and generally speaking, more time before release if we are serious
> about wanting releases to be stable and reliable.

Imho James needs BIG or even GREAT changes. We are late. We are 
inadequate for our own goals.

> So a related question would be how should the release after v2.3 be made?
> Copy v2.3 to v2.4, and merge in pieces from trunk as necessary?  For each
> release?  Or do we want to try to keep trunk more stable (not unchanging,
> just making sure that we have confidence in what is in it), and work on the
> more pervasive and/or riskier changes in a branch before merging them back
> in?

I would apply major changes to trunk because I think that release 
branches are made for the stability.
So we apply everything that could be in James goals and someone have 
been willing to code in our trunk. One day someone will wake up saying 
we need a 2.4 release and we'll do the same we did for 2.3: branch and 
start the release process.

> The solution, as I expect we all agree, is NOT to have a lot of branches, or
> at least not long-lived ones.


> As I said, this isn't about what you are doing, it is about how how we want
> to set ourselves up for managing change.  So that we *can* making releases
> in the kind of timeframe that I believe we all want to have them.  Because
> this is not a new problem, nor one that is caused by you.  We have run into
> this problem before.

In fact I feel part of the solution, not of the problem. Maybe this is 
not a shared idea, or maybe this has been a misunderstanding.

> Danny started making changes in trunk that in the end not even Danny wanted.
> Meanwhile, all of the Avalon changes were made in trunk.  And other work was
> happening in trunk from other developers.  And for a long time we spent a
> lot of effort for a while trying to copy changes between trunk and the v2
> branch.  In the end, that cost us a *lot* of time between releases.

I understood this, but this is not happening now and not near to happen. 
We have a 2.3 branch that will get only bugfixes and we have trunk.
Nothing to merge but bugfixes.

> One approach might be that when we want to make a substantial change, we
> either discuss it first and get people to agree on making the proposed
> change directly in trunk; or we might create a branch, do the work, get a
> consensus, and merge the work into trunk.  This approach might be
> particilarly effective when the changes are both substantial *and*
> relatively isolated, e.g., the recent changes on fetchmail.

As I already said plenty of times I have a big -1 for discussions: this 
is not a general consideration, but I simply saw that it is not working 
for James.

I don't think that is good to create a branch for a 2 hours work. If I 
create a branch for each of this refactorings we will end up with 
hundreds of temporary branches. I don't think this will help.

>> how many mailing list message per line of code changed we want to require.
> Again, depends upon what changes are being made.  When we replace the
> spooler, I would expect discussion.  Fixing a bug in a mailet, less
> discussion.  Total architecture of some components, more discussion.

Imho discussion is not working here. Each one has his own ideas, limited 
time, and limited knowledge of the specific code problem. I understood 
this many months ago and I tried with the CTR approach: discussion on 
concrete things has been better but too often people say "we should have 
discussed this before" and similar thing, with no technical issues, no 
vetoes and no conclusions for the discussion.

Please open the mailing list archives and look how many thread 
"last-replies" have been written by me asking something and how many 
times I left a question unanswered.

The result is that most code changes I did for the 2.3 release have not 
been discussed. Maybe you liked them, or maybe you had no time to review 
them after my commits, but I think the result is good.

I've introduces really major and critical changes in the code that is 
going to be released as 2.3 (see the MimeMessageCopyOnWriteProxy and the 
refactoring of MimeMessageWrapper). Imho it is the most problematic (but 
needed) change I did there. We will know if I improved or decreased the 
quality only when much more people will start testing our 2.3 releases 
(we know for sure that it fixed a major bug and that it probably improve 
the performances but even if I added few unittests we can't be sure if 
people don't test it). I don't understand why 5 months ago I thought I 
deserved the trust to make that critical changes and now I can't keep 
working that way.

Imho we have not enough developer power to previously define release 
dates associated with features and roadmaps.

I think the best we can do is agree on goals (features we want in James) 
and try to coordinate the community achieving one of more of the goals.

We can also define a time between new medium/major releases. Imho 5-8 
months is a good amount and a first goal since the last one have been 
more than 2 years.

Imho this is the best we can hope to achieve: we have no money to 
enforce a specific roadmap (features <=> dates)


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message