archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trygve Laugstøl <tryg...@apache.org>
Subject Re: [VOTE] Merge Archiva Database Branch to Trunk
Date Thu, 26 Apr 2007 14:02:45 GMT
Joakim Erdfelt wrote:
> Trygve Laugstøl wrote:
>> Joakim Erdfelt wrote:
>>> Lots of work has been done in the archiva database branch in the past 
>>> 2 months.
>>>
>>> It has come time to start the merge back into trunk and get the help 
>>> of others to finish off the work.
>>>
>>> I wanted to point people to the branch and let them take a look 
>>> around, and then vote.
>>>
>>> As I see it we have 3 options.
>>>
>>> option A [ ] Make the branch the new trunk.
>>> option B [ ] Merge the branch into the existing trunk.
>>> option C [ ] -1 Do not merge the branch into trunk.
>>>
>>> I'll wait the usual 72 hours and tabulate the scores.
>>> Scores will be tabulated around 1:00am Sunday UTC.
>>
>> I vote for the one that will get an alpha out as soon as possible.
>>
>> Archiva is really missing out on a lot of good customers and thus 
>> developers. I am afraid that unless an alpha is kicked out ASAP the 
>> development will loose it focus and that it will develop more advanced 
>> and/or unnecessary features that needed.
> My timeline is this ...
> 
> 1) Get branch merged back into trunk.

As I'm not following Archiva from the code point I find it a bit hard to 
vote for A or B. I'd suggest the ones working on trunk specify how 
big/isolated their changes are and use that as a basis for a decision.

I'm not sure if a vote is the best tool to sette branch->trunk or 
trunk->branch.

> 2) Allow 1 to 2 weeks to stabilize core functionality.

I'd recommend the following approach:

1) Write down all the use cases that you want alpha 1 to implement. Note 
that stuff like security is not something that should be the focus of an 
alpha 1. I wouldn't mind skipping it for 1.0. I for one don't use any 
security for anything but uploading, which I could life without if it 
would save me all that httpd configuration that I have all over the place.

2) Write integration tests that do mostly happy day testing of the use 
cases. Only fix the functionality that is *broken*, not missing. This 
was a very useful tool when developing Continuum, and I'm pretty sure it 
will be a very good fit for Archiva aswell. Writing the tests in python 
was easy and made it easy to call external programs.

3) Release, rinse and repeat.

> 3) Release 1.0-alpha-1
> 4) Integrate redback.
> 5) Work through jira's.
> 6) Release 1.0-alpha-2 (time since 1.0-alpha-1, about 2 weeks)
> 7) Work through feature set for 1.0 in 
> http://docs.codehaus.org/display/MAVENUSER/Archiva+Roadmap

I just did a quick read of the roadmap and have some comments:

Drop everything related to reporting and automatic processing. The 
logging stuff is something I would strongly consider moving to 1.1, but 
might be very useful in some cases so a simple CSV-like file will cover 
the most basic needs until an 1.1 release.

> 8) Tackle jira's
> 9) Iterate thru feature set and jiras until we decide it's time for 1.0 
> (final).

I would not use the bugs in JIRA to create your roadmap. Alphas are here 
to demonstrate features more that stability. Stability and robustness 
come with the betas. Features come with 1.1+ releases.

This baby are way overdue and still adding features just feels wrong. 
There is nothing wrong in releasing an 1.1 a month after the initial 
release and just show signs of an active community.

--
Trygve

Mime
View raw message