Re: Help for the Log4cxx podling
Guten Tag Wiebesiek, Torsten, am Dienstag, 26. Januar 2016 um 14:29 schrieben Sie: > I just want to tell, that am willing to prepare a log4cxx release. Sounds good, I just removed the 3 open issues currently assigned to 0.11.0, because if they are not fixed now, they won't be in the short time and at least 2 of those are not even that important to block a release. The original plan was to release as is with only patches applied anyway. 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
Re: Help for the Log4cxx podling
On Mon, Jan 11, 2016 at 3:18 AM, Wiebesiek, Torsten < torsten.wiebes...@grecon.de> wrote: > > > If not you, then ...? Are there other committers who are interesting > > > in taking the release mantle, and really give yourself breathing room > > > to just improve the code without all the rest of the details? > > > > Torsten Wiebesiek seemed interested to read the details about the > > release process, so we might wait the next days to see what he says. > > I've read the "Guide To Release Management During Incubation" and I have > to admit, that I have not understood all of it. I am sure, there are many > people who can do this job better. > > I am still willing to help out, but I will definitely need help at least > for the first release. > More than happy to provide mentorship if the project is on a path to releasing and graduating from the incubator... > But again, what do we need to keep log4cxx out of the attic? > > - Someone, who prepares a release. Ok, that might be me (with someone > help!). > Yup, that is the key issue at hand. > - Some people, who vote for a release? How many people do we need? What > qualifications do they have to have? > There must be three PPMC members of this project who vote the release +1 (and more +1 than -1). That is the demonstration that this project can be graduated soon and will be self-sufficient in the future. Anyone can chime in with a vote, and is encouraged to do so! Generally the PPMC will be listening to the dev list and non-committer input when things are not looking quite right. As a practical matter, three IPMC members need to also vote +1, but don't dwell on that detail, you have us. And we will be looking to log4cxx PPMC members and committers in considering our own votes, along with the licensing and other higher level policy issues. Knowing the provenance of the code, I don't expect to find other issues in the release candidate, unless something is overlooked like including the LICENSE or NOTICE file. > - Some more developers? Or is it for now ok, if Thorsten is doing the main > Development? > It's OK for each of the committers to contribute as much or little time as they can invest in the project. There must be at least 3 and perhaps even 5 (some redundancy so it doesn't slip below 3). Commits might be as simple as shepherding other drive-by patches into vcs. > - Do we have a deadline for the release or some kind of time frame? > IMHO, no, but if I jump aboard as a mentor, I'm hoping to help you all succeed with graduation in the next couple months. > Unfortunately, I am very busy right now (and will be for this week). I > will follow the discussion and maybe answer some mails, but can dig deeper > into this ASF stuff next week. > Same here, as a mentor I can offer the 10k foot perspective, but as yet another C[++] programmer, should be able to help a little more than just guidance emails :) Hoping to dig into the code in the next two weeks. > Still, it's not worth doing that, if we have not answered the most > important question: > > What do we have to do, to keep log4cxx alive at ASF? > You covered it; at least three active participants, activity is defined as making a release every so often (requires 3+ PMC voters), directing users to the released version in http://www.apache.org/dist/log4cxx/ (and directing only contributor/participants to the unreleased working effort in the vcs and resources in http://log4cxx.apache.org/dev/, that is effectively anyone who would participate or follow dev@). Other great things are supporting users (a users list or equivilant), following the bug trackers and patch submissions, etc.
Re: Help for the Log4cxx podling
> > If not you, then ...? Are there other committers who are interesting > > in taking the release mantle, and really give yourself breathing room > > to just improve the code without all the rest of the details? > > Torsten Wiebesiek seemed interested to read the details about the > release process, so we might wait the next days to see what he says. I've read the "Guide To Release Management During Incubation" and I have to admit, that I have not understood all of it. I am sure, there are many people who can do this job better. I am still willing to help out, but I will definitely need help at least for the first release. But again, what do we need to keep log4cxx out of the attic? - Someone, who prepares a release. Ok, that might be me (with someone help!). - Some people, who vote for a release? How many people do we need? What qualifications do they have to have? - Some more developers? Or is it for now ok, if Thorsten is doing the main Development? - Do we have a deadline for the release or some kind of time frame? - What else? And last, but not least: is the code in a state that allows a release any time soon? Unfortunately, I am very busy right now (and will be for this week). I will follow the discussion and maybe answer some mails, but can dig deeper into this ASF stuff next week. Still, it's not worth doing that, if we have not answered the most important question: What do we have to do, to keep log4cxx alive at ASF? Regards, Torsten
Re: Help for the Log4cxx podling
Guten Tag William A Rowe Jr, am Samstag, 9. Januar 2016 um 18:26 schrieben Sie: > While we are waiting to find out who is interested in the heavy > lifting of creating a release candidate, who here is willing to > review such candidates and cast a +/-1 vote for release of the > package? Which of the following links would be the ones the project members need to care about in the release process? We wouldn't vote for the incubator release, because we are the subjects to vote on, right? But what about the release candidate, that's the one we need to review within the project ourselfs and vote for that until we are satisfied? Afterwards the release manager would end up doing what is mentioned for the incubator release and people like John D. Ament would vote on that, completely outside the project? Or does the project never vote "internally" at all, but only deals with -1 votes for the incubator release and needs to fix bugs and such until all external voters are satisfied? I'm not sure if there are two independent votes or such one and if the project members itself are part of those. http://incubator.apache.org/guides/releasemanagement.html#best-practice-incubator-release-vote http://incubator.apache.org/guides/releasemanagement.html#best-practices-release-candidates 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
Re: Help for the Log4cxx podling
Assuming the release can be compiled on fedora, I can review and vote on it (as an IPMC member). John On Sat, Jan 9, 2016 at 12:26 PM William A Rowe Jr wrote: > > On Jan 9, 2016 02:53, "Thorsten Schöning" wrote: > > > > Guten Tag William A Rowe Jr, > > am Freitag, 8. Januar 2016 um 23:54 schrieben Sie: > > > > > If not you, then ...? Are there other committers who are interesting > in taking > > > the release mantle, and really give yourself breathing room to just > improve > > > the code without all the rest of the details? > > > > Torsten Wiebesiek seemed interested to read the details about the > > release process, so we might wait the next days to see what he says. > > While we are waiting to find out who is interested in the heavy lifting of > creating a release candidate, who here is willing to review such candidates > and cast a +/-1 vote for release of the package? The review period should > rarely be shorter than 72 hours but I've seen 10 day review periods for > projects with especially small communities. > > As an aside the ASF only 'releases' the source code. Some projects create > convenience binaries but they are not the subject of the vote. Some > projects refuse to create binaries as a matter of policy (Subversion, for > example.) >
Re: Help for the Log4cxx podling
On Jan 9, 2016 02:53, "Thorsten Schöning" wrote: > > Guten Tag William A Rowe Jr, > am Freitag, 8. Januar 2016 um 23:54 schrieben Sie: > > > If not you, then ...? Are there other committers who are interesting in taking > > the release mantle, and really give yourself breathing room to just improve > > the code without all the rest of the details? > > Torsten Wiebesiek seemed interested to read the details about the > release process, so we might wait the next days to see what he says. While we are waiting to find out who is interested in the heavy lifting of creating a release candidate, who here is willing to review such candidates and cast a +/-1 vote for release of the package? The review period should rarely be shorter than 72 hours but I've seen 10 day review periods for projects with especially small communities. As an aside the ASF only 'releases' the source code. Some projects create convenience binaries but they are not the subject of the vote. Some projects refuse to create binaries as a matter of policy (Subversion, for example.)
Re: Help for the Log4cxx podling
Guten Tag William A Rowe Jr, am Freitag, 8. Januar 2016 um 23:54 schrieben Sie: > If not you, then ...? Are there other committers who are interesting in > taking > the release mantle, and really give yourself breathing room to just improve > the code without all the rest of the details? Torsten Wiebesiek seemed interested to read the details about the release process, so we might wait the next days to see what he says. 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
Re: Help for the Log4cxx podling
On Fri, Jan 8, 2016 at 1:10 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. > Dropping general@ for now... If not you, then ...? Are there other committers who are interesting in taking the release mantle, and really give yourself breathing room to just improve the code without all the rest of the details? The lack of 'releases' will no doubt hobble the adoption of this code base, as many potential consumers will look at the release history and determine the code is already DoA. But that shouldn't put us off from continuing as an incubating project, if some of the other contributors would like to more actively participate and help push releases of the stable code between bug and enhancement spurts. Anyone willing to step up?
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
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
Re: Help for the Log4cxx podling
On Fri, Jan 8, 2016 at 10:19 AM, Thorsten Schöning 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 toget
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
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
Hi, > I am not familiar with the Apache requirements for a project. From > what I understand, there have to be reports filed every three month. > What else? How can we proceed with the limited resources, we have? > The reports every 3 months shouldn't be a big problem, but you need > to do e.g. votes for releases as well, they need to be signed off > and we currently don't even have a mentor signing off our incubator > reports and such. > > You want details? :-) > > http://incubator.apache.org/guides/releasemanagement.html wow! I am going to read this on the weekend. That will probably be much fun. ;-) > If binary releases are not a must for Apache, which I didn't know > before, in my opinion we should simply reduce to a source release > and don't even care about the build tools too much. If things > don't work as they are, people will create tickets in JIRA and > hopefully provide patches. cpptasks for our ant based build is not > maintained anymore, so I would suggest to cut it off with autoconf > for non-Windows and documentation and maybe template project files > in some "contrib" for Windows. Source only releases sound good to me, and the build process should be held as simple as possible too. One of my problems with log4cxx has always been, that there had been multiple ways to build the project and all had there flaws on our platform (Windows/Visual Studio). log4cxx need one well documented cross platform build process. Last time I dug into autotools (at least ten years ago), they already appeared to be overly complicated. Ant/Maven seemed to be a relict from log4j and needs a Java environment only to build a c++ library. What do you think about changing to cmake? That should work on Linux, Windows and Mac OS. > I don't know how others work, but with my Windows-IDE I need to > create custom projects all the time for various reasons. What do you need these custom projects for? Testing within VS? > But in the end it all boils down to if someone will follow the > official release process. Yes, but first, we have to keep log4cxx out of the Attic. And it might be easier to deal with details (e.g. build process, release process) in separate threads? that -- Regards Torsten
Re: Help for the Log4cxx podling
Guten Tag Wiebesiek, Torsten, am Freitag, 8. Januar 2016 um 11:16 schrieben Sie: > I am not familiar with the Apache requirements for a project. From > what I understand, there have to be reports filed every three month. > What else? How can we proceed with the limited resources, we have? The reports every 3 months shouldn't be a big problem, but you need to do e.g. votes for releases as well, they need to be signed off and we currently don't even have a mentor signing off our incubator reports and such. You want details? :-) http://incubator.apache.org/guides/releasemanagement.html We need one who really wants to make himself familiar with this process and is afterwards responsible for doing the release. If binary releases are not a must for Apache, which I didn't know before, in my opinion we should simply reduce to a source release and don't even care about the build tools too much. If things don't work as they are, people will create tickets in JIRA and hopefully provide patches. cpptasks for our ant based build is not maintained anymore, so I would suggest to cut it off with autoconf for non-Windows and documentation and maybe template project files in some "contrib" for Windows. I don't know how others work, but with my Windows-IDE I need to create custom projects all the time for various reasons. But in the end it all boils down to if someone will follow the official release process. 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
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 Thu, Jan 7, 2016 at 9:53 AM, Thorsten Schöning wrote: > So even if we are to dead for the incubator, we are to alive for the > attic. If you can't make a release, you're dead enough for the Attic. Marvin Humphrey
Re: Help for the Log4cxx podling
> Or clone/fork it into Trafodion, if you need updates or continued maintenance. Any chance apr-util could pick up the torch? That would at least centralize it as anyone needing log4cxx needs apr-util. - Rhys
Re: Help for the Log4cxx podling
Or clone/fork it into Trafodion, if you need updates or continued maintenance. Look at it as just another component (rather than a separate project). On Thu, Jan 7, 2016 at 10:44 AM, Thorsten Schöning wrote: > 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
> 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 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 Marvin Humphrey, am Donnerstag, 7. Januar 2016 um 04:59 schrieben Sie: > 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. Looking at the SVN history, Curt Arnold seemed to be the only active developer in the project for years. > 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. Attic seems to be the "no one cares anymore" place for Apache projects, but that's not the case if log4cxx still receives at least some feedback by users. But of course you are absolutely right about the incubation process: It doesn't look like there's other members still around, one doesn't know if this ever changes again and I do know that officially releasing software just to correspond to some Apache process has a very low priority on my todo list, because of the reasons already mentioned in your former quote. The most important thing for me is that there's someone "out there" providing at least some level of support AND is able to commit, in my opinion folks can handle things like missing releases. If this is not enough for the Apache way and/or incubation process, then feel free to move log4cxx into Attic. But in that case I would like to ask if we can create a GitHub repo for the project so people like me are able to fork it and easier merge patches of other users who may still be around. There's already one, but that lacks the incubating history. We can make clear in the README that it's unsupported and dead and whatever you like, just don't please lock the current(!) history of the project away behind a door. https://github.com/apache/log4cxx 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
Re: Help for the Log4cxx podling
On Mon, Jan 4, 2016 at 5:37 PM, 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. 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
