Re: Help for the Log4cxx podling

[Marvin Humphrey <ma...@rectangular.com>]

On Mon, Jan 4, 2016 at 5:37 PM, John D. Ament <jo...@apache.org> 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

Re: Help for the Log4cxx podling

[Thorsten Schöning <ts...@am-soft.de>]

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.Schoening@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

AW: Help for the Log4cxx podling

["Wiebesiek, Torsten" <to...@grecon.de>]

Hello log4cxx community,

here's another one against the Attic. :-)

log4cxx is used and needed even though the community is not very large. Actually, the community has never has been very large, and this hasn't been a problem before, when only Curt Arnold maintained the project.

Including log4cxx into another ASF project (like Trafodion) as suggested before, doesn't sound very reasonable in case there's more than one project using log4cxx in the world. And there is. :-)

As long as log4cxx is working well (and it is in our project), I don't see any need for frequent releases. It's probably good to have a new release once in a while just to show, that the project's still active. If a project seems to be dead, it probably won't attract any new users.

So, what do we have to do to keep log4cxx alive? There are probably two important on our agenda:

1. Keep log4cxx out of the Attic (short term)
2. Release a new version (long term)

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?
 
Just my two cents,

  Torsten


-----Ursprüngliche Nachricht-----
Von: Thorsten Schöning [mailto:tschoening@am-soft.de] 
Gesendet: Donnerstag, 7. Januar 2016 19:50
An: general@incubator.apache.org
Cc: Log4CXX Dev
Betreff: 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.Schoening@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

[Greg Stein <gs...@gmail.com>]

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" <ts...@am-soft.de> 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.Schoening@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: Help for the Log4cxx podling

[Greg Stein <gs...@gmail.com>]

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" <ts...@am-soft.de> 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.Schoening@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

RE: Help for the Log4cxx podling

["Dennis E. Hamilton" <de...@acm.org>]

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:johndament@apache.org]
> Sent: Friday, January 8, 2016 17:14
> To: general@incubator.apache.org; dennis.hamilton@acm.org;
> tschoening@am-soft.de
> Subject: Re: Help for the Log4cxx podling
> 
> On Fri, Jan 8, 2016 at 6:06 PM Dennis E. Hamilton
> <de...@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-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Help for the Log4cxx podling

["John D. Ament" <jo...@apache.org>]

On Fri, Jan 8, 2016 at 6:06 PM Dennis E. Hamilton <de...@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

RE: Help for the Log4cxx podling

["Dennis E. Hamilton" <de...@acm.org>]

[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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Help for the Log4cxx podling

[Thorsten Schöning <ts...@am-soft.de>]

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.Schoening@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

["John D. Ament" <jo...@apache.org>]

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 <wr...@rowe-clan.net>
wrote:

>
> On Jan 9, 2016 02:53, "Thorsten Schöning" <ts...@am-soft.de> 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

[William A Rowe Jr <wr...@rowe-clan.net>]

On Jan 9, 2016 02:53, "Thorsten Schöning" <ts...@am-soft.de> 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

[Thorsten Schöning <ts...@am-soft.de>]

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.Schoening@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

[William A Rowe Jr <wr...@rowe-clan.net>]

On Fri, Jan 8, 2016 at 1:10 PM, Thorsten Schöning <ts...@am-soft.de>
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

[Thorsten Schöning <ts...@am-soft.de>]

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.Schoening@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Help for the Log4cxx podling

[Thorsten Schöning <ts...@am-soft.de>]

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.Schoening@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

[William A Rowe Jr <wr...@rowe-clan.net>]

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

Re: Help for the Log4cxx podling

[William A Rowe Jr <wr...@rowe-clan.net>]

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

RE: Help for the Log4cxx podling

["Dennis E. Hamilton" <de...@acm.org>]

[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:tschoening@am-soft.de]
> Sent: Friday, January 8, 2016 08:20
> To: general@incubator.apache.org
> Cc: log4cxx-dev@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Help for the Log4cxx podling

[Thorsten Schöning <ts...@am-soft.de>]

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.Schoening@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Help for the Log4cxx podling

[Thorsten Schöning <ts...@am-soft.de>]

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.Schoening@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

[William A Rowe Jr <wr...@rowe-clan.net>]

On Fri, Jan 8, 2016 at 3:31 AM, <ul...@diamond.ac.uk> 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

[William A Rowe Jr <wr...@rowe-clan.net>]

On Fri, Jan 8, 2016 at 3:31 AM, <ul...@diamond.ac.uk> 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

[ul...@diamond.ac.uk]

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

[ul...@diamond.ac.uk]

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

[Thorsten Schöning <ts...@am-soft.de>]

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.Schoening@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Help for the Log4cxx podling

[Thorsten Schöning <ts...@am-soft.de>]

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.Schoening@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

[Marvin Humphrey <ma...@rectangular.com>]

On Thu, Jan 7, 2016 at 9:53 AM, Thorsten Schöning <ts...@am-soft.de> 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

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Help for the Log4cxx podling

[Marvin Humphrey <ma...@rectangular.com>]

On Thu, Jan 7, 2016 at 9:53 AM, Thorsten Schöning <ts...@am-soft.de> 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

[Thorsten Schöning <ts...@am-soft.de>]

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.Schoening@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

[Thorsten Schöning <ts...@am-soft.de>]

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.Schoening@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Help for the Log4cxx podling

[Rhys Ulerich <rh...@gmail.com>]

> 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

[Rhys Ulerich <rh...@gmail.com>]

> 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

[Greg Stein <gs...@gmail.com>]

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 <ts...@am-soft.de>
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.Schoening@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: Help for the Log4cxx podling

[Greg Stein <gs...@gmail.com>]

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 <ts...@am-soft.de>
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.Schoening@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: Help for the Log4cxx podling

[Thorsten Schöning <ts...@am-soft.de>]

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.Schoening@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Help for the Log4cxx podling

[Thorsten Schöning <ts...@am-soft.de>]

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.Schoening@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

[Roberta Marton <ro...@esgyn.com>]

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?

   Regards
   Roberta Marton

-----Original Message-----
From: Thorsten Schöning [mailto:tschoening@am-soft.de]
Sent: Thursday, January 7, 2016 7:10 AM
To: Greg Stein <gs...@gmail.com>; general@incubator.apache.org
Cc: Log4CXX Dev <lo...@logging.apache.org>
Subject: 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.Schoening@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: Help for the Log4cxx podling

[Roberta Marton <ro...@esgyn.com>]

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?

   Regards
   Roberta Marton

-----Original Message-----
From: Thorsten Schöning [mailto:tschoening@am-soft.de]
Sent: Thursday, January 7, 2016 7:10 AM
To: Greg Stein <gs...@gmail.com>; general@incubator.apache.org
Cc: Log4CXX Dev <lo...@logging.apache.org>
Subject: 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.Schoening@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Help for the Log4cxx podling

[Thorsten Schöning <ts...@am-soft.de>]

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.Schoening@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Help for the Log4cxx podling

[Thorsten Schöning <ts...@am-soft.de>]

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.Schoening@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

[Ralph Goers <ra...@dslextreme.com>]

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 Stein <gs...@gmail.com> wrote:
> 
> On Thu, Jan 7, 2016 at 6:16 AM, John D. Ament <jo...@apache.org> 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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Help for the Log4cxx podling

[Greg Stein <gs...@gmail.com>]

On Thu, Jan 7, 2016 at 6:16 AM, John D. Ament <jo...@apache.org> 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.

Re: Help for the Log4cxx podling

[Greg Stein <gs...@gmail.com>]

On Thu, Jan 7, 2016 at 6:16 AM, John D. Ament <jo...@apache.org> 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.

Re: Help for the Log4cxx podling

["John D. Ament" <jo...@apache.org>]

On Thu, Jan 7, 2016 at 6:32 AM Rhys Ulerich <rh...@gmail.com> wrote:

> > 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/
> <CAKDqugR-iVw2j1SuufSrPiiPAVbBWdsVXyN%2BuT%3D7x8461-ewkA%40mail.gmail.com>
>

Re: Help for the Log4cxx podling

["John D. Ament" <jo...@apache.org>]

On Thu, Jan 7, 2016 at 6:32 AM Rhys Ulerich <rh...@gmail.com> wrote:

> > 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/
> <CAKDqugR-iVw2j1SuufSrPiiPAVbBWdsVXyN%2BuT%3D7x8461-ewkA%40mail.gmail.com>
>

Re: Help for the Log4cxx podling

[Rhys Ulerich <rh...@gmail.com>]

> 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/
<CAKDqugR-iVw2j1SuufSrPiiPAVbBWdsVXyN%2BuT%3D7x8461-ewkA%40mail.gmail.com>

Re: Help for the Log4cxx podling

[Rhys Ulerich <rh...@gmail.com>]

> 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/
<CAKDqugR-iVw2j1SuufSrPiiPAVbBWdsVXyN%2BuT%3D7x8461-ewkA%40mail.gmail.com>

Re: Help for the Log4cxx podling

[Thorsten Schöning <ts...@am-soft.de>]

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.Schoening@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

[Thorsten Schöning <ts...@am-soft.de>]

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.Schoening@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org