RE: Help for the Log4cxx podling

[Dennis E. Hamilton]

Aside to John:

No particular reason other than I find it confusing whether I am subscribed to 
both lists or not.

I just wanted to understand the technical objection.  Greg's response settled 
the only concern I could see.

 - Dennis

> -Original Message-
> From: John D. Ament [mailto:johndam...@apache.org]
> Sent: Friday, January 8, 2016 17:14
> To: general@incubator.apache.org; dennis.hamil...@acm.org;
> tschoen...@am-soft.de
> Subject: Re: Help for the Log4cxx podling
> 
> On Fri, Jan 8, 2016 at 6:06 PM Dennis E. Hamilton
> 
> wrote:
> 
> > [not cross-posting]
> >
> 
> Just curious - but why? The hope is to collaborate between the two
> groups
> to get a consensus.
> 
> 
> >
> > If there is a read-only GitHub mirror of the in-attic SVN repository
> > subtree, will that provide enough history for you?
> >
> > Or would you actually require a (compressed) dump of the read-only SVN
> > repository subtree (not the entire ASF subversion), assuming Apache
> Infra
> > could provide that without creating any unacceptable SVN lock-out
> duration?
> >
> > [I am operating on the assumption that the repository in the attic has
> the
> > entire history of the project's repository tree at the time of
> movement to
> > the attic.  It is simply read-only forever.]
> >
> >  - Dennis
> >
> >
> > [ ... ]
> > > And that's fine, but that doesn't necessary mean that you need to
> "lock
> > > away" the history. But I may completely wrong and it wouldn't be
> > > allowed to even fork a dead Apache log4cxx on GitHub to keep working
> > > on it with the history, even privately?
> > >
> > > Mit freundlichen Grüßen,
> > >
> > > Thorsten Schöning
> > [ ... ]
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >


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

Re: Concerted may be in need of help

[Chris Nauroth]

Accept

--Chris Nauroth

From: Ross Gardler 
mailto:ross.gard...@microsoft.com>>
Date: Friday, January 8, 2016 at 7:54 PM
To: "general@incubator.apache.org" 
mailto:general@incubator.apache.org>>
Cc: 
"d...@concerted.incubator.apache.org"
 
mailto:d...@concerted.incubator.apache.org>>,
 Atri Sharma mailto:atri.j...@gmail.com>>
Subject: RE: Concerted may be in need of help

+1

Sent from my Windows Phone

From: Roman Shaposhnik
Sent: ?1/?8/?2016 7:35 PM
To: general@incubator.apache.org
Cc: 
d...@concerted.incubator.apache.org;
 Atri Sharma
Subject: Re: Concerted may be in need of help

On Thu, Jan 7, 2016 at 2:23 PM, Ted Dunning 
mailto:ted.dunn...@gmail.com>> wrote:
> Atri,
>
> It looks like community building is going slowly with Concerted.  This is
> understandable as a part-time activity.
>
> Would it be simpler and better for the project to build a community outside
> Apache and bring the project back for incubation once you have done so?

But what's wrong with this community building exercise within the Apache?

I honestly don't get what this is going to accomplish if we push Concerted
out AND then get them back.

I also don't get why we're so concerned about this particular community
where we had examples of very, very slow to take off communities in
the Incubator.

Thanks,
Roman.

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

RE: Concerted may be in need of help

[Ross Gardler]

+1

Sent from my Windows Phone

From: Roman Shaposhnik
Sent: ‎1/‎8/‎2016 7:35 PM
To: general@incubator.apache.org
Cc: 
d...@concerted.incubator.apache.org;
 Atri Sharma
Subject: Re: Concerted may be in need of help

On Thu, Jan 7, 2016 at 2:23 PM, Ted Dunning  wrote:
> Atri,
>
> It looks like community building is going slowly with Concerted.  This is
> understandable as a part-time activity.
>
> Would it be simpler and better for the project to build a community outside
> Apache and bring the project back for incubation once you have done so?

But what's wrong with this community building exercise within the Apache?

I honestly don't get what this is going to accomplish if we push Concerted
out AND then get them back.

I also don't get why we're so concerned about this particular community
where we had examples of very, very slow to take off communities in
the Incubator.

Thanks,
Roman.

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

Re: Concerted may be in need of help

[Roman Shaposhnik]

On Thu, Jan 7, 2016 at 2:23 PM, Ted Dunning  wrote:
> Atri,
>
> It looks like community building is going slowly with Concerted.  This is
> understandable as a part-time activity.
>
> Would it be simpler and better for the project to build a community outside
> Apache and bring the project back for incubation once you have done so?

But what's wrong with this community building exercise within the Apache?

I honestly don't get what this is going to accomplish if we push Concerted
out AND then get them back.

I also don't get why we're so concerned about this particular community
where we had examples of very, very slow to take off communities in
the Incubator.

Thanks,
Roman.

-
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

[John D. Ament]

On Fri, Jan 8, 2016 at 6:06 PM Dennis E. Hamilton 
wrote:

> [not cross-posting]
>

Just curious - but why? The hope is to collaborate between the two groups
to get a consensus.


>
> If there is a read-only GitHub mirror of the in-attic SVN repository
> subtree, will that provide enough history for you?
>
> Or would you actually require a (compressed) dump of the read-only SVN
> repository subtree (not the entire ASF subversion), assuming Apache Infra
> could provide that without creating any unacceptable SVN lock-out duration?
>
> [I am operating on the assumption that the repository in the attic has the
> entire history of the project's repository tree at the time of movement to
> the attic.  It is simply read-only forever.]
>
>  - Dennis
>
>
> [ ... ]
> > And that's fine, but that doesn't necessary mean that you need to "lock
> > away" the history. But I may completely wrong and it wouldn't be
> > allowed to even fork a dead Apache log4cxx on GitHub to keep working
> > on it with the history, even privately?
> >
> > Mit freundlichen Grüßen,
> >
> > Thorsten Schöning
> [ ... ]
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

RE: Help for the Log4cxx podling

[Dennis E. Hamilton]

[not cross-posting]

If there is a read-only GitHub mirror of the in-attic SVN repository subtree, 
will that provide enough history for you?

Or would you actually require a (compressed) dump of the read-only SVN 
repository subtree (not the entire ASF subversion), assuming Apache Infra could 
provide that without creating any unacceptable SVN lock-out duration?

[I am operating on the assumption that the repository in the attic has the 
entire history of the project's repository tree at the time of movement to the 
attic.  It is simply read-only forever.]

 - Dennis


[ ... ]
> And that's fine, but that doesn't necessary mean that you need to "lock
> away" the history. But I may completely wrong and it wouldn't be
> allowed to even fork a dead Apache log4cxx on GitHub to keep working
> on it with the history, even privately?
> 
> Mit freundlichen Grüßen,
> 
> Thorsten Schöning
[ ... ]


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

Subject: [RESULT] [VOTE] Apache Slider (incubating) release 0.90.2-incubating

[Steve Loughran]

Subject: [RESULT] [VOTE] Apache Slider (incubating) release 0.90.2-incubating

Hello,

Here are the results of the vote for releasing
Apache Slider (incubating) release 0.90.2-incubating-RC1


+1 votes: 4 (4 binding)
+0 votes: 0 (0 binding)
-1 votes: 0 (0 binding)
(and a +0.5 vote from Daniel Gruno)

The vote has succeeded -the release will now be completed

   stevel on behalf of the Apache Slider (incubating) team


-
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

[Greg Stein]

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: Access to Incubator Wiki

[Marvin Humphrey]

On Fri, Jan 8, 2016 at 10:21 AM, James Sirota
 wrote:
> I am  james.sirota

Done.

Marvin Humphrey

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

Re: Help for the Log4cxx podling

[Thorsten Schöning]

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: Access to Incubator Wiki

[James Sirota]

I am  james.sirota

On 1/8/16 6:57 AM, Marvin Humphrey wrote:

On Thu, Jan 7, 2016 at 3:52 PM, James Sirota  wrote:


Can someone give me access to the incubator wiki so that I can append the 
Metron progress report to it?

What is your Incubator wiki login?  (Not the same as your Apache ID.)

Marvin Humphrey

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




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

Re: Help for the Log4cxx podling

[William A Rowe Jr]

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

[Dennis E. Hamilton]

[Not cross-posted]

This is not about the governance issues raised in the discussion.

Technically, I do not understand what is difficult about creating working 
copies of a project's portion of the ASF SVN repository.  It is done all of the 
time, for presumably much larger projects.  If you mean a full backup with all 
history, that is a different matter.  An attic SVN would still have all of that 
though.

In any case, projects now have the option of creating a read-only Git mirror of 
their SVN, and there are a number of those hosted on GitHub, cloned, forked, 
etc.  That could clearly be done for a project with its SVN in the attic.  (I 
have no idea whether the history is as complete as what abides in the SVN.)  
These are not Gits of the entire ASF repo.  The Git mirror has just the 
project's slice.

What is not part of the current use of Git mirrors (whether on an ASF SVN or 
Git) is a way to accept Git push requests at the mirror in a manner that 
sustains ASF requirements for provenance and auditability of contributions, 
with assurance that IP matters are dealt with in accord with policy.  My 
impression is that there is work underway to address that.  However, this 
relates to ASF project governance policies and practices and that may not be 
helpful in how log4xx might be sustained.  It would not apply to a project in 
the attic regardless.  


> -Original Message-
> From: Thorsten Schöning [mailto:tschoen...@am-soft.de]
> Sent: Friday, January 8, 2016 08:20
> To: general@incubator.apache.org
> Cc: log4cxx-...@logging.apache.org
> Subject: Re: Help for the Log4cxx podling
> 
[ ... ]
> The problem and difference to GitHub I see now with the Attic is, that
> you have a huge, centralized SVN repo, which is very hard to clone for
> interested persons like me for technically reasons. When I tried some
> years ago, you actively blocked me just because I fetched revisions a
> week or so... :-) So if you decide that the project is dead, with the
> same decision you might prevent people access to the very valuable
> history of the project simply for practical reasons, because we are
> not allowed to clone it 2 weeks or the amount of data is just to huge
> with all those empty revisions or whatever.
> 
> If the project is additionally hosted on GitHub and not only in Attic,
> it would be simpler for still interested people to fork and make use
> of it. I see that as somewhat special to Apache's Attic concept, and
> maybe even the use of SVN, though I like SVN a lot: To me it looks
> like that hosting all Attic projects on a platform enabling easier
> forking of the entire project history would be a great idea.
[ ... ]


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

Re: Help for the Log4cxx podling

[Thorsten Schöning]

Guten Tag William A Rowe Jr,
am Freitag, 8. Januar 2016 um 15:33 schrieben Sie:

> Forty forks means 40 prospective committers.

Or just people, like some of those currently involved, which change
things once in a while because of bugs or such. I'm always just happy
if my fixes are simply merged without participating in further
development too much.

> Nothing is solved by "moving"
> the project to github if their changes are never moved back to the ASF.

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

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

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

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail: thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow


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

Re: Help for the Log4cxx podling

[William A Rowe Jr]

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: Access to Incubator Wiki

[Marvin Humphrey]

On Thu, Jan 7, 2016 at 3:52 PM, James Sirota  wrote:

> Can someone give me access to the incubator wiki so that I can append the 
> Metron progress report to it?

What is your Incubator wiki login?  (Not the same as your Apache ID.)

Marvin Humphrey

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

Re: Wiki write karma

[Marvin Humphrey]

On Fri, Jan 8, 2016 at 12:55 AM, Jan Willem Janssen
 wrote:

> Would it be possible to grant me edit rights to the incubator wiki?
> My wiki name is “JanWillemJanssen”.

Done.

Marvin Humphrey

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

RE: Help for the Log4cxx podling

[ulrik.pedersen]

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

Wiki write karma

[Jan Willem Janssen]

Hello,

Would it be possible to grant me edit rights to the incubator wiki?
My wiki name is “JanWillemJanssen”.

Thanks in advance,

--
Met vriendelijke groeten | Kind regards

Jan Willem Janssen | Software Architect
+31 631 765 814


My world is something with Amdatu and Apache

Luminis Technologies
Churchillplein 1
7314 BZ  Apeldoorn
+31 88 586 46 00

https://www.luminis.eu

KvK (CoC) 09 16 28 93
BTW (VAT) NL8170.94.441.B.01



signature.asc
Description: Message signed with OpenPGP using GPGMail

Access to Incubator Wiki

[James Sirota]

Hi,

Can someone give me access to the incubator wiki so that I can append the 
Metron progress report to it?

Thanks,
James