Re: Help for the Log4cxx podling
I have to point out that all of this is exactly why the project moved to the incubator from the logging project. While all the logging projects are obviously related by what they do, the language and implementation differences make it difficult for committers to cross over from one project to the other so it was hoped going to incubator would signal people interested in the project to get involved. Having said that, Log4j 1.x has barely had any life for years, was recently marked as end-of-life and still has a huge number of users using it and periodically asking for fixes that will never happen. It is still the most used logging framework. While Log4j 2 is in much better shape, we too have a hard time attracting committers. We get lots of people submitting one time patches but very few stick around. I don’t know if it is just because working on logging isn’t as sexy as working on a NoSQL thingy or what, but all the logging projects have trouble attracting new committers, even though they still seem to be quite popular and people still seem to expect them to magically have new releases. Ralph > On Jan 7, 2016, at 5:31 AM, Greg Steinwrote: > > On Thu, Jan 7, 2016 at 6:16 AM, John D. Ament wrote: > >> ... >> Your lack of mentors is probably the biggest issue on the incubator side. >> Without mentors, you have no one to steer you through graduation. Though >> Marvin raises a good point - you're coming from an existing TLP, not only >> would incubation be optional if the logging TLP chose to bring you in, but >> having the backing of logging likely means there are other existing members >> out there that can help you through incubation. >> > > They arrived from an existing TLP, and have been around for a LONG time. I > don't think Mentors are the problem at all. ... there is simply no > community. (and Mentors will not and cannot solve that) > > IMO, close it down. > > Cheers, > -g > > ps. as ALv2 source, of course anybody willing can clone it elsewhere, but > may need to change the name. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Help for the Log4cxx podling
On Fri, Jan 8, 2016 at 10:19 AM, Thorsten Schöningwrote: > 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
Re: Help for the Log4cxx podling
Have no fear, we can extract all history from the svn repo. I don't know what approach you used, such that your IP was auto-banned, but that can be solved. We've done this before. So: please don't worry about that, within this discussion. On Jan 8, 2016 1:11 PM, "Thorsten Schöning"wrote: > Guten Tag William A Rowe Jr, > am Freitag, 8. Januar 2016 um 19:18 schrieben Sie: > > > 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? > > Holy shit no, this is by no means the start of a SCM flamewar, I like > and still prefer SVN very much, we use it at our company extensively. > My problem is really only about the release and incubation part and in > the end, if I'm going to keep my commit permissions to the "current" > codebase and history or not. I simply won't have the time to go > through the release process myself, I thought I have it when the > incubation process started, but it didn't work the last 2 years, so I > guess it won't work the next 2... And with that in mind, I'm just > checking the possibilities to keep any somewhat writable permissions > to the codebase for me. > > GitHub is only one possible anchor, which is simply better suited for > my needs than the Attic, because I could fork with keeping the > history. And if the project doesn't succeed the incubation process > now, it surely won't ever leave the Attic again. > > > [...]but if Apache log4cxx does not have > > those three people, and is not creating any releases, it simply is not > > a project. > > And that's fine, but that doesn't necessary mean that you need to "lock > away" the history. But I may completely wrong and it wouldn't be > allowed to even fork a dead Apache log4cxx on GitHub to keep working > on it with the history, even privately? > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de > AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > > Telefon...05151- 9468- 55 > Fax...05151- 9468- 88 > Mobil..0178-8 9468- 04 > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Help for the Log4cxx podling
On Fri, Jan 8, 2016 at 6:06 PM Dennis E. Hamiltonwrote: > [not cross-posting] > Just curious - but why? The hope is to collaborate between the two groups to get a consensus. > > If there is a read-only GitHub mirror of the in-attic SVN repository > subtree, will that provide enough history for you? > > Or would you actually require a (compressed) dump of the read-only SVN > repository subtree (not the entire ASF subversion), assuming Apache Infra > could provide that without creating any unacceptable SVN lock-out duration? > > [I am operating on the assumption that the repository in the attic has the > entire history of the project's repository tree at the time of movement to > the attic. It is simply read-only forever.] > > - Dennis > > > [ ... ] > > And that's fine, but that doesn't necessary mean that you need to "lock > > away" the history. But I may completely wrong and it wouldn't be > > allowed to even fork a dead Apache log4cxx on GitHub to keep working > > on it with the history, even privately? > > > > Mit freundlichen Grüßen, > > > > Thorsten Schöning > [ ... ] > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
RE: Help for the Log4cxx podling
[not cross-posting] If there is a read-only GitHub mirror of the in-attic SVN repository subtree, will that provide enough history for you? Or would you actually require a (compressed) dump of the read-only SVN repository subtree (not the entire ASF subversion), assuming Apache Infra could provide that without creating any unacceptable SVN lock-out duration? [I am operating on the assumption that the repository in the attic has the entire history of the project's repository tree at the time of movement to the attic. It is simply read-only forever.] - Dennis [ ... ] > And that's fine, but that doesn't necessary mean that you need to "lock > away" the history. But I may completely wrong and it wouldn't be > allowed to even fork a dead Apache log4cxx on GitHub to keep working > on it with the history, even privately? > > Mit freundlichen Grüßen, > > Thorsten Schöning [ ... ] - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Help for the Log4cxx podling
Guten Tag William A Rowe Jr, am Freitag, 8. Januar 2016 um 19:18 schrieben Sie: > 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? Holy shit no, this is by no means the start of a SCM flamewar, I like and still prefer SVN very much, we use it at our company extensively. My problem is really only about the release and incubation part and in the end, if I'm going to keep my commit permissions to the "current" codebase and history or not. I simply won't have the time to go through the release process myself, I thought I have it when the incubation process started, but it didn't work the last 2 years, so I guess it won't work the next 2... And with that in mind, I'm just checking the possibilities to keep any somewhat writable permissions to the codebase for me. GitHub is only one possible anchor, which is simply better suited for my needs than the Attic, because I could fork with keeping the history. And if the project doesn't succeed the incubation process now, it surely won't ever leave the Attic again. > [...]but if Apache log4cxx does not have > those three people, and is not creating any releases, it simply is not > a project. And that's fine, but that doesn't necessary mean that you need to "lock away" the history. But I may completely wrong and it wouldn't be allowed to even fork a dead Apache log4cxx on GitHub to keep working on it with the history, even privately? Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Help for the Log4cxx podling
Aside to John: No particular reason other than I find it confusing whether I am subscribed to both lists or not. I just wanted to understand the technical objection. Greg's response settled the only concern I could see. - Dennis > -Original Message- > From: John D. Ament [mailto:johndam...@apache.org] > Sent: Friday, January 8, 2016 17:14 > To: general@incubator.apache.org; dennis.hamil...@acm.org; > tschoen...@am-soft.de > Subject: Re: Help for the Log4cxx podling > > On Fri, Jan 8, 2016 at 6:06 PM Dennis E. Hamilton > <dennis.hamil...@acm.org> > wrote: > > > [not cross-posting] > > > > Just curious - but why? The hope is to collaborate between the two > groups > to get a consensus. > > > > > > If there is a read-only GitHub mirror of the in-attic SVN repository > > subtree, will that provide enough history for you? > > > > Or would you actually require a (compressed) dump of the read-only SVN > > repository subtree (not the entire ASF subversion), assuming Apache > Infra > > could provide that without creating any unacceptable SVN lock-out > duration? > > > > [I am operating on the assumption that the repository in the attic has > the > > entire history of the project's repository tree at the time of > movement to > > the attic. It is simply read-only forever.] > > > > - Dennis > > > > > > [ ... ] > > > And that's fine, but that doesn't necessary mean that you need to > "lock > > > away" the history. But I may completely wrong and it wouldn't be > > > allowed to even fork a dead Apache log4cxx on GitHub to keep working > > > on it with the history, even privately? > > > > > > Mit freundlichen Grüßen, > > > > > > Thorsten Schöning > > [ ... ] > > > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Help for the Log4cxx podling
As a user (and small time contributor once) of log4cxx, I would vote for a move to a central hosting on github. I don't mind what happens to the project in terms of the apache organization as I use log4cxx as a stand-alone library - and I guess many others use log4cxx in the same fashion. However, putting it in a read-only repo is effectively declaring it dead and forcing everyone who uses it to either create individual forks or rewrite code using alternative libraries. That will be a shame for a library that probably for most users (me certainly) Just Works :-) The trouble on github at the moment is that there are up to 40 potential forks on there with no central one - as the github.com/apache/log4cxx is very out-of-date... Just my £0.02 worth... Cheers, Ulrik -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
Re: Help for the Log4cxx podling
On Fri, Jan 8, 2016 at 3:31 AM,wrote: > As a user (and small time contributor once) of log4cxx, I would vote for a > move to a central hosting on github. I don't mind what happens to the > project in terms of the apache organization as I use log4cxx as a > stand-alone library - and I guess many others use log4cxx in the same > fashion. However, putting it in a read-only repo is effectively declaring > it dead and forcing everyone who uses it to either create individual forks > or rewrite code using alternative libraries. That will be a shame for a > library that probably for most users (me certainly) Just Works :-) > In the ASF, "creating open source software for the public good" means releasing it. I am happy to sign up to mentor the project out of the incubator, but that should be a 12 week project, tops. We would need to see commits from at least three and preferably five committers. Who are these people? > The trouble on github at the moment is that there are up to 40 potential > forks on there with no central one - as the github.com/apache/log4cxx is > very out-of-date... > Forty forks means 40 prospective committers. Nothing is solved by "moving" the project to github if their changes are never moved back to the ASF. It's not enough to simply apply all of the merge requests; the ASF strongly holds that we don't do 'one man shows'. We work to attract many committers and prevent the benevolent-dictator-for-life and hit-by-a-bus conundrums. So if the project demonstrates that they can 1. recruit at least a handful of the github fork maintainers to participate at log4cxx and sign on as committer/ppmc members, and 2. assemble a 0.11 release candidate, review and vote to release it, I'll jump on to ease the transition to a full fledged PMC. If that PMC wants to move from svn to git as their primary development history, work is in progress at the ASF to facilitate that. There is a functional place to further develop the software here. But if these two things can't happen, this is past time to land in the attic for others to run with elsewhere. Either it is effectively in the attic with no code changes anyways, or these code changes aren't being released to the public, but users are being directed to use the bleed dev repo, which is against the spirit of the ASF's release early and release often policy.
Re: Help for the Log4cxx podling
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. > 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. 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. 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. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Help for the Log4cxx podling
[Not cross-posted] This is not about the governance issues raised in the discussion. Technically, I do not understand what is difficult about creating working copies of a project's portion of the ASF SVN repository. It is done all of the time, for presumably much larger projects. If you mean a full backup with all history, that is a different matter. An attic SVN would still have all of that though. In any case, projects now have the option of creating a read-only Git mirror of their SVN, and there are a number of those hosted on GitHub, cloned, forked, etc. That could clearly be done for a project with its SVN in the attic. (I have no idea whether the history is as complete as what abides in the SVN.) These are not Gits of the entire ASF repo. The Git mirror has just the project's slice. What is not part of the current use of Git mirrors (whether on an ASF SVN or Git) is a way to accept Git push requests at the mirror in a manner that sustains ASF requirements for provenance and auditability of contributions, with assurance that IP matters are dealt with in accord with policy. My impression is that there is work underway to address that. However, this relates to ASF project governance policies and practices and that may not be helpful in how log4xx might be sustained. It would not apply to a project in the attic regardless. > -Original Message- > From: Thorsten Schöning [mailto:tschoen...@am-soft.de] > Sent: Friday, January 8, 2016 08:20 > To: general@incubator.apache.org > Cc: log4cxx-...@logging.apache.org > Subject: Re: Help for the Log4cxx podling > [ ... ] > 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. > > 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. [ ... ] - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Help for the Log4cxx podling
On Thu, Jan 7, 2016 at 6:32 AM Rhys Ulerichwrote: > > It doesn't look like there's other members still around > > I'm still lurking but have not touched the code for awhile. > > It is, and has been, unclear what needs to happen for a 0.11.0 release > candidate [1]. Much of the problem is that there's no concensus on what > build system should work. Autotools, Maven, and some collection of Windows > IDE projects all exist in various states. Many user questions involve the > latter, which Thorsten fields impressively well. > > The remainder of the release - readiness concerns voiced since incubation > involve Windows thread safely to which I cannot speak. Again, Thorsten > fields these and has nudged the code forward as he has been able. > I dunno - its been too long since I've had to deal with C/C++. The ASF looks for a release of source code, convenience binaries are not required. If your main issue is a build system, I would include the ability to run all three you've listed (if possible - though it should be) allowing users to compile themselves. Your lack of mentors is probably the biggest issue on the incubator side. Without mentors, you have no one to steer you through graduation. Though Marvin raises a good point - you're coming from an existing TLP, not only would incubation be optional if the logging TLP chose to bring you in, but having the backing of logging likely means there are other existing members out there that can help you through incubation. > I believe we can get a release out if we can decide on what it must > contain, and how it must build. Following APR on a build process would be > ideal but I have not been able to glean which build system(s?) of theirs > they consider blessed. > > - Rhys > > [1] > http://mail-archives.apache.org/mod_mbox/logging-log4cxx-dev/201410.mbox/ > >
Re: Help for the Log4cxx podling
Guten Tag Greg Stein, am Donnerstag, 7. Januar 2016 um 13:31 schrieben Sie: > ps. as ALv2 source, of course anybody willing can clone it elsewhere, but > may need to change the name. What I meant was to let @infra create one official/original/whatever git repo/mirror containing the current history before moving to Attic, like they did for the project before and do for other projects, even from the incubator. Same like the following: https://github.com/apache/incubator-rya Or even something like: https://github.com/apache/attic-log4cxx Getting the SVN history from the huge Apache repo is very time consuming and creates a large repo of mostly empty revisions. When I did it the last time some years ago, @infra seemed to even block my dynamic IPs after some hours of fetching. :-) That's something I would like to avoid if @infra has more efficient ways to deal with this. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Help for the Log4cxx podling
On Thu, Jan 7, 2016 at 6:16 AM, John D. Amentwrote: > ... > Your lack of mentors is probably the biggest issue on the incubator side. > Without mentors, you have no one to steer you through graduation. Though > Marvin raises a good point - you're coming from an existing TLP, not only > would incubation be optional if the logging TLP chose to bring you in, but > having the backing of logging likely means there are other existing members > out there that can help you through incubation. > They arrived from an existing TLP, and have been around for a LONG time. I don't think Mentors are the problem at all. ... there is simply no community. (and Mentors will not and cannot solve that) IMO, close it down. Cheers, -g ps. as ALv2 source, of course anybody willing can clone it elsewhere, but may need to change the name.
Re: Help for the Log4cxx podling
Guten Tag Roberta Marton, am Donnerstag, 7. Januar 2016 um 17:14 schrieben Sie: > Just curious. The product I work on, Apache Trafodion, uses log4cxx. If the > incubator goes to the "Attic", what does that mean to products that are > using the code? No development of any kind, I think of it as a read only repo. http://attic.apache.org Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Help for the Log4cxx podling
Guten Tag Rhys Ulerich, am Donnerstag, 7. Januar 2016 um 18:22 schrieben Sie: > Any chance apr-util could pick up the torch? That would at least centralize > it as anyone needing log4cxx needs apr-util. And who would get commit access then, would we be able to keep ours? I doubt it. The traffic on the APR mailing list seems to be dominated by SVN as well, e.g. some of my threads and reported bugs were ignored like those of others, they have their own Bugzilla instead of JIRA etc. I don't think this would make it any better for Log4cxx and if I remember correctly, apr-util was discussing removing e.g. expat, so I don't think they want to include another new project of our size. I wouldn't if I was them. :-) Let's focus on the main point again: Log4cxx is used, there are still users somewhat interested in the project and there are people willing to provide at least support, apply bug fixes and if needed I will report the same contents every 3 months over and over again... ;-) So even if we are to dead for the incubator, we are to alive for the attic. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Help for the Log4cxx podling
Guten Tag Marvin Humphrey, am Donnerstag, 7. Januar 2016 um 18:57 schrieben Sie: > If you can't make a release, you're dead enough for the Attic. According to the logs, the former maintainer Curt Arnold didn't release for years as well after the project moved to Apache and nevertheless provided the majority of work on it and made users happy. Let's agree that we disagree and we have two votes for the Attic right now. :-/ Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Help for the Log4cxx podling
On Mon, Jan 4, 2016 at 5:37 PM, John D. Amentwrote: > Hi all, > > I happened to stumble upon the log4cxx mailing list where there is concern > over mentor participation. It appears that they may need help, more mentor > participation to help get reports through. > > They're a small podling, so I'm wondering if there's ways to help them out? > It seems like Christian G was their main mentor, but he may be a bit busy > right now. Christian is a great guy and if it were possible for him to stay on as Mentor he would -- but he has effectively resigned. I have now taken the liberty of removing his name from the log4cxx2 project page and from podlings.xml. People come and go in open source. Apache podlings and projects have to be able to adapt. That leaves only Scott Deboy listed as Mentor, who is not heavily involved in the Incubator. The log4cxx reports have not been getting Mentor signoff, which is why this has come to a head. What we need to do first is review the why log4cxx wound up in the Incubator and assess what the desired end state is. This is an unusual podling in that it originated with an existing Apache subproject. Here's an excerpt from the proposal to re-enter the Incubator: http://wiki.apache.org/incubator/Log4cxxProposal The original developers of the project went inactive and the project was not maintained for quite a while. The Logging PMC thought about moving the project to the attic but a few users were objecting. This proposal is to create a new community around Log4cxx. So, has this happened? Has a healthy Apache community emerged which is self-governing and self-sustaining? If not, what do we do? If we retire the podling, does the project go into the Attic? Does it become the Logging PMC's problem again (which seems wrong)? In my view, the podling contributors need to step up and make the case stay in incubation, then recruit new Mentors. A podling which does not have active Mentors cannot remain in incubation. One significant statistic: there have been no releases since 2008. Here's a comment that was left when someone opened a JIRA issue asking for a release: https://issues.apache.org/jira/browse/LOGCXX-459 While I can totally understand your wish, I consider JIRA the wrong place for discussing such things and therefore close this issue. The user mailing list is the better place but even there it's likely that I would be the only one answering that I'm currently unable to do a release because I simply lack the time, knowledge and maybe even tools to do so. So if you need current src, just check it out from SVN and let us deal with things don't working this way on the user mailing list. This is not acceptable. Apache projects *must* make official releases and they must direct users towards those releases and not towards raw version control. The community has one active developer as far as I can tell, and at least he is responding to user inquiries when they come in. But one developer does not make an Apache community. The project has had a long and successful run, but I think the time has come for Log4CXX to consider retiring and heading to the Attic. PS: I have CC'd this message to log4cxx-dev@logging.apache after first subscribing to ensure that the message does not get stuck in an untended moderation queue. Anyone who wants to participate in this thread, I urge that you subscribe to general@incubator. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Help for the Log4cxx podling
Hi John, thanks for the warning. Just saw the thread between Thorsten and you on the mailing list. Let me try to take a look tomorrow. Maybe we can talk together directly tomorrow, wdyt ? Regards JB On 01/05/2016 02:37 AM, John D. Ament wrote: Hi all, I happened to stumble upon the log4cxx mailing list where there is concern over mentor participation. It appears that they may need help, more mentor participation to help get reports through. They're a small podling, so I'm wondering if there's ways to help them out? It seems like Christian G was their main mentor, but he may be a bit busy right now. John -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Help for the Log4cxx podling
Hi all, I happened to stumble upon the log4cxx mailing list where there is concern over mentor participation. It appears that they may need help, more mentor participation to help get reports through. They're a small podling, so I'm wondering if there's ways to help them out? It seems like Christian G was their main mentor, but he may be a bit busy right now. John