james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincenzo Gianferrari Pini <vincenzo.gianferrarip...@praxis.it>
Subject Re: AW: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Date Wed, 22 Nov 2006 10:35:56 GMT
Hi everybody,

Juergen said it exactly: what Stefano and Norman are doing is just proactively judging what
they think could and should be fixed/developed for "next-major", and documenting it through
jira labels, without any change to our subversion repository. All the committers are free
to have - issue by issue - a different opinion and re-change the labels.

When, sooner or later, "next-major" will be considered mature to be finalized, an SVN branching
will be voted and done and a version number will voted and applied, and the jira labels renamed
accordingly. Same for "next-minor".

I think that we all can and should stay calm, peaceful, optimistic and polite.

Vincenzo


J├╝rgen Hoffmann wrote:
> Hi Bernd,
>
> >From my viewpoint, all he is trying to do is to define a rough road map for
> himself with the tools he has at hand.
>
> And if trunk == next-major, where is the difference? Why is everyone so touchy
> about the term?
>
> I think what he is doing is fine, you guys voted about what you would like to
> work on ("next-major"). All he is doing is that he is tagging certain
> jira-issues, that they are fixed in the next-major, which is really just a
> label inside jira.
>
> So that after the discussion and vote for a branch is over, and after the
> discussion/vote about a next version number is over, just rename the label.
>
> That saves a lot of work. So I really see nothing bad in doing so.
>
> My 2 cents
>
> Juergen
>
> -----Urspr├╝ngliche Nachricht-----
> Von: Bernd Fondermann [mailto:bernd.fondermann@googlemail.com] 
> Gesendet: Dienstag, 21. November 2006 11:56
> An: James Developers List
> Betreff: Re: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
>
> Stefano,
>
> 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
> wrong?
>
> 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
> tommorrow.
>
>   
>> 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
> appropriate?
> 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.
>
>   Bernd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
> !EXCUBATOR:1,4562db6353071639226496!
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>   


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


Mime
View raw message