On Sat, Jul 26, 2008 at 5:47 AM, Martijn Dashorst < [EMAIL PROTECTED]> wrote:
> On Sat, Jul 26, 2008 at 10:20 AM, Bertrand Delacretaz > <[EMAIL PROTECTED]> wrote: > >> Can you provide one example? Just curious.... > > > > While it was incubating, Wicket did a few non-ASF releases on their > > old project site, to minimize disruption for their existing users > > while they were repackaging and cleaning up for an ASF release. > > And even after we had graduated. Wicket 1.2.7 (the final maintenance > release for the 1.2 branch) was created in last March. We didn't use > the Apache mirroring system and put a disclaimer in it that the > release was non-Apache. [1] In my opinion, this is more important than anything else. If we're going to import our code into ASF SVN, we must still be able to make edits to that code with the intention of releasing those edits later outside of the ASF to our existing community. To bring others up to speed, this is what we're looking at right now: The JSecurity team is trying to release 0.9.0 RC1 to our existing community, with no ties to the ASF. After that is out, it isn't unlikely that a few more changes will need to occur before 0.9.0 Final. (There might even be an RC2, but I hope not - we'll see). After 0.9.0 final is out, only then do I think would we want to call any of our releases an ASF release and go through the Incubator release approval process. Prior to that I have no problem not mentioning ASF anywhere. In other words, we would keep doing things exactly as we have for the last three years, its just we happen to be using ASF SVN hosting instead of SourceForge SVN hosting - that would be the only difference. The reason why this is critiical is if any source code changes go in to say, an 0.9.0 brach, they have to make their way into trunk at the same time - branch merging and all, etc. That would be a nightmare if we have to make these changes manually to two different repositories. If that is forced upon us, I would ask the previous JSecurity dev team to wait to do the code import into ASF until after that time. But I don't like this option - it doesn't attract other ASF developers because they don't have ASF access to the source code - they'd have to join the SF project until the time when the team says they want to do their first ASF release. Not ideal IMO. I don't see the early-import into ASF SVN as a problem though: to me at least, this is one of the things the incubation process helps to resolve - there is nothing IMO wrong with ASF SVN hosting source code for an existing oommunity under the knowledge that it will be actively converted to the ASF community in the process. That's part of migration, which to me, is a key point of incubation for projects with a previous history. Yep, and it really is a problem IMO when incoming *open source* > projects have to ditch their collected history. If we care about code > provenance, having the full history available is best. As far as I'm concerned, ditching history is not an option at all. We need to always be able to compare previous code, maybe resurrect things that were deleted, etc. I'd hate to lose that capability. Martjin, when you guys migrated your source code for Wicket, how did you retain history when it was imported into the Incubator SVN? Did you use 'svnadmin dump' and then load it into the Incubator repository via 'svnadmin load'? Or did you use svnsync? (this is all assuming that your previous repo was already SVN...) Cheers, Les
