james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Fondermann" <bernd.fonderm...@googlemail.com>
Subject Re: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Date Tue, 21 Nov 2006 10:56:06 GMT

Again I find it very disturbing how you manage this "next-major" thing.

We just made a release, have massive changes in the codebase, are
weeks (if not months) away from a branch and you are suggesting what
is or is not in the next release. All this by applying an artificial
abstract label (BTW, what is the follow-up label, "next-major 2.0"?)
to code which _is_ on /trunk/ and not on a /branch/.
When I noticed all the JIRA logs on the weekend I was really flatted.
No time to respond to that until now, and really I still don't feel
like answering. Anyway.

This all happens in the light of severe reservations by some
committers concerning the branching/releasing thing as you put it and
a release numbering vote pending on general@.

On 11/21/06, Stefano Bagnara <apache@bago.org> wrote:
> Noel J. Bergman wrote:
> >> Fix Version/s: Next Major (was: Trunk)
> >
> > Please stop doing this and messing up the JIRA issues.
> I kept updated JIRA for the last year and more following this schema.
> We agreed to have sequential branches and not diverging brnaches so it
> make real sense to use that method, imho.

I don`t know of any current release branch in svn other than 2.3.x.
can you point me to it?

> If you can't leave with me updating JIRA and mantaining this schema
> bring your own reason.

by saying that, are you suggesting you can do with JIRA whatever you
want? this is not a co-operative reasoning.

> As we did with 2.3 and trunk we agreed that everything we could have
> written for 2.3 would have been applied first in trunk and then
> backported. This way there is no issue applied to 2.3 that will not be
> in trunk.

+1. that was when we had a release branch for 2.3.0.

> Using only 2.3 as fix version will make a much more clean
> roadmap/changelog and will make us understand better the current scenario.

don't understand that one, sorry.

> I said I would have operated this way more than 1 year ago, if we want
> to change this.

you changed the way you operate. everyone else did not move.

>  > trunk is real.  next_major is nothing.
> Next-major is the only real roadmap we currently have: it has proposal,
> status update and discussions. And also a REAL VOTE!

please don't confuse the voting outcome with your personal
comprehension of what the vote might justify you to do. the vote is
not a blank cheque to storm away.
let us work on trunk in the way the vote is suggesting and talk about
branching and releasing when this is due.

there is lots of code added/changed and this is a very good thing. all
is progressing fine. we are in the coding and refactoring phase of the
release cycle. we partially skipped the planning phase, because it was
obscured by stupid pseudo-roadmap discussions. but we are not not
feature-finalizing, not branching, not final-testing, not RCing. am I

only about half a year ago you said things like "I can live without a
release, I don't care for releasing". Now I am under the impression
you would like to push a second release out of the door not after

> On the other side I still have to see the roadmap for next-minor if we
> want to talk about nothing and real...

By saying this you are trying to put pressure on people who are - from
your view - not getting enough things done. Do you think this is
Do you think we should all work at your pace to have a place here? Do
you measure merit in terms of lines of code per day or JIRA changes
per hour?

>  > It has no existance except in your mind so far.
> False. False. False. If any other PMC think this I will add more
> explanation. No time for another answer to similar sentence again.
>  > Who knows what will be in it?  We have branched nothing.
> There are clear vote, discussion, status update about this.
> And in the last message there is also an estimate date for the VOTE to
> start the branch.

But this date is not now.

>  > But in the meantime, the fix IS in trunk.
> I don't agree. And as I think I'm the one that keep JIRA cleaned I think
> we should try to understand my needs.
> We created Next-Minor and Next-Major in JIRA for this very purpose, if
> we don't use this way, what should we use them for??
>  > You can add next_major to things if/when the fix actually
>  > IS in next_major.
> >
> >       --- Noel
> Next-Major currently is in svn trunk folder. This is what we VOTED.

trunk will become next-major at an appropriate point in time. that is
what I have voted.
at that point in time we should also have a more expressive label for it.
"next major" is an artificial term which was introduced to circumvent
discussions about the next release numbering which at this time was
absolutely too early to discuss.


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

View raw message