All conformance ansi-test's passed

[Erik Huelsmann]

Hi all,

On Tue, Aug 25, 2015 at 6:07 PM, Ralph Ritoch <rritoch at gmail.com> wrote:

> Anton & Blake,
>
> One example feature that I hope to support is OSGI. Direct support for
> OSGI will likely cause a significant performance loss. That is why I'm
> going to do a quick optimization of the entire system before I start
> working on the new features. I believe OSGI is scheduled to be included in
> Java 9, along with some new packaging facilities which I also hope to
> support when I can find adequate documentation on the subject. These are
> all features that belong in a fork because they can and probably will have
> a negative impact on the performance of applications that don't need those
> features. I hope to make these features pluggable eventually, but hard
> coding them initially is much easier.
>

If the intent is to migrate things back to the original project in due
time, the open source name for such an effort would be "a remote branch",
not a fork. If you are not aware of this difference, you could start naming
your repository "a branch". If you *are* aware of the difference (and I
think you are, because you already were looking for a different name for
your project, judging by the IRC communication), then I can only say it's a
pity that you didn't have the patience to go through the process that's
customary in open source to get your patches accepted. As an illustration
of what I mean there: my first Mercurial patch was accepted yesterday. My
initial submission was in May or June. Due to time constraints on my side
*and* requirements from theirs, this process simply can take long and
becomes more smooth over time.

Using ant instead of maven is also a limitation I'm not willing to accept.
> Most of the people I've talked to think I should skip maven and go directly
> to a gradle build system. Since gradle can utilize maven, maven is adequate
> for most development needs at this point.
>

Just for the record I'm taking this to the mailing list, because most of
this took place on the mailing list: the project asked to migrate *all*
current functionalities to Maven, if you want to deprecate the Ant build,
not *just* the ones that are needed to make the ABCL upload into the Maven
repository. Our hesitation to accept the Maven based build lies in the fact
that we have had two build systems in the past. Out of experience, we can
say "It doesn't work". So, claiming we don't want to move forward is simply
wrong. We want to do it in a way that doesn't kill half the project's
infrastructure. I'm sure people understand that, if presented this way.

-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20150826/0d8d0dfe/attachment.html>