commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <flame...@gmail.com>
Subject Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
Date Thu, 11 Aug 2011 06:13:54 GMT
On Wed, Aug 10, 2011 at 6:06 AM, Ceki Gülcü <ceki@qos.ch> wrote:
> On 10/08/2011 8:02 AM, Henri Yandell wrote:
>
> <rambling scope="large" unabashed-plugin="true" >
>
> Thank you for posting this summary of the Apache way. Yes, it is damn
> hard to track contributions, especially if one wishes to do it
> accurately and fairly. However, it is possible and even easy to keep
> *approximate* track of contributions, e.g. via "commit points" as
> described in my committocracy post.

I was going to say: "That would put Sebb in charge of the ASF!!!", but
then I noticed that after the import of Jena Andy Seaborne appears to
be the top count committer (I know, that doesn't measure size of
commit).  [http://svnsearch.org/svnsearch/repos/ASF/search]

I think the problem with this is that it's an extremely arbitrary way
of dealing with failure to find consensus. It's also not very
meritocratic - it's based on what people have done and not what people
are willing to do. The 'prove it in a branch' is more merit-based and
less likely to result in status quo decisions.

> I quite like the consensual approach you describe. Treating others
> with respect goes a long way in convincing your audience. Yes, meeting
> people face to face create bonds which then help to ease
> tensions. However, while the consensual approach works nicely under
> many circumstances it does not always work.
>
> Take for example the logging issue recently discussed on this
> list. Some argue in favor of adopting SLF4J, some in favor of j.u.l,
> some in favor of log4j v2 and yet others wish to keep using
> commons-logging. I don't see a way to reach consensus on this topic
> regardless of the time and effort put into it. Creating a branch of
> commons-digester using SLF4J/jul/log4jv2 will not convince anyone.

Agreed - the work to move from one logger to another is presumably
very easy for us. Much more of a pain for users, so I'd expect there
to be resistance to change there. The interesting one will be whether
a new component (or one adding logging) would hit resistance from
using a different system.

Some of the discussion was also not about what we should use, but
whether commons-logging was done, dead etc [puts on the Attic hat].
Currently c-logging has 2 bugs fixed in trunk but no release imminent.
They don't seem like trivial bugs, so I contend we should either be
thinking of a release or thinking of making the component dormant.

> In the current system, I would expect commons-logging to be retained
> because it's the path of least action/no decision. I should mention
> that not deciding can sometimes be the best decision yielding the best
> results. In other words, being conservative is often OK.

Yup - . It's a good conversation to have had - great to hear of log4j
2.0 work and to have you still active in the conversation.

Looking at Commons, there are 17 components using c-logging (+5 in the
sandbox) and 2 also using slf4j. DBCP 2.0 represents the most likely
time on the horizon that a component would consider changing.

> The alternative system I propose, namely committocracy, is merit-based
> and where decisions can be reached in an orderly and timely fashion.
> It specifically caters for cases where consensus cannot be
> reached. IMO committocracy is not in contradiction with consensus
> building as long as its use is restricted to special circumstances
> (where consensus building has failed repeatedly).

Definitely the right way to focus on it - what are the mechanisms for
handling breakdown of consensus. Too often it's the loudest-wins, or
the one willing to hang in the longest, or the one willing to be the
most obstinate.

I think committocracy is too arbitrary to be agile - it casts things
in stone that the general Apache approach leaves to the social
structure. In practice the respect built from historical work is more
often than not the 'winning vote', we all tend to defer to those who
were here before us. That gets a bit warped as people move from
project to project. jim@ is a Commons committer. He made 4 commits to
CLI back in 2009, but I'm still likely to listen to him above and
beyond his committocracy count. I can see how that might be a good
thing or a bad thing depending on situation.

> Governance models are not cast in stone. The apache model will need to
> improve over time or eventually become obsolete.

Yup, though I think there are other areas where adaptation is more
likely to be needed than this one. Whether or not we should have CLAs
is one that jumps to mind. How to stop employers buying committocracy
(regardless of whether we have it as an official notion or its current
social notion). Patents. Decentralized development (github-like - not
the source-control but the ultra-bazaar dev style).

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message