incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Les Hazlewood" <>
Subject Re: SVN move
Date Sat, 26 Jul 2008 15:22:27 GMT
On Sat, Jul 26, 2008 at 5:47 AM, Martijn Dashorst <> wrote:

> On Sat, Jul 26, 2008 at 10:20 AM, Bertrand Delacretaz
> <> 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...)



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message