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 further, whereas others won't. Steve's
comments about Fetchmail, for example, weren't that the changes might not be
good ones, but that they are likely to push out release dates for trunk.
Every change has a risk and a cost. Every change. The more major the
change, and the more pervasive its effect, the more the risk. The more
risk, the more testing that should be done. And hopefully the greater the
benefit, or there is little point to making them.
Making changes changes schedules. Many of the changes you are making are
fine, but they change core parts of JAMES, which means more risk.
Fortunately, we have more testing coverage, and that is helpful, but these
changes still entail higher risk than isolated changes effecting single
components.
A related question is what belongs in trunk. I would say that it should be
the mainstream development. When we did the branch merger, we intentionally
merged only the actively used, mainstream, code into trunk. So, as you
discovered, there are other things, such as proposals, testing code, and
other things, that weren't active and weren't merged. Not everything is in
trunk, and people should be aware of where those things are in case they
want to start working on those parts, and make it suitable for trunk.
Personally, I'd see making major changes in branches, and merging
afterwards, so that trunk can be kept more stable while those changes are
being made. I don't know how others feel.
I'd expect the next release to come out of the v2.3-branch. I am testing
only against this one.
I'd favor big changes to happen on trunk rathern than on a branch. Trunk
has better peer oversight and is tested a lot more by others than some
'remote' branch somewhere.
But there may well be situations when changes are so experimental or
fundamental and cannot be broken into small patches, that a branch
suites better.
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 something? I'd expect nothing less for some types of
changes, althought I would also expect development to start at some point
during the discussion.
+1
Norman Maurer wrote:
> Ok so let us make a roadmap! What changes should be made in 2.x
> releases ? what to make in 3.x ? We need to know for making the changes
> on the right release (time).
> Should we use a trunk ( for all work) , 2.3-branch (for merging to
> current release),2.4-branch (for merging for next release) ,3.0-branch
> (for next milestone changes) ?
>
> What the other guys think ?
Personally, I am not ready for a post-2.3 roadmap yet.
I have many things in mind I'd like start working on, but I think it's
now time to finalize 2.3.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
