I think the key thing to remember here is that Bertrand was not suggesting
we do anything differnetly then we have before, just that as the number of
committers grow, it's a good idea to clarify how things have been done in
the past, so we can talk about how we want to do things in the future.
(forgive me if i'm putting words in your mouth Bertrand)
Solr is not an Aristocracy, it's a community ... in the past things were
done a certian way, not because a few of us got together in a room and
decided they should be done that way, but because there was only a few of
us and it just worked out that way. As the community grows, new working
styles are added into the mix and it starts to become a little more
important to have discussions where we start to ask "How do we work
together? How do we want to work together?"
To that end, I've made some notes on the wiki about how changes have been
made in the past, written in future tense to serve as a guide -- but that
doesn't mean it's a policy written in stone from on high, it's a wiki --
if we want to do things differnetly let's talk about it.
http://wiki.apache.org/solr/CommitPolicy
A few more comments below...
: No, but there is a lot of trust between committers, so everyone's
: allowed to diverge from the "rules" when it makes sense, and we do our
: best not to be pedantic about them. Hence the "usually": it's based on
: trust and agreeing on a basic set of (relatively loose) principles.
agreed ... OSS projects could adopt a free-for-all approach where anyyone
could commit anything, in which case the the worst case scenerio is that
someone does a lot of work, commits it, and the community decides that
it's not in the best interest of the project and it gets rolled back ...
no harm to the project in the long run, but it can be very costly to
individuals in terms of time, effort, and sanity. having loose (in many
cases unwritten) policies/principles/guidelines/etc. help ensure that
things work more smoothly -- evne if they aren't always followed.
: > gets to trunk. Cos when you look at Solr Jira seems like 90% of the issues
: > are unassigned where 50% being major and 50% being minor. Obviously
: > there are some community needs for those patches, some are bad some are
: > good nevertheless those who are submitting patch should get a honest reply
: > in a decent time frame...
the major/minor distinction is largely subjective, an issue being
unassigned doens't mean that no one has looked at it, just that no one has
taken explicit responsibiliy for it -- it's a way of making it clear that
if another committer has the time/desire to step forwrad and work on it
they can.
A submitted patch may be good, and it may be very useful, but it also has
to be safe, and robust, and backwards compatible, and generally reusable
for more then one person, and it takes time for committers to evaluate
those things -- but the patch still has value just by being in Jira
because it means it's accessible to other users who can try it out and use
it in their own installation, or chime in with their own comments saying
"this works great for me, i love it"
-Hoss
