Hi Joakim,
Thanks for discussing this. I don't want to dwell on it since I think
we are in agreement that the change is the right technical direction
but that it should not have been done in such a "singular" fashion.
However, there are a couple of things I don't quite agree with and
wanted to pick up on. I'm not sure if we differ in opinion or if I'm
just reading through jetlagged eyes :)
Also, though this thread is now largely unrelated to the change
itself - please reply to my other mail which addresses specific
technical issues that are outstanding. I'm particularly concerned
that the purge feature is no longer working (and in a way that
indicates version parsing may be broken entirely based on the error I
got).
On 10/10/2007, at 9:25 PM, Joakim Erdfelt wrote:
Technical Breakdown of commit:
This is pretty consistent with what I observed from scanning it, but
I think that supports the whole point in my other mail - unrelated
changes shouldn't go together. I just wanted to stress my objection
was not to the size of the commit, but the complexity.
First: THIS IS NOT A MAVEN 1 LEGACY ONLY PROBLEM as some people have
suggested. The way layouts were used within archiva prior to
this commit made the entire core unreliable, inconsistent, and
subject to failure in real world scenarios.
Sorry, but to me that wasn't clear from the proposal - all the
discussion centred around those particular problems. We need to work
on better describing the problems being addressed by changes.
As we get more and more users of Archiva for their day to day
projects,
we see more and more examples of legitimate usage of Archiva where
the
most basic functions fail due to a one layout assumption or another.
Just IMO, but I think this is overstating the problem a little :)
(2) I could have split this commit up into separate pieces, but
decided
that getting this code into place was more important that spending
the
next several days carefully crafting the optimum separation of
commits
to perform that wouldn't break the build, or have a dependency on
another
commit coming up. This was my decision, I was not coerced into it, I
weighed the options (3) and felt that getting a version 1.0 out
sooner
rather than later was more important.
I would love to see Archiva 1.0 final out before ApacheCon US
(starting on November 10th, 2007)
I don't agree here. Crafting small changesets should not be more work
than large ones - it's simply a matter of discipline. And we cannot
cut corners to speed a release - we've seen that it causes the
opposite effect already.
This code is a bug fix for current open and assigned jiras, it is not
a rearchitecting, or work against future issues, or even an
attempt at
code perfection.
The end result was that it did re-architect something, based on a
proposal that was still being discussed. I think we need to be more
critical of the need for that (see below).
Archiva is a web application, and as such, will have a different way
of handling changes to the codebase, it is not subject to the the
same
stringent commit and change controls in place for maven, or java
libs,
or components that are either released, shared, or in common use
across
many users or other applications. This is the best time to make
these
kind of changes, before the release, before the web services.
I don't agree with this. Good development practices should apply
everywhere. Yes, it's easier to get away with making sweeping changes
now, but that doesn't make it the right choice.
I realise I'm oversimplifying, but I think it's important to agree on
the ideals and make concessions only where necessary.
I acknowledge that I could have branched this, which given the
flak i'm
getting for this commit, I probably should have. But I stand by this
change as a means to get the product stable in a faster fashion.
Stable? "You keep using that word. I do not think it means what you
think it means." :)
It is stable when it is "not likely to change or fail". A known bug
is not a stability problem. Within the scope I use it, it runs 24x7
on my machine without failing. I think it's stable.
Large changes decrease (development) stability by definition.
If we really want to seek stability, we need to be making small,
testable changes towards the 1.0 release from here on out.
I apologize for scaring the crap out of the other devs.
I apologize for for not making a branch first.
I apologize for not splitting up the commit.
I apologize for stomping across other peoples active work.
In the future I promise to be more clear about the scope of changes
that need to be done.
I promise to better manage my commit sizes and scope in the future.
Thanks, much appreciated!
- Brett
--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/
