This brings up a follow-up question - when Wicket graduated to a TLP, were you able to retain the history while working in the Incubator when you moved to an SVN repo of your own?
On Sat, Jul 26, 2008 at 11:22 AM, Les Hazlewood <[EMAIL PROTECTED]> wrote: > > 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 > >
