On Fri, Jan 8, 2016 at 10:19 AM, Thorsten Schöning <tschoen...@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 other 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
