archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: Monster Commit Breakdown - svn commit: r583412 [1/8]
Date Wed, 10 Oct 2007 22:36:49 GMT
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  

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 -

View raw message