hehe - to be clear, I was kind of joking. My stuff is on a branch
because I don't like local changes and because it isn't yet 100%
working. I don't want to interfere with the release.
It's existence will also help Joakim to review it and understand
where there are potential conflicts, and minimise the damage. Right,
Joakim? :)
I don't intend to maintain it any longer than this week.
On 21/08/2007, at 3:10 PM, Arnaud HERITIER wrote:
It's why I'm not in favor of the decision we made to use branches.
First times it could be a game. Following times it's quickly the war.
The one who want to be the first to back home (in a corporate env)
will commit its code with less checks and the last one will be
punished by having to merge others changes. In opensource we are less
in a hurry, thus I hope we'll not see the second case happen.
Arnaud
On 21/08/07, Brett Porter <[EMAIL PROTECTED]> wrote:
I'm not merging until I'm done, and I'll give a heads up.
But please, be nice... :)
Actually, maybe we should race. Loser has to resolve the
conflicts! :)
- Brett
On 21/08/2007, at 1:04 PM, Joakim Erdfelt wrote:
I have a decent raft of new code coming in as part of MRM-463
(metadata stuff), can you hold off until that commit comes in?
- Joakim
Brett Porter wrote:
I decided to use a branch for the configuration split since I
thought it could be (at least partially) contentious, and is at
least quite disruptive. I won't have a problem merging the lot
down to trunk once completed.
Please review the changes if you are interested in it - I'm
confident that the changes outside the webapp are solid since all
the tests are passing again (I've added some coverage that was
missing in archiva-configuration, the rest are much less
consequential changes).
The next step is to change the webapp, and I'l be adding tests
there to ensure that the functionality is working. This could take
a little longer.
I'm worried at how much the implementation details of the
configuration have leaked out throughout the application -
something to review later on.
Thanks,
Brett
--
..........................................................
Arnaud HERITIER
..........................................................
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..........................................................
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...........................................................
