Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <24604444.20160108171935@am-soft.de>
References: 
 <CAOqetn8h+pcTw7bm3p5haPGrq4Wb7_nZPsLU+38ByRQti4wYSg@mail.gmail.com>
	<CAAS6=7jS3U0w-fetfwGeP5wpjkURBdUWvA7tOzrM3_D=6nm0hQ@mail.gmail.com>
	<8110117309.20160107100129@am-soft.de>
	<CAKDqugSYZiFwVTpQpDwNEiZuGtXurOmoeGuy_Kc95aVEzOcDdg@mail.gmail.com>
	<CAOqetn-3iGniOU+fGr0QsDDk-RgRvS10_JrrvX+na3FQwurdag@mail.gmail.com>
	<CABD8fLUvLVrVSQ+VFL0p4RfvEVXQFV6gi+fovfYiu4PZPRt8PQ@mail.gmail.com>
	<1088353187.20160107160945@am-soft.de>
	<44b6ae5d105ec214627f92d19a56659e@mail.gmail.com>
	<1293699553.20160107174442@am-soft.de>
	<CABD8fLXTpg_dxNryCFbs7k9K1MzhxBcZ2GYMO+Aa3inV+sL3vA@mail.gmail.com>
	<CAKDqugRWo186Su0EJuFyN++raEKmncEaPn4W6yJWzZbcMMRFcw@mail.gmail.com>
	<1715995338.20160107185322@am-soft.de>
	<CAAS6=7idRPb50nsrNoLSxwtVMcHzTFdbSnbkGDUvkaftoNHCSA@mail.gmail.com>
	<7910314259.20160107195024@am-soft.de>
	<A74B5B4D91021841BC07498282AB9FE6E99C78C7@EXCHMBX03.fed.cclrc.ac.uk>
	<CACsi252ZK-FL9K3hxUB0aa4xt597BdyA_n+nWDv46jXwZ4LxdA@mail.gmail.com>
	<24604444.20160108171935@am-soft.de>
Date: Fri, 8 Jan 2016 12:18:57 -0600
Message-ID: 
 <CACsi252YLLYLb9Z9jCrKwH5rTMecwmY9tEhuO+=jwQxbETpwDw@mail.gmail.com>
Subject: Re: Help for the Log4cxx podling
From: William A Rowe Jr <wrowe@rowe-clan.net>
To: general@incubator.apache.org
Cc: log4cxx-dev@logging.apache.org
Content-Type: multipart/alternative; boundary=089e0122aac2ec74090528d69edb

--089e0122aac2ec74090528d69edb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 8, 2016 at 10:19 AM, Thorsten Sch=C3=B6ning <tschoening@am-soft=
.de>
wrote:

> Guten Tag William A Rowe Jr,
> am Freitag, 8. Januar 2016 um 15:33 schrieben Sie:
>
> > Forty forks means 40 prospective committers.
>
> Or just people, like some of those currently involved, which change
> things once in a while because of bugs or such. I'm always just happy
> if my fixes are simply merged without participating in further
> development too much.


Hallo Thorsten,

Of course, 2 patches doesn't really make a "committer".  Lots of people
file jira tickets, fork code and patch two things, and never look back at
it.
If it solves their problem, they have other things.  But others probably
have
been making minor fixes or even enhancements for a while and it would be
good to invite them all to subscribe to the dev@ list and share their hopes
and thoughts on log4cxx's sustained success.


> > Nothing is solved by "moving"
> > the project to github if their changes are never moved back to the ASF.
>
> I disagree: I'm doing at least some level of support and merge patches
> once a while, depending on their nature and such. The problem now is
> that such an amount of work and "community" ;-) would not be enough
> for your incubation rules and the Apache way, so you would need to
> decide that it's "better" to keep me off the repo entirely instead of
> just letting me do what I'm able to provide AND what is somewhat
> requested by at least some users. That's a decision you make based on
> your project/organisation rules, but it doesn't change if there's at
> least some demand for maintenance of any kind, it's just that the
> project doesn't fit to your rules anymore.
>

Not sure which aspects of ASF's rules you refer to?

If you mean "Projects must ship releases, projects may not point users
at the dev repo - without calling out that this is unreleased code" then if
log4cxx cannot abide, the project needs to be shelved.  The mark stays
at the ASF.  Any fork can pick a new name for itself but it is simply not
"Apache log4cxx" any longer.

If you mean that patches are picked up from github merge requests, vs.
patches must be submitted via Jira, there is no such rule.  If you mean
that it is more convenient to perform git merge requests into an ASF git
repo as the canonical source code tree, that too is being worked on to
simplify the workflow for 'svn adverse' projects.

I'm trying to understand whether we are looking at a cultural refusal to
ever put a post in the stand and say "this is a release, there will be othe=
r
releases, but this is our release as of now"?  Or is this simply a matter
of preferring git to svn?  The former is a requirement, the later is easily
adapted as we clarify how the ASF will insist on a true history of the
project development.  That effort is being pursued and Apache log4cxx
can be accommodated, hopefully in short order.

Hadoop does this today working with git, here's their explanation;
https://wiki.apache.org/hadoop/HowToCommit

There are other rules - invite frequent patch submittors to become new
committers, bring them to the PMC as well based on their contribution,
allow every project participant a voice in the direction of project based
on merit, no a fiefdom.  But I don't expect that was the complaint?

The problem and difference to GitHub I see now with the Attic is, that
> you have a huge, centralized SVN repo, which is very hard to clone for
> interested persons like me for technically reasons. When I tried some
> years ago, you actively blocked me just because I fetched revisions a
> week or so... :-) So if you decide that the project is dead, with the
> same decision you might prevent people access to the very valuable
> history of the project simply for practical reasons, because we are
> not allowed to clone it 2 weeks or the amount of data is just to huge
> with all those empty revisions or whatever.
>

Not familiar with that history so I can't comment.  But Attic code is
abandonware, it exists for others to pick back up, much like we tried
to accomplish by incubating log4cxx.  I'd hate to see that happen if
there are a group of 3+ people who will actively participate in reviewing
and blessing a release candidate, but if Apache log4cxx does not have
those three people, and is not creating any releases, it simply is not
a project.


> If the project is additionally hosted on GitHub and not only in Attic,
> it would be simpler for still interested people to fork and make use
> of it. I see that as somewhat special to Apache's Attic concept, and
> maybe even the use of SVN, though I like SVN a lot: To me it looks
> like that hosting all Attic projects on a platform enabling easier
> forking of the entire project history would be a great idea.
>

I can't say whether a read-only git clone of [all] attic code bases is
a worthwhile idea or not.  The code is accessible from svn so I don't
exactly see why it would be impossible.  But the attic code isn't
maintained, it is fodder for a new group to come together around
bringing it back out of the attic :)

Cheers,

Bill

--089e0122aac2ec74090528d69edb--