incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Les Hazlewood" <>
Subject Re: SVN move
Date Mon, 28 Jul 2008 15:14:56 GMT
> Where I think that there is a problem is when they ditch their old
> infrastructure and exclusively use ASF's infrastructure to build, maintain,
> and release non-ASF releases.  To be sure in the case of JSecurity the final
> artifacts will not use the ASF mirrors but that does not  hide the fact that
> they intend to build and maintain non-ASF releases exclusively using our
> infrastructure.
> Craig says that's fine.
> I think that they should release and maintain their new and earlier non-ASF
> releases on the infrastructure that they currently have or else use ours and
> follow the ASF/Incubator guidelines.

If it turns out that it is *not* OK to do this (use ASF infrastructure
exclusively to maintain our few remaining non-ASF releases), I'm perfectly
ok with that and of course would respect the Incubator's wishes - but I
myself would ask our current JSecurity team to delay the code import into
the ASF.

I don't think I would be willing to perform code modifications and patches
for the next Release Candidate release(s) and maybe the few point releases
that might follow on two different repositories.  That's a nightmare to
maintain - "Did I apply this patch to project-from-server-A and
project-from-server-B?  Hrm.. I can't remember if I JavaDoc'd that method
correctly in both locations...".  No thanks :)

Sure, this might delay our incubation process another few weeks or even a
month or two, but I don't mind that at all - I feel comfortable that
JSecurity will succeed at the ASF, so I don't feel a little extra delay
would hurt things for us much...  This is much less painful IMO than
manually mantaining code in two separate locations.



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