On Tue, 2010-07-27 at 11:11 +0100, Ross Gardler wrote: > I'm currently working with the community behind a large and established > codebase that wants to enter the ASF Incubator. It is likely to be a > while before we have the legal stuff sorted out but all indications are > that it will be sorted. > > I do, however, have a few questions from the team that I'm unable to > answer with complete confidence so here goes: > > Their user mailing list has 3000 subscribers and is currently hosted by > Yahoo!. They report that there are problems with getting the information > out of that list. Has anyone here got experience of migrating a yahoo > list, preferably with archives to ASF hardware? What options do we have > if it proves to be problematic?
I would advise just leaving that list as is, with its old archives. Put pointers to these old archives on the new incubator site. You will not be able to autosubscribe users to the new list. They will have to re-subscribe. Autosubscribing would involve migrating information about people between organisations, which fires up loads of data-protection and consent issues. Likewise attempting to migrate the archives could get you caught up in all sorts of copyright/consent issues too. > The project consists of a "core" and then a number of optional modules > that extend the core. At present most of these modules are maintained by > the same community members but are hosted in different projects, in some > cases on different infrastructure, in all cases with different release > cycles. The modules do not useful without the core, that is they cannot > be used with a different implementation of the core. > > Are there any problems bringing these modules into the podling, managing > them under the same community but each having separate release cycles. There is no reason why a podling must release only one resource. The only requirement is that each and every release meet the release requirements, and be vetted by the incubator PMC. Too many separate releases could make this process onerous, and would likely put a significant load on the projects mentors, as the incubator PMC will likely expect them to carry a reasonable amount of that load. > Finally, they have a large number of users and thus changing their java > package names to org.apache.* will create considerable problems for > them. They are happy with the package names but want to do it in a > managed way with plenty of warning for their users. > > Can incubator releases be in package names other than org.apache? Typically projects plan to migrate to org.apache at their next major version. Before that, they keep their old package names for obvious compatibility reasons. Hope that helps. Upayavira --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
