Re: Howto revive inactive projects ?
After reading the followups, -1 to my original idea! :-) One funny thought: I love having inactive jars in my classpath. It's the active jars that give me all the headaches! -- yours, Julius Davies 416-652-0183 http://juliusdavies.ca/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: News feed,
Howard knocked it together. XML file that generates HTML and RSS. The news.xml in the jakarta/site/ in svn. Hen On 2/7/07, Danny Angus <[EMAIL PROTECTED]> wrote: I see jakarta has a news feed, I'd like to nick the idea for James. How did you do that? d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Howto revive inactive projects ?
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 ten
[Jakarta Wiki] Update of "JakartaBoardReport-current" by HenriYandell
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Jakarta Wiki" for change notification. The following page has been changed by HenriYandell: http://wiki.apache.org/jakarta/JakartaBoardReport-current The comment on the change is: IO and Lang have both just had releases. -- === Releases === + * 13 February 2007 Commons Lang 2.3 + * 13 February 2007 Commons IO 1.3.1 * 30 January 2007 Commons IO 1.3 * 19 December 2006 Commons SCXML 0.6 @@ -109, +111 @@ ''IO'' - Active. A 1.3 release has been made. Mostly this was a case of adding new functionality (some from the Sandbox Finder component) and fixing some bugs. There was a screwup (method wasn't static as desired) so a 1.3.1 is being worked on. There's no activity on a 1.4 yet, but I'm sure there will be. + Active. A 1.3 release has been made. Mostly this was a case of adding new functionality (some from the Sandbox Finder component) and fixing some bugs. There was a screwup (method wasn't static as desired) so a 1.3.1 has also been released. There's no activity on a 1.4 yet, but I'm sure there will be. ''Jelly'' @@ -125, +127 @@ ''Lang'' - Actively working to get 2.3 out the door. + Lang 2.3 has been released this month. Active development is expected to continue. ''Launcher'' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] VelocityTools 1.3 released
I'm pleased to announce the release of VelocityTools 1.3. There have been many improvements made since the 1.2 release. A key focus in this version has been ease of use. We've simplified developing your own tools by eliminating the ViewTool and Configurable interfaces, and we've simplified the syntax for using many of our existing tools within Velocity templates to both save keystrokes and reduce visual clutter. The distribution also comes with a new "showcase" example webapp that demonstrates many of the uses of the various tools as well as allowing you to interactively play with them. Just download the binary distribution, and deploy the "showcase.war" example to your servlet container to try it out. Also included are the usual slate of bug fixes, dependency upgrades, entirely new tools, and new functions for existing tools. For a full listing of changes, see the change log. http://velocity.apache.org/tools/devel/changes.html VelocityTools 1.3 is available in either source or binary form at: http://velocity.apache.org/download.cgi#tools For more information about VelocityTools go to: http://velocity.apache.org/tools/devel/index.html Nathan Bubna, on behalf of the Velocity development community. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Howto revive inactive projects ?
Hi Julius,
> If someone is interested in taking over a truly inactive project,
> maybe they should fork and start their own SVN repository from their
> own domain. The person should make it clear that their fork is in no
> way sanctioned by Apache.
That would be OK for projects that are, as you call it, "truly inactive".
Meaning: no developers and no users. But I believe our main concern is
with projects where the developers have moved on, but a user community
is left. Forking this kind of project is disadvantages in various ways:
- The developer not only has to learn the new code base, but must also
build a new user community either from scratch or by winning over
the users of the Apache code base. That means a lot more work for
the developer candidate, and makes a successful revival less likely.
- The users are left with a choice between the inactive Apache project
and the live fork. Re-integration of the fork is a possibility but
can not be guaranteed. Meanwhile, users of the forked codebase are
missing the legal protection provided by the Apache foundation. And
potential new users of either codebase face uncertainty.
I believe that Jakarta projects with an active user base should be
revived within Jakarta. I thought a while about some kind of second
class committer status, but found more reasons against than for the
idea. Here is my take on a revival procedure...
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.
- A CLA on file from the revival candidate. ("resurrector")
Procedure:
- Create a "revival" fork of the code base in the software repository.
- The resurrector submits patches for the revival fork in the bug
tracking system.
- The mentor reviews patches for style only, not for functionality.
- Patches are committed by the mentor to the revival fork.
- 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.
- All discussions take place on the regular mailing list(s) of the
project, so that users are aware of the revival attempt.
- 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.
- 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.
- 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.
- The first task of the new committer is to merge the revival
branch into the main trunk.
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.
cheers,
Roland
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
