I like this approach, and I think it's just a slightly more detailed version of what some of us are already trying to do when we put together major new pieces for Maven. I agree with Eric that any API or behavioral change should probably follow this process, basically anything that could change what the user experiences.
However, for me, it'd be nice if we could follow this documentation/ratification process with some enforcement and quality controls. For instance, I'd love to see something that would help us improve our test coverage (not just LoC, but functional coverage), and other pieces that would help keep us honest on API modifications. Clirr can do the latter, but I'm not sure there's a good tools for the former, as code-coverage doesn't tell the story of how much of a claimed feature actually works...that's more of an assessment of test quality as well as population. This is definitely a step in the right direction, and should help us tame the release process a little more. Hmm, we should be writing all of this down for posterity...How We Tamed the Maven Development Process. That way, rather than being hypocrites for talking about idealistic dev processes that we don't follow, we can join the masses in our migration toward that ideal. ;-) Cheers, -john On 6/25/07, Eric Redmond <[EMAIL PROTECTED]> wrote:
I kind of like the idea of this process applying to any API change - even if it's just a bug fix, not necessarily a feature request. It would also be nice to either have the "Work" articles under "Work in Progress" themselves contain contain the related JIRA issues (since there could be more than one, like ArchetypeNG) - either that or dictate that each proposal has one "feature" JIRA issue (that you can link others to). I don't know if this is already supposed to be the process, but it's clearly not being strongly adhered to. Something minor - I don't know if it was a graffle gaffe (ha) but it might get confusing having two steps named "Approved Proposal". I would imagine one moves the draft to "Approved" before working on the project - which is kind of redundant since once it's approved it moves to work in progress. How about "Drafts", "Pending" and "Complete"? Thanks; Eric On 6/25/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] > > -- Eric Redmond http://www.sonatype.com
-- John Casey --- Maven Developer (http://maven.apache.org) --- Blog: http://www.ejlife.net/blogs/buildchimp
