On 8/9/06, Upayavira <[EMAIL PROTECTED]> wrote:
Igor Vaynberg wrote:
<snip>
> 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 necessary. 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 incubator. 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 release.
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
