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
Steve Brewin wrote:
In my experience, having more than one active development branch almost
always ends in tears, even in more tightly controlled commercial endevaours.
Its fine having a trunk and branches for past releases to which maintenance
may be applied. For instance, after releasing 2.3 we
Serge Knystautas wrote:
On 5/30/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Well, I think this explain why I think that this is not a best practice.
Most James discussions takes weeks and are lost forever with no results.
This thread has gotten somewhat bitter.
My 2 cents... I voted for St
Vincenzo Gianferrari Pini wrote:
Yes. And one of the things that held us up for a long time was making
changes that blocked our ability to get good releases out the door. I'd
like to learn from that, and avoid a repeat.
--- Noel
If this is referred to anything happened in the last year I
James is a great project but sometimes we take to long
Yes. And one of the things that held us up for a long time was making
changes that blocked our ability to get good releases out the door. I'd
like to learn from that, and avoid a repeat.
--- Noel
If this is referred to anythin
Am Mittwoch, den 31.05.2006, 01:08 -0400 schrieb Serge Knystautas:
> On 5/30/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> > Well, I think this explain why I think that this is not a best practice.
> > Most James discussions takes weeks and are lost forever with no results.
>
> This thread has
On 5/30/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Well, I think this explain why I think that this is not a best practice.
Most James discussions takes weeks and are lost forever with no results.
This thread has gotten somewhat bitter.
My 2 cents... I voted for Stefano as a committer and
Steve Brewin wrote:
Stefano Bagnara wrote:
I also wrote something really clear: "If I understand your words you
are: -1 to apply the code for a 2.4 release but you don't
apply a veto
if the release will be 3.0 or if we add unit tests, is it right? "
No reply is not a fast solution. 3 days have
Stefano Bagnara wrote:
> I also wrote something really clear: "If I understand your words you
> are: -1 to apply the code for a 2.4 release but you don't
> apply a veto
> if the release will be 3.0 or if we add unit tests, is it right? "
>
> No reply is not a fast solution. 3 days have passed and
Noel J. Bergman wrote:
As you suggest, we want development to happen actively within source
control, so that people can see the changes as they happen.
This has not been my impression: I received "alerts" every time I
committed something without discussing first.
I always said that we could r
Steve Brewin wrote:
What I said about fetchmail holds for Maven 2 too.
I'll try this another way. For 2.2.x code, if it ain't broke, don't fix it.
Oh, I agree: the difference is in the definition of broken.
Imho if it is not good enough for your next step then it is broken.
If you have a bike
Noel J. Bergman wrote:
>
> Norman Maurer wrote:
> > Noel wrote:
> > > Stefano wrote:
> > > > We can't take weeks and dozen of messages for each
> single commit.
> > >
> > > Depends upon the nature of the change. Weeks and weeks of active
> > > discussion? Might be quite useful. Weeks of silence?
Noel J. Bergman wrote:
Stefano wrote:
maybe I should start working on a branch [instead of trunk]
At the moment, I don't think so, but in the bigger question, it depends upon
what we are doing. Some of the changes being made are going to push release
dates for trunk back further and furthe
Am Montag, den 29.05.2006, 14:55 -0400 schrieb Noel J. Bergman:
> people can see the changes as they happen. The fetchmail
> code might have been a good example of when to use a branch, since it
> was
> relatively isolated, and would have been easy to merge in afterwards.
> Steve
> wasn't saying t
Norman Maurer wrote:
> Noel wrote:
> > Stefano wrote:
> > > We can't take weeks and dozen of messages for each single commit.
> >
> > Depends upon the nature of the change. Weeks and weeks of active
> > discussion? Might be quite useful. Weeks of silence? Not so much.
> > Dozens of messages on
Norman Maurer wrote:
>
>
> Am Montag, den 29.05.2006, 11:40 -0400 schrieb Noel J. Bergman:
> > Stefano wrote:
> >
> > > maybe I should start working on a branch [instead of trunk]
> >
> > At the moment, I don't think so, but in the bigger
> question, it depends upon
> > what we are doing. Some of
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'd like to avoid us having that problem again. Hence the topic: Managing
Changes.
Noel J. Bergman wrote:
http://svn.apache.org/viewvc/james/server/tags/pre-v2and3-merger-trunk/tes
ts/
http://svn.apache.org/viewvc/james/server/tags/pre-v2and3-merger-trunk/pro
posals/
Bernd might want to look at the testing code, for example, although he may
have surpassed it in all cases.
Am Montag, den 29.05.2006, 18:04 +0200 schrieb Stefano Bagnara:
> Sorry. I can't keep up with this. This, in part, offend me: I would
> accept this if I was one of ten committers actively working and if my
> work introduced more problems than the ones fixed.
Im sad to read this but i can really
Am Montag, den 29.05.2006, 11:40 -0400 schrieb Noel J. Bergman:
> Stefano wrote:
>
> > maybe I should start working on a branch [instead of trunk]
>
> At the moment, I don't think so, but in the bigger question, it depends upon
> what we are doing. Some of the changes being made are going to pus
Sorry. I can't keep up with this. This, in part, offend me: I would
accept this if I was one of ten committers actively working and if my
work introduced more problems than the ones fixed.
I'm too busy now to try again understanding this. I temporarily will
stop to commit in trunk until I will
Stefano wrote:
> maybe I should start working on a branch [instead of trunk]
At the moment, I don't think so, but in the bigger question, it depends upon
what we are doing. Some of the changes being made are going to push release
dates for trunk back further and further, whereas others won't. S
22 matches
Mail list logo
