Hi Rajesh, On 4/27/07, rubdabadub <[EMAIL PROTECTED]> wrote:
...The word here is "unwritten". This is where is the problem with loads of apache project. Its the few privileged who decides what is a "rule" or "coding conduct". So unwritten rule is a great way of working so long you are singing the same song...
I would agree as a general rule - but in a project where face-to-face communications are the exception, I find it good to have explicit agreements on basic principles - even if they are fairly loose. I have tried to always use the word "rules" in quotes, the intent is more to have a flexible set of basic principles, they are not really "rules" - we *do* trust each other here, and svn is here to get things back when needed. About the "few privileged": at the ASF, each project's PMC has a lot of leeway when it comes to organizing how they work, and it's a good thing. Note that in our case it's the Lucene PMC who oversees Solr (and I'm not part of it ;-)
> 1. Solr usually works in RTC mode: patches are first posted to Jira, > then committed once we agree on a particular patch. This does not > apply to obvious fixes, typos, etc., of course. So "usually" works? So how do you agree? are there any rules there or is it also unwritten? ...
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.
....Sorry I have a hard time understanding how things 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...
Agreed - if you have some patches that you feel should be committed sooner than later, feel free to ask specific questions about why this hasn't happened yet. OTOH we're all volunteers, so Solr users must be prepared to get their hands dirty, and if needed use trunk code (as opposed to released versions) with the patches that they need applied.
...Your comments here are very general, vague, wide open shots. ..
That's on purpose, based on the trust thing, and as I said it's a first shot anyway.
I think if there are any commits that Ryan made is not to your liking or patch doesn't have test/docs what not then it can be reverted after all its a subversion and its not a part of a release...
Sorry if I wasn't clear, but this is *not* against Ryan's way of working, quite the contrary in fact: the goal is to create an environment where people (like Ryan currently) who're working faster than others can go forward as fast as they need, without being dragged down by others who have less available time/energy/whatever. All this while keeping Solr's great code quality, so a bit of discussion doesn't hurt IMHO.
...I been following the list and Ryan made great patches and he has the drive/time and blessings from the PMC so why stop the good thing and his enthusiasm....
Again, sorry if my message came across as a "stop", it's not the intention!
...Just some comments from the sideline..
Thanks: this is not only about committers, as usual all community members are welcome to express themselves. Hope this helps...it'd be so much more efficient to have such discussions f2f over a beer than in writing ;-) -Bertrand
