On 2/14/07, Roland Weber <[EMAIL PROTECTED]> wrote:
Here is my take on a revival procedure...
Pre-precondition.
We need to define what is inactive and place it in such a state.
Dormant seems a favourite word.
In the recent board report for the Commons components, we've gone with
"Inactive" to mean that there is no coding and no one is watching over
it; and "maintenance" to mean that there is no coding, but someone is
watching over it. Something that is "inactive" is up for being made
"dormant".
So we need to define Jakarta components in this way and challenge each
inactive component to explain why it is not suitable for dormancy. I
think we need to do this even if there is an active user community -
being told that Xxx is now being considered inactive might kick people
into being active.
So first - let's get the components defined in these ways and reflect
this on the website(s).
There's been a suggestion on [EMAIL PROTECTED] that dormant projects
should be moved into the Incubator.
The following becomes a process for reactivating:
Preconditions:
- A mentor with committer/admin access to both the software repository
and the bug tracking system. One that is willing to invest significant
time and not just give a useful tip once or twice a week.
+1.
- A CLA on file from the revival candidate. ("resurrector")
The mentor should guide them through a few patches to show they are
committed, then we can make them a committer. I don't think there's
any reason to do CLAs without also making them committers.
I'm not sure we need to define a 'resurrector'. Rather we should
define the project as being revived and explain that that means that
Person X is mentoring it and that N people are submitting patches to
get it moving along. Often when one person gets active on a component,
others start to show up. Having a resurrector limits the new
contributions.
We could have a wiki page that lists dormant components and people
could put their names down (emails?) as interested in reviving a
component.
Procedure:
Step 1 - announce to all that the dormant component is being revived.
- Create a "revival" fork of the code base in the software repository.
Probably a good idea. I'd have immediately said to tag a "prerevival"
tag and then go for it in trunk, but that is a pain when the move
fails and someone else tries to do the same later.
- The resurrector submits patches for the revival fork in the bug
tracking system.
+1
- The mentor reviews patches for style only, not for functionality.
Why not functionality? To keep the time required for the mentor low?
- Patches are committed by the mentor to the revival fork.
+1
- The mentor is responsible for running tools with committers-only
access, such as Clover. The mentor encourages the writing of test
cases by the resurrector.
I think this is pretty unnecessary in the process. Clover's the only
example and I don't think it's as used now as it used to be.
Cobertura/Emma/JCoverage seem to have done enough to stop it becoming
predominant.
However - the mentor refuses to commit without a test patch would be
something I'd expect to see.
- All discussions take place on the regular mailing list(s) of the
project, so that users are aware of the revival attempt.
+1, though a lot tends to take place in JIRA/Bugzilla. The mentor
should be encouraging the people contributing patches to prepare
release plans and communicate them to the mailing list.
- Adventurous users are encouraged to try out the revival branch.
They'll probably have to compile themselves, or use a manually
created snapshot as the nightlies would still be based on the
main trunk rather than the revival branch.
We could be doing the revival branch in the nightlies too.
- If there is a significant number of fixes in the revival branch
and code quality is considered good enough by the mentor (for
example based on Clover test coverage results), a "Possible
REvival alpha release" (PRE-alpha) is created.
- Publication of the not-quite-release is done on a low profile,
as it is not a full quality release of an Apache project. For
example, due to the lack of a developer community, there won't
be three binding votes as required for a real release.
-1. That's nothing more than saying "We think the nightly is pretty
good now" on a mailing list.
Do an actual alpha release. The vote should be held here if there's
not enough voting on the components list.
- Adventurous users are encouraged to try out the PRE-alpha.
- If the PRE-alpha exhibits major quality problems, continue with
bug fixes and improved test coverage. Repeat PRE-alpha procedure.
The decision about the quality is at the discretion of the mentor.
- Once a PRE-alpha release meets quality standards, the mentor
calls for a Jakarta-wide vote to promote the resurrector to
committer status.
Make them a committer based on their patches. The only problem with
this now is that we don't tend to pay enough attention to people
making the patches and voting on them.
- The first task of the new committer is to merge the revival
branch into the main trunk.
I forgot about the revivial branch. Bit worrying having any kind of
release that is from the branch; I'd like to see this merging happen
prior to discussions of an alpha release.
Or something along that line. Multiple mentors would be better
than one, but who believes in that many volunteers? A mentor is
of course free to ask for help, in particular on major decisions
such as whether a PRE-alpha is good enough or not.
If only we could find multiple mentors :)
Good ideas. We've done variants of this in a few places:
BCEL - Dave Brosius joined. Torsten and I (and Conor from Ant I think)
mentored and he got things moving. Torsten's more involved now, it's
not moving anywhere fast though (I think... I've not looked for a
while).
BSF - Self-started. Old committers got around enough to push things on
and get the new committers in. Other Jakarta committers have helped
them with the 'how to' of things, though it took too long for that to
start up (I think).
Commons - We tried to do this with the compress component in the
sandbox, but it's not gone anywhere (we did add a committer). We tried
to do it with CLI, but the contributor didn't respond to the "we've
voted you as a committer" emails. Email is currently moving along
nicely with a contributor and a mentor. Modeler got released this way
- but the contributor was Dims.
Hen
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
