community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: What is the legal basis for enforcing release policies at ASF?
Date Fri, 21 Aug 2015 15:16:35 GMT
On Fri, Aug 21, 2015 at 9:58 AM, Bertrand Delacretaz
<> wrote:
> On Fri, Aug 21, 2015 at 3:54 PM, Shawn Heisey <> wrote:
>> ...Their changes do mean that when people come to the solr-user mailing
>> list looking for help, we sometimes have to refer them to the downstream
>> maintainers, because we can't make any sense of where things are....
> To me this is clearly a case that requires those maintainers to change the name.
> Based on your description their code is clearly a fork of Apache Solr,
> and we shouldn't allow people to keep our names for such external
> forks.
> -Bertrand

Are you sure? I would think it's quite common for file locations to
change by a downstream packager, to support the downstream packaging
requirements/conventions. Accumulo has this issue sometimes with
Cloudera and/or Hadoop packaging of Accumulo. We get questions about
errors which don't exist anywhere in Accumulo's source code, or about
classpath problems which apply to the users environment, but not the
vanilla upstream packages we provide from the official source release.

At what point are we growing our community and promoting our
respective projects/brands by encouraging sharing and integration, and
at what point does a downstream packager's action cause us to consider
it a "fork" with the requirement to change the name? If we took a hard
line on this, things would get really crazy... almost no package in a
downstream distro, like Fedora or Ubuntu, would match its upstream
origins (because they are all forked to some extent to make it work in
that environment). And, that would be detrimental. On the other hand,
if we're too soft on this, then substantial forks begin to reflect
badly on the upstream project.

In the case of Solr, it might be the case that it's a substantial
external fork, in need of rebranding. But, if it's just file locations
being moved around to match a distro filesystem layout requirements,
or to do typical distro dependency convergence, backport patches, and
the like, that seems pretty much norm, and it might be a bit too
aggressive to require them to rebrand.

View raw message