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
