Hi, (Sorry for the delay) I agree with the dev process which will clarify our changes in the code base and give a better visibility for our community. The new Home page is very pleasant but we'll have to not forget to update it (as long as we don't have something more integrated which could take itself last releases from Jira for example, ..). It could be effectively a good idea to use XWiki in the future.
However I have a problem with the Annotated Dev Process (http://docs.codehaus.org/display/MAVEN/Annotated+Development+Process) : Are you sure that it can work ? Personally I never saw a project using branches for dev working for a long time. We'll have more or less late some problems to merge branches if changes are important. We had it some monthes ago on archiva. Joakim made so much changes that it were a big headache to merge his branch in the trunk, thus we decided to swap them. It was possible because there was few activity in the trunk and there was only one branch. I'm not convinced about that. The future we'll say if it is a good idea but I prefer that everybody work on the trunk (the CI server is here to check that there's nothing wrong) and we keep branches to maintain releases. Another thing that your proposal isn't covering and I think is important : releases management. I find that our community have a lot of problems to deliver products regularly. It's now better for m2 core but m2 without its plugins and others components is "nothing". We have the flaw to be too perfectionist. We are often overstep the bound of alpha, beta instead of trying to deliver regularly a new version (whatever we changed in it). Before, with maven 1, we justified this because we bundled a lot of plugins and we tried to improve them before to create another release. Now it's no more the case and we have again a lot of plugins not released regularly or always in a beta/alpha stage. Why? It's not the release process, because it was greatly improved in maven 2 and it requires few steps. Can we change that ? Could we try to work within time frames instead of focusing on the content? For example we could generate each month (less often?) a report about which plugins/components had issues fixed. We could release all of them (it could be difficult at the beginning because we have a big debt). Cheers Arnaud On 26/06/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Hi, As part of trying to make the whole process of making changes and adding new features transparent to everyone involved I've whipped up a little sketch for perusal: http://people.apache.org/~jvanzyl/DevProcess.png Basically it revolves around making sure things are documented in the Wiki and providing a clear record of the evolution of the project that anyone can follow at any point in time. So far from perfect but I think a good starting point and I would like to field feedback so I can improve it. It basically revolves around the dashboard where I've tried to collect all relevant information about the project: http://docs.codehaus.org/display/MAVEN/Home And process is based around making proposals that eventually will serve as the record of evolution of the project. The goal is not to have anything that's heavy, and that we might eventually be able to automate some data gathering but for the meantime it's not overly onerous and provides some visibility we have not yet had to date. The proposals are all here: http://docs.codehaus.org/display/MAVEN/All+Proposals And they basically move from draft -> pending -> approved. I've put some notes in the diagram and I figured we could start with a simple proposal to see how it works and iron the kinks as we go. This is experimental but I see it as the best way forward for getting a clear view of what's going on Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com ---------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- .......................................................... Arnaud HERITIER .......................................................... OCTO Technology - [EMAIL PROTECTED] www.octo.com | blog.octo.com .......................................................... ASF - [EMAIL PROTECTED] www.apache.org | maven.apache.org ........................................................... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
