> > 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. Regards, Les
