incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "robert burrell donkin" <>
Subject Re: Wicket again (was Re: incubation process for open development open source projects)
Date Thu, 10 Aug 2006 22:00:40 GMT
On 8/9/06, Upayavira <> wrote:
> Igor Vaynberg wrote:


> > here is another example.
> >
> >> Noel J. Bergman
> >> Most users should not be using Incubator code.  Only those who are
> > committed
> >> and willing to trust that the project will do well here and eventually
> >> become an ASF project.
> >
> >> Remember that most people don't believe that Incubator projects should
> >> even have a user@ list, only a dev@ list.
> My suspicion there is that Noel is being somewhat idealistic in that
> sentiment. Especially given the number of incubating projects that do
> have user lists!

experience has shown that it's better for incubator projects not to
start out with user lists hosted at apache. there is no policy against
incubator project having user lists, it's just that   creating them by
default as part of the proposal has disadvantages  both for new
projects and for those with existing user lists.

to create a user list, a binding vote on the incubator project dev
list is sufficient. no (explicit) incubator pmc involvement is

IMHO it would be easier for an existing open source project (with a
user list) moving to apache to bootstrap just a dev list whilst
maintaining their existing user list for a transitionary period. once
the apache infrastructure is up and running ok, then the user list can
be created by vote and the migration managed. i think that this
process is likely to work out more smoothly for existing users.

> > where does this leave us?
> > so i guess what i would like to confirm is the following:
> >
> > a) we will have a user list in the incubator and our users will not be
> > discouraged from joining it
> That seems fair enough to me. Hopefully others (particularly Noel) will
> chime in.

here's how i see it (maybe noel will jump in afterwards)

bootstrapping a user list is discouraged. any users coming through the
apache site should be directed to the developer list during the
transitionary period whilst the incubator project is being
bootstrapped. (this does take some time.)

if an incubator project votes for a user list, once one is set up of
course users should be encouraged to join it.

> > b) if we have a final release ready even though we were in the incubator
> > for a short time ( lets say a month ) it will not be blocked just because of
> > its timeframe.
> So long as the other criteria that are required in order to do a release
> are met, I do not see any problem with that.

IMO apache is very unlikely to endorse any full release made from the

it's very rare for any incubating project to create compliant releases
the first few times they try. there is more overhead and it may well
be a number of weeks between code cut and having an incubator approved
release. a dedicated and experience open source release manager
willing to research the issues would be able to cut this time
significantly, though.

from a pragmatic perspective, if your users really need a regular
release then IMHO it would be better to issue an offshore wicket
release in the way you do now and then work on apache incubator
compliant release based on the same code. (there should be no code
changes required, just packaging and licensing related ones.) you'd
need to be careful to remove references to apache from the offshore

> In this case, the criteria are objective ones, such as: all contributor
> CLAs have been received by ASF; licenses are correctly placed on all
> source code, license files (NOTICES.txt, LICENSE.txt) are correctly
> placed within the release file, etc, etc. Nothing that should be too
> hard to manage (esp as I'd intend to do most of the CLA gathering before
> actually shifting to Apache - without doing so you'd have committers
> without commit access to your codebase, which really wouldn't work)

typically the part which takes the longest is tracking all the other
small code contributions and ensuring that all contributions are
known, tracked and dealt with appropriately.

- robert

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message