On 25 Jun 07, at 7:11 PM 25 Jun 07, John Casey wrote:
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.
Yah, really just to surface the information. I know that there are
only a few of us know where everything is because we look at it
everyday but the casual contributor wouldn't have a chance. I think
this really facilitates contribution. Someone who has a particular
need can see if there is anything vaguely related to what he needs.
The other place this can go is to have a place in the MAVENUSER space
that is an analog for non-committers. Any committer who put together
proposals for patches in the same way we did for adding/changing
functionality would get my attention for first for sure. If we have a
process that is visible we can make this accessible to contributors.
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.
We can certainly add the Clirr requirement and I'll add that to the
requirements for "deemed fit for completion". So right now the list is:
- another committer to review
- api inspection for compatibility
I'm sure are many points that are implicit which we could make
explicit. Like ITs being added, unit tests being included,
javadoc ... and maybe even something like we do with the plugins
where we have a standard usage document, so for new features this
could be a requirement, how that meshes into the site. Many things
are possible. This is just the start.
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. ;-)
Heh. Sure, I don't mind writing this up because it's my job currently
during the day at two very large organizations struggling with the
same issues.
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
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]
