Re: Do we agree on our RTC way of working? (was: Welcome Ryan McKinley!)
On 4/27/07, Yonik Seeley [EMAIL PROTECTED] wrote: snip-lotsa-good-stuff/ ...My *personal* philosophy is probably more permissive than most:.. Thanks for sharing this, you're totally right that a half-baked patch is better than no patch at all, and that there are different stages which make sense in contributions. Hard rules wouldn't work, but I'm glad we've had this discussion (and I'll go back to my corner now ;-) Also, thanks Hoss for creating http://wiki.apache.org/solr/CommitPolicy, I think it's really good to have this. -Bertrand
Re: Do we agree on our RTC way of working? (was: Welcome Ryan McKinley!)
Bertrand: Just some comments from the sideline.. Here's my understanding of our current (but largely unwritten IIUC) way of working. 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. 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? 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. 2.. Non-trivial patches require a [VOTE] on the dev list before being committed. What's non-trivial? I'd suggest using our common sense and trusting each other to judge this, for a start. 3. Patches, and especially those adding new functionality, must be accompanied by automated tests and some documentation (usually in the Solr wiki). 4. If needed, we could create svn branches for wild experimental stuff, but we prefer to work with small incremental patches if possible. Your comments here are very general, vague, wide open shots. 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. 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. Just some comments from the sideline Rajesh.
Re: Do we agree on our RTC way of working? (was: Welcome Ryan McKinley!)
Here's my understanding of our current (but largely unwritten IIUC) way of working. 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. 2.. Non-trivial patches require a [VOTE] on the dev list before being committed. What's non-trivial? I'd suggest using our common sense and trusting each other to judge this, for a start. 3. Patches, and especially those adding new functionality, must be accompanied by automated tests and some documentation (usually in the Solr wiki). 4. If needed, we could create svn branches for wild experimental stuff, but we prefer to work with small incremental patches if possible. I hope I'm not wasting our collective time with this - feel free to correct, complete, flame, whatever ;-) yes. Clarity is good! The logic I had for this set of commits was adding things that are trivial (SOLR-203) and things that do not affect a running system without configuration (SOLR-162, SOLR-179, SOLR-211) -- Next time i will wait for an explicit review + vote. My trivial radar may have been off when I deleted ContentStream.java and CommitRequestHandler.java with only a warning on the wiki... yes, these guidelines look good ryan
Re: Do we agree on our RTC way of working? (was: Welcome Ryan McKinley!)
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
Re: Do we agree on our RTC way of working? (was: Welcome Ryan McKinley!)
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
Re: Do we agree on our RTC way of working? (was: Welcome Ryan McKinley!)
On 4/27/07, Bertrand Delacretaz [EMAIL PROTECTED] wrote: 1. Solr usually works in RTC mode: I don't think that's really the way we have been working (RTC requires a consensus vote). I think we've been doing CTR. For anything non-trivial, we open a JIRA issue and request feedback before committing. Feedback is not always received, but I've still committed many based on my own personal comfort level with the patch (if I think it will be contentious or not, etc). So it's more like lazy consensus. I think Solr has been using roughly the same approach that Lucene-java has been (unsurprisingly, since that's where many of us came from). 3. Patches, and especially those adding new functionality, must be accompanied by automated tests and some documentation (usually in the Solr wiki). In general... I like guidelines more than rules, and I like to retain flexibility. My *personal* philosophy is probably more permissive than most: - a half baked patch in JIRA is better than no patch at all (just say it's not quite ready) - a JIRA patch w/o tests is better than no patch at all - new functionality w/o a test is often better than no functionality (some tests are very hard to write... I've just hand-tested some things in the past). - new functionality with tests is better than without - new functionality that's not documented is often better than no functionality (it doesn't have to be at the same time... it can be documented later) - new functionality with tests and documentation is best Off on a tangent: for contributors, we want to be careful about implying that patches should always be complete, include unit tests, and be documented. While it's nice, we'd still rather have a patch than no patch at all. Of course if someone is looking to become a committer, then we would be looking at patch completeness, quality, tests, etc. -Yonik
