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
community.
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.
+1
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)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
