On Jul 28, 2008, at 8:14 AM, Les Hazlewood wrote:
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.
Let's turn this around and look at it from a different light. What's
stopping us from doing a 0.9.0 release in the incubator? I'm guessing
that you need the packages to be the same?
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
