You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Stefano Bagnara (JIRA)" <se...@james.apache.org> on 2006/11/20 18:49:06 UTC
[jira] Updated: (JAMES-663) sendmail.py crashes on line "from_addr
= os.environ['USER'] + '@' + socket.getfqdn()"
[ http://issues.apache.org/jira/browse/JAMES-663?page=all ]
Stefano Bagnara updated JAMES-663:
----------------------------------
Fix Version/s: Next Major
(was: Trunk)
> sendmail.py crashes on line "from_addr = os.environ['USER'] + '@' + socket.getfqdn()"
> -------------------------------------------------------------------------------------
>
> Key: JAMES-663
> URL: http://issues.apache.org/jira/browse/JAMES-663
> Project: James
> Issue Type: Bug
> Affects Versions: 2.3.0rc5
> Environment: Debian Linux, Python 2.3.5, "Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)"
> Reporter: Stephan Sann
> Assigned To: Noel J. Bergman
> Priority: Critical
> Fix For: Next Major
>
>
> This line in sendmail.py:
> from_addr = os.environ['USER'] + '@' + socket.getfqdn()
> causes my mail-delivery to crash:
> <---snip--->
> Traceback (most recent call last):
> File "/usr/sbin/sendmail", line 126, in ?
> main(sys.argv)
> File "/usr/sbin/sendmail", line 77, in main
> from_addr = os.environ['USER'] + '@' + socket.getfqdn()
> File "/usr/lib/python2.3/UserDict.py", line 19, in __getitem__
> def __getitem__(self, key): return self.data[key]
> KeyError: 'USER'
> </---snip--->
> I think it's an permission-thing, but didn't went any further.
> I just changed it to
> from_addr = "postmaster@localhost"
> (since the sender is pased by "-f") and now it works.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Posted by Bernd Fondermann <be...@googlemail.com>.
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 <ap...@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
AW: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Posted by Jürgen Hoffmann <jh...@byteaction.de>.
Hi Noel,
Noel J. Bergman [mailto:noel@devtech.com] wrote:
Now, let's consider next-major. As far as I know, we agree that the code in trunk will branch to be next-major. BUT, we also agree that there is code in trunk that may not survive the pruning. For example, perhaps none of the IMAP stuff survives to ship in next-major. We decide that in order to have a release in some timeframe, everything else is stable enough, but not certain other parts. Those issues would be resolved in trunk, but *not* resolved in next-major. Do you understand now why I am making this point?
[JH>] If after the vote/discussion for the next-major feature set, there is such a case, we remove the label again. Where is the Problem?
Kind regards
Juergen
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
AW: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Posted by Jürgen Hoffmann <jh...@byteaction.de>.
Hi Noel,
you do not get the point. All he is doing is summing up things he wants to be
seen within next-major. It is a Summary of Features, which anyone with jira
access can and should change. Then after time, a discussion is started
probably sounding like this...
Guys, there is a feature-set that would be great to have in next-major. Please
look at it, and say what you think. Then another feature might be added or
dropped. I think this is a good thing. The leaves room for discussion before
the vote for the next release, to have a group of people vote about a feature
set, and once settled, branch and do release preparing from then on. Don't you
think?
Kind regards
Juergen
-----Ursprüngliche Nachricht-----
Von: Noel J. Bergman [mailto:noel@devtech.com]
Gesendet: Mittwoch, 22. November 2006 16:41
An: James Developers List
Betreff: RE: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Jürgen Hoffmann wrote:
> All he is doing is that he is tagging certain jira-issues,
> that they are fixed in the next-major
Well, that is the thing. They may or may not be. What there ARE closed in
is trunk. I don't really care if they are listed against next-major, but
when we actually have code for next-major (remember: trunk is copied, then
PRUNED to become next-major), it may turn out that they are not resolved in
next-major at all.
All that I asked him to do was stop removing trunk as a label, since that IS
where the issue is resolved.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
!EXCUBATOR:1,45646fc353071734920388!
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: AW: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
+1
Vincenzo
Jürgen Hoffmann wrote:
> Hi guys,
>
> sorry if my last 2 E-Mails were shot before reading all Mails, but I am on a
> GPRS Link at the moment, and using it is really a PITA.
>
> Anyways, just to sum it up. It seems we all have the same view now, and can
> agree with consent. Everyone is fine with what Stefano is doing, if he labels
> issues both with "next-major" AND "trunk" correct?
>
> Kind regards
>
> Juergen
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
AW: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Posted by Jürgen Hoffmann <jh...@byteaction.de>.
Hi guys,
sorry if my last 2 E-Mails were shot before reading all Mails, but I am on a
GPRS Link at the moment, and using it is really a PITA.
Anyways, just to sum it up. It seems we all have the same view now, and can
agree with consent. Everyone is fine with what Stefano is doing, if he labels
issues both with "next-major" AND "trunk" correct?
Kind regards
Juergen
-----Ursprüngliche Nachricht-----
Von: Jürgen Hoffmann [mailto:jh@byteaction.de]
Gesendet: Donnerstag, 23. November 2006 00:55
An: 'James Developers List'
Betreff: AW: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Hi Noel,
you do not get the point. All he is doing is summing up things he wants to be
seen within next-major. It is a Summary of Features, which anyone with jira
access can and should change. Then after time, a discussion is started
probably sounding like this...
Guys, there is a feature-set that would be great to have in next-major. Please
look at it, and say what you think. Then another feature might be added or
dropped. I think this is a good thing. The leaves room for discussion before
the vote for the next release, to have a group of people vote about a feature
set, and once settled, branch and do release preparing from then on. Don't you
think?
Kind regards
Juergen
-----Ursprüngliche Nachricht-----
Von: Noel J. Bergman [mailto:noel@devtech.com]
Gesendet: Mittwoch, 22. November 2006 16:41
An: James Developers List
Betreff: RE: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Jürgen Hoffmann wrote:
> All he is doing is that he is tagging certain jira-issues,
> that they are fixed in the next-major
Well, that is the thing. They may or may not be. What there ARE closed in
is trunk. I don't really care if they are listed against next-major, but
when we actually have code for next-major (remember: trunk is copied, then
PRUNED to become next-major), it may turn out that they are not resolved in
next-major at all.
All that I asked him to do was stop removing trunk as a label, since that IS
where the issue is resolved.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
!EXCUBATOR:1,45646fc353071734920388!
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
!EXCUBATOR:1,4564e37053071653268718!
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Posted by Bernd Fondermann <be...@googlemail.com>.
On 11/22/06, Jürgen Hoffmann <jh...@byteaction.de> 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.
"for himself"?
>
> And if trunk == next-major, where is the difference?
The difference is, that TRUNK is existing in subversion and is the
place where all the commits go ATM. "Next-major" is a JIRA label and
if somebody looks at a JIRA item fixed for "next-major", people could
get confused (especially I get confused very easily) where to look at
(right answer would be: trunk).
Some issues where moved from trunk to next-major, some from next-major
to trunk, and so on. this seemed arbitrary to me. and this raised my
concerns.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: AW: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
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 <ap...@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
RE: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Posted by "Noel J. Bergman" <no...@devtech.com>.
Danny Angus wrote:
> Trying to inject a positive thought here...
:-)
> > Well, it's a label. Frankly, I'm almost getting used to it. I agree
that
> > it has no meaning in the long-term, since it is a floater, and
eventually
> > needs to have a real label attached to it, but that's a minor point.
> In fact that is how we manage release planning at work.
> Abstract labels are applied to a release after it has been labeled
> with a real label, then changes are labelled with the abstract label
> and eventually a real label is applied.
> I'm not proposing that for here, but I do understand and I know it
> works (I'd be out of a job if it didn't)
Well, can you elaborate more?
> > Well, that is another problem, which I mentioned earlier today. Stefano
and
> > Norman appear to feel that there was a vote to cast in stone what goes
into
> > next-major.
> That still needs to be resolved, there was a vote on general@ (I still
> haven't wound it up) to define the terms and a vote about what was
> being planned, but I don't think we all accepted either of them, not
> really.
Again, that's a problem. Stefano THOUGHT that there was an agreement, and
if I were in his shoes, I'd be pretty shocked now to find out that the
agreement isn't what he thought it was. *I* hadn't realized that people had
voted for something other than what he and I both thought that they had
voted for. As I said, I find it ironic that only I (who did not vote for
it) and he actually took it at face value.
So I'm commiserating with Stefano on this issue. I can appreciate his
surprise.
> > Again, I just asked that he stop removing trunk from the list of
> > versions in JIRA, since trunk *IS* the actual place holding that
> > code, and (to be specific) when we branch next-major, it may or
> > may not have (almost certainly will not have) all of the issues
> > closed that are closed in trunk.
> What we need to do is to record *both*
That's what I wanted. I just wanted him to stop removing trunk as a version
label.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Posted by Danny Angus <da...@gmail.com>.
Trying to inject a positive thought here...
> Well, it's a label. Frankly, I'm almost getting used to it. I agree that
> it has no meaning in the long-term, since it is a floater, and eventually
> needs to have a real label attached to it, but that's a minor point.
In fact that is how we manage release planning at work.
Abstract labels are applied to a release after it has been labeled
with a real label, then changes are labelled with the abstract label
and eventually a real label is applied.
You can move the labels to change the contents of the release,
continuous integration works on the abstract labels.
I'm not proposing that for here, but I do understand and I know it
works (I'd be out of a job if it didn't)
> Well, that is another problem, which I mentioned earlier today. Stefano and
> Norman appear to feel that there was a vote to cast in stone what goes into
> next-major.
That still needs to be resolved, there was a vote on general@ (I still
haven't wound it up) to define the terms and a vote about what was
being planned, but I don't think we all accepted either of them, not
really.
> I appear to have been cast as the official naysayer (ironic,
> but addressed in another e-mail), but it appears that no one who voted for
> the plan actually agreed with it at the level assumed by Stefano and Norman.
> So that's an unresolved tension.
Agreed This is a symptom of the communication issue which we need to
resolve if we're going to manage to work together. We need to get much
better at cooperating and do it quickly.
> Again, I just asked that he stop removing trunk from the list of versions in
> JIRA, since trunk *IS* the actual place holding that code, and (to be
> specific) when we branch next-major, it may or may not have (almost
> certainly will not have) all of the issues closed that are closed in trunk.
What we need to do is to record *both*
>
> Clearly my request has escalated beyond all proportion for what was
> intended.
Again I believe that that is a symptom of the disfunctional family we
are becoming.
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> 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
RE: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Posted by "Noel J. Bergman" <no...@devtech.com>.
Danny Angus wrote:
> Jürgen Hoffmann wrote:
> > And if trunk == next-major, where is the difference?
> > Why is everyone so touchy about the term?
> The issue is that it has no meaning.
Well, it's a label. Frankly, I'm almost getting used to it. I agree that
it has no meaning in the long-term, since it is a floater, and eventually
needs to have a real label attached to it, but that's a minor point.
> We all have our own ideas about what the next major release is, but
> the term "next_major" is not defined.
Well, that is another problem, which I mentioned earlier today. Stefano and
Norman appear to feel that there was a vote to cast in stone what goes into
next-major. I appear to have been cast as the official naysayer (ironic,
but addressed in another e-mail), but it appears that no one who voted for
the plan actually agreed with it at the level assumed by Stefano and Norman.
So that's an unresolved tension.
> we need to AGREE on the labels and their meanings.
Again, I just asked that he stop removing trunk from the list of versions in
JIRA, since trunk *IS* the actual place holding that code, and (to be
specific) when we branch next-major, it may or may not have (almost
certainly will not have) all of the issues closed that are closed in trunk.
Clearly my request has escalated beyond all proportion for what was
intended.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Posted by Danny Angus <da...@gmail.com>.
On 11/22/06, Jürgen Hoffmann <jh...@byteaction.de> wrote:
> And if trunk == next-major, where is the difference? Why is everyone so touchy
> about the term?
The issue is that it has no meaning.
We all have our own ideas about what the next major release is, but
the term "next_major" is not defined.
We SHOULD [VOTE] to decide what major version number that release is
(e.g. 3.0.0 or 2.4.0) and once that vote has decided we should use the
number for planning. If that vote hasn't taken place we shouldn't be
planning the contents of that release, it stands to reason.
If there is a requirement for indicating that a fix is ready , or will
be ready at any point then that is different and could be done with
labels, BUT we need to AGREE on the labels and their meanings.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Posted by Norman Maurer <nm...@byteaction.de>.
Danny Angus schrieb:
> On 11/22/06, Jürgen Hoffmann <jh...@byteaction.de> wrote:
>
>
>> And if trunk == next-major, where is the difference? Why is everyone
>> so touchy
>> about the term?
>
> The issue is that it has no meaning.
> We all have our own ideas about what the next major release is, but
> the term "next_major" is not defined.
> We SHOULD [VOTE] to decide what major version number that release is
> (e.g. 3.0.0 or 2.4.0) and once that vote has decided we should use the
> number for planning. If that vote hasn't taken place we shouldn't be
> planning the contents of that release, it stands to reason.
> If there is a requirement for indicating that a fix is ready , or will
> be ready at any point then that is different and could be done with
> labels, BUT we need to AGREE on the labels and their meanings.
>
> d.
I not care much about the numbers.. Anyway if you do please start a vote.
bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Posted by Bernd Fondermann <be...@googlemail.com>.
On 11/22/06, Jürgen Hoffmann <jh...@byteaction.de> wrote:
> Hi Bernd,
>
> no offense at the moment, but knowing that Jira offers saveable search
> queries, I am really puzzled by such a statement. You select "Search Issues",
> select Next Major and Trunk (You can select multiple entries by holding down
> the CTRL-Key) and save your search. It is afterwards right there, whenever you
> need it.
cool. that is fabulous. problem solved... thanks! ;-)
Now as we have this yet overdiscussed jira label thingy resolved...
I still don't get this "roadmap for himself" statement you made. For
me, the current road map is to put all things in trunk until the
branching. There should be no need for a "personal" road map. Am I
getting something wrong again?
Thanks,
Bernd
>
> -----Ursprüngliche Nachricht-----
> Von: Bernd Fondermann [mailto:bernd.fondermann@googlemail.com]
> Gesendet: Mittwoch, 22. November 2006 13:16
> An: James Developers List
> Betreff: Re: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
>
> On 11/22/06, Jürgen Hoffmann <jh...@byteaction.de> 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.
>
> "for himself"?
>
> >
> > And if trunk == next-major, where is the difference?
>
> The difference is, that TRUNK is existing in subversion and is the
> place where all the commits go ATM. "Next-major" is a JIRA label and
> if somebody looks at a JIRA item fixed for "next-major", people could
> get confused (especially I get confused very easily) where to look at
> (right answer would be: trunk).
> Some issues where moved from trunk to next-major, some from next-major
> to trunk, and so on. this seemed arbitrary to me. and this raised my
> concerns.
>
> Bernd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
> !EXCUBATOR:1,45643fbc53079559943052!
>
>
>
> ---------------------------------------------------------------------
> 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
AW: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Posted by Jürgen Hoffmann <jh...@byteaction.de>.
Hi Bernd,
cool. that is fabulous. problem solved... thanks! ;-)
[JH>] anytime :)
Now as we have this yet overdiscussed jira label thingy resolved...
I still don't get this "roadmap for himself" statement you made. For
me, the current road map is to put all things in trunk until the
branching. There should be no need for a "personal" road map. Am I
getting something wrong again?
[JH>] Ok, sometimes using german in english is not a good idea ;). What I was
trying to say is, that by using the label form him, you and others, it is now
possible without voting, to assign this label to things which one wants to do
whilst working on next-major. When everyone is finished with it, it is
possible to have the feature list, which has to be voted for (before
branching) ready at a mouse click.
This should really make voting and things easier, because the assignment of a
label to a certain issue can be discussed beforehand, and prevents multiple
threads when it comes to voting time. This has happened too many times in the
past (at least while I am monitoring this list). The Discussions at the time
of the vote tended to be drifting off topic, and to get personal. For me they
became very hard to follow. Who said what, and the whole deal.
This project has so many committers and people doing good things. Quite
opposite to the project I am working on. And there is so much time spent on
writing long E-Mails. I am not saying that they are useless, but most are
off-topic and written to no consent.
The Label really helps the guys in looking into Jira, and find an issue they
want to work on, and assign it a label "next-major". There is no timeframe or
Version Number or anything else so far. Just this label, which enables you all
to say "I want to work on this feature".
So what I wanted to say, is that is not one persons roadmap, but this projects
possible roadmap for the next release. This Roadmap is changeable by all of
you, and displays where this project is heading. If you disagree, you can
start a discussion right away (but I think I said that before).
Kind regards
Juergen
>
> -----Ursprüngliche Nachricht-----
> Von: Bernd Fondermann [mailto:bernd.fondermann@googlemail.com]
> Gesendet: Mittwoch, 22. November 2006 13:16
> An: James Developers List
> Betreff: Re: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
>
> On 11/22/06, Jürgen Hoffmann <jh...@byteaction.de> 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.
>
> "for himself"?
>
> >
> > And if trunk == next-major, where is the difference?
>
> The difference is, that TRUNK is existing in subversion and is the
> place where all the commits go ATM. "Next-major" is a JIRA label and
> if somebody looks at a JIRA item fixed for "next-major", people could
> get confused (especially I get confused very easily) where to look at
> (right answer would be: trunk).
> Some issues where moved from trunk to next-major, some from next-major
> to trunk, and so on. this seemed arbitrary to me. and this raised my
> concerns.
>
> Bernd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
> !EXCUBATOR:1,45643fbc53079559943052!
>
>
>
> ---------------------------------------------------------------------
> 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
!EXCUBATOR:1,45645cd653074584710222!
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Posted by "Noel J. Bergman" <no...@devtech.com>.
Jürgen Hoffmann wrote:
> I am really puzzled by such a statement. You select "Search Issues",
> select Next Major and Trunk
:-) Exactly. Again, as the person who started this thread, all that I was
asking him to do was to stop REMOVING trunk as a version label from the
issues to which it applied. And I believe that I've now explained the
reasons for that a few times this morning, so I'll let it go until people
have a chance to read them. :-)
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
AW: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Posted by Jürgen Hoffmann <jh...@byteaction.de>.
Hi Bernd,
no offense at the moment, but knowing that Jira offers saveable search
queries, I am really puzzled by such a statement. You select "Search Issues",
select Next Major and Trunk (You can select multiple entries by holding down
the CTRL-Key) and save your search. It is afterwards right there, whenever you
need it.
This really should not be a problem with Stefano using a label.
Kind regards
Juergen
-----Ursprüngliche Nachricht-----
Von: Bernd Fondermann [mailto:bernd.fondermann@googlemail.com]
Gesendet: Mittwoch, 22. November 2006 13:16
An: James Developers List
Betreff: Re: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
On 11/22/06, Jürgen Hoffmann <jh...@byteaction.de> 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.
"for himself"?
>
> And if trunk == next-major, where is the difference?
The difference is, that TRUNK is existing in subversion and is the
place where all the commits go ATM. "Next-major" is a JIRA label and
if somebody looks at a JIRA item fixed for "next-major", people could
get confused (especially I get confused very easily) where to look at
(right answer would be: trunk).
Some issues where moved from trunk to next-major, some from next-major
to trunk, and so on. this seemed arbitrary to me. and this raised my
concerns.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
!EXCUBATOR:1,45643fbc53079559943052!
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
AW: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Posted by Jürgen Hoffmann <jh...@byteaction.de>.
Hi Danny,
you contradict yourself. You say the term "next-major" has no meaning, but
there has been a vote to see on what people are willing to work on. Wihtin
this E-Mail/Vote I was able to read the term "next-major" a couple of times.
So this has a meaning to me and should have a meaning to you (you voted a +1).
Then you write "BUT we need to AGREE on the labels and their meanings." Which
is what has happened!
>From the Vote:
> "next-major":
> - based on current trunk
So I see the Label "next-major" and, that it is based upon current trunk. I
really don't understand the hassle that is going on at the moment, because
someone is using a label within an Issue Tracker. Which will be renamed
afterwards. It is not like he tagged the sources or anything. The Label is the
same, that was voted upon, and nothing is different from trunk.
Look at Vincenzos' Mail. This is really just pro-active work, so one does not
have to look through Jira AFTER the vote, to see what all has been done, will
be done.
Kind regards
Juergen
-----Ursprüngliche Nachricht-----
Von: Danny Angus [mailto:danny.angus@gmail.com]
Gesendet: Mittwoch, 22. November 2006 11:56
An: James Developers List
Betreff: Re: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
On 11/22/06, Jürgen Hoffmann <jh...@byteaction.de> wrote:
> And if trunk == next-major, where is the difference? Why is everyone so
touchy
> about the term?
The issue is that it has no meaning.
We all have our own ideas about what the next major release is, but
the term "next_major" is not defined.
We SHOULD [VOTE] to decide what major version number that release is
(e.g. 3.0.0 or 2.4.0) and once that vote has decided we should use the
number for planning. If that vote hasn't taken place we shouldn't be
planning the contents of that release, it stands to reason.
If there is a requirement for indicating that a fix is ready , or will
be ready at any point then that is different and could be done with
labels, BUT we need to AGREE on the labels and their meanings.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
!EXCUBATOR:1,45642cd053071888263105!
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Posted by "Noel J. Bergman" <no...@devtech.com>.
Vincenzo Gianferrari Pini wrote:
> So what you mean is that the right thing to do is, if someone plans to
> have something fixed/working for next-major is to *add* the next-major
> fix version *without removing* the trunk label, right? Sounds correct.
YES! :-) It appears that I was far too brief in my original e-mail.
Stefano had removed trunk as a version and changed it to next major. I
finally asked him to please stop doing that, but apparently the request
wasn't clear enough.
A problem with labeling by intent is that we may end up removing the code
from next-major, which means that someone would need to go back and remove
next-major as the label. Right now, there are quite a few items listed
against Next Major that might not survive the release cycle, especially if
we want that to be shorter rather than longer. It would be best to have
trunk *AND* next-major if it really looks likey to surivive, rather than
force everything to be against next-major as a label for trunk.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
So what you mean is that the right thing to do is, if someone plans to
have something fixed/working for next-major is to *add* the next-major
fix version *without removing* the trunk label, right? Sounds correct.
Vincenzo
Noel J. Bergman wrote:
> Jürgen Hoffmann wrote:
>
>
>> All he is doing is that he is tagging certain jira-issues,
>> that they are fixed in the next-major
>>
>
> Well, that is the thing. They may or may not be. What there ARE closed in
> is trunk. I don't really care if they are listed against next-major, but
> when we actually have code for next-major (remember: trunk is copied, then
> PRUNED to become next-major), it may turn out that they are not resolved in
> next-major at all.
>
> All that I asked him to do was stop removing trunk as a label, since that IS
> where the issue is resolved.
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> 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
Re: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Posted by Norman Maurer <nm...@byteaction.de>.
You got it ;-)
bye
Norman
Vincenzo Gianferrari Pini schrieb:
> So what you mean is that the right thing to do is, if someone plans to
> have something fixed/working for next-major is to *add* the next-major
> fix version *without removing* the trunk label, right? Sounds correct.
>
> Vincenzo
>
> Noel J. Bergman wrote:
>> Jürgen Hoffmann wrote:
>>
>>
>>> All he is doing is that he is tagging certain jira-issues,
>>> that they are fixed in the next-major
>>>
>>
>> Well, that is the thing. They may or may not be. What there ARE
>> closed in
>> is trunk. I don't really care if they are listed against next-major,
>> but
>> when we actually have code for next-major (remember: trunk is copied,
>> then
>> PRUNED to become next-major), it may turn out that they are not
>> resolved in
>> next-major at all.
>>
>> All that I asked him to do was stop removing trunk as a label, since
>> that IS
>> where the issue is resolved.
>>
>> --- Noel
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
> !EXCUBATOR:1,4564720253071762512537!
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Posted by "Noel J. Bergman" <no...@devtech.com>.
Jürgen Hoffmann wrote:
> All he is doing is that he is tagging certain jira-issues,
> that they are fixed in the next-major
Well, that is the thing. They may or may not be. What there ARE closed in
is trunk. I don't really care if they are listed against next-major, but
when we actually have code for next-major (remember: trunk is copied, then
PRUNED to become next-major), it may turn out that they are not resolved in
next-major at all.
All that I asked him to do was stop removing trunk as a label, since that IS
where the issue is resolved.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
AW: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Posted by Jürgen Hoffmann <jh...@byteaction.de>.
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 <ap...@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
RE: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
I'm sorry that you didn't understand my point, and that you're getting beaten up in response. Let me try to be more clear. I am also going to reply in three parts: one for each topic.
>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.
> 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.
> 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?
IMO:
1) Issues should be marked as fixed for the code in which it is fixed.
2) Unresolved issues could be marked as fixed for code in which it is
intended to be fixed. The problem with doing this is that someone
might close it, and not realize that the fix does not exist in the
branch housing that version.
Now, let's consider next-major. As far as I know, we agree that the code in trunk will branch to be next-major. BUT, we also agree that there is code in trunk that may not survive the pruning. For example, perhaps none of the IMAP stuff survives to ship in next-major. We decide that in order to have a release in some timeframe, everything else is stable enough, but not certain other parts. Those issues would be resolved in trunk, but *not* resolved in next-major. Do you understand now why I am making this point?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Next-major is the only real roadmap we currently have: it has proposal,
> status update and discussions. And also a REAL VOTE!
> Next-Major currently is in svn trunk folder. This is what we VOTED.
> I made a proposal, we voted, we had all +1s to that vote. I'm just
> following that release plan. I really don't understand what's wrong
> with this. When I'll have understood this maybe I'll come back.
I'm sorry that you're taking this badly, and I could see this coming a couple of weeks ago when other people started questioning the release labels. And, as a reminder, I started this thread to talk about versions in JIRA, specifically removing trunk from the version list, not to talk about about what ends up or not in next-major. But let try to explain what I see happening.
As best I can surmise, Stefano, what's wrong is that only you and I (and perhaps Norman) took the next-major plan seriously in all of its details (which is why I did not vote in favor of it). Everyone else took it as just a general roadmap, but didn't take seriously the timeframe or consider anything cast in stone.
>From what I can see, the agreement that actually exists is that when everyone is comfortable, we branch trunk to a release branch and start work to stablize that branch. Hey, *I* agree with that, too! :-) What I didn't agree with were some of the details, especially the timeframes, and it seems that other folks ignored that and voted for the outline.
And I have no problem with the general idea. We had laid out something similar in the past. It makes sense. I just didn't agree with some of the details and certainly not even remotely with the proposed timeframes when combined with the rest of it. There are things in trunk that have gotten way ahead of anyone's comfort point, and yet there is a lot of GOOD stuff in trunk, too, with high value.
Here is a bit of irony for you, since you seem to think that I'm fixated on next-minor and against next-major. Most of the code I want to do belongs in next-major. And I don't want to see us maintain the v2.3 branch once we can stablize next-major. When I point out how much code has changed, and suggest that we have to review each change from v2.3 to what becomes next-major, you think that I'm trying to be an obstruction. But what I'm really trying to do is have us do the risk assessment for the code, so that we can more confidently move forward with it.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Next-minor
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I still have to see the roadmap for next-minor if we
> want to talk about nothing and real.
I am sorry that discussion of next-major vs trunk inspired you to have to issue a challenge regarding next-minor. I wasn't challenging you regarding next-major. I just asked you to stop removing trunk from the fix list in JIRA (explained in another e-mail)
However, since you ask, the roadmap for next-minor is clear, but the approach is different from how you are trying to drive next-major. Incremental improvements based upon value and risk assessment. In other words, the road-map for next-minor is based upon the idea that we have a stable release and we want to keep having a stable release. What changes go into next-minor are not as important as why and how.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Next-Major and trunk: AGAIN (Was: [jira] Updated: (JAMES-663))
Posted by Stefano Bagnara <ap...@bago.org>.
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.
If you can't leave with me updating JIRA and mantaining this schema
bring your own reason.
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.
Using only 2.3 as fix version will make a much more clean
roadmap/changelog and will make us understand better the current scenario.
I said I would have operated this way more than 1 year ago, if we want
to change this.
> 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!
On the other side I still have to see the roadmap for next-minor if we
want to talk about nothing and real...
> 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 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.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [jira] Updated: (JAMES-663) sendmail.py crashes on line "from_addr = os.environ['USER'] + '@' + socket.getfqdn()"
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Fix Version/s: Next Major (was: Trunk)
Please stop doing this and messing up the JIRA issues. trunk is real. next_major is nothing. It has no existance except in your mind so far. Who knows what will be in it? We have branched nothing. But in the meantime, the fix IS in trunk. You can add next_major to things if/when the fix actually IS in next_major.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org