On Thu, Jul 7, 2011 at 6:52 PM, Erick Erickson <erickerick...@gmail.com> wrote: > Yeah, this is kind of a grey area, I think we should do what we can to > encourage contributions and being better about applying patches when > someone has gone through the effort of making one in the first place > certainly goes in the right direction... > > > It *may* help that there have been several more committers added in the > recent past (myself included), so perhaps there's some more bandwidth > available now.
hopefully!!! this is why we added and keep on adding committers since we have too much work than we can handle. simon > > Best > Erick > > On Thu, Jul 7, 2011 at 12:44 PM, Smiley, David W. <dsmi...@mitre.org> wrote: >> >> On Jul 6, 2011, at 6:44 PM, Erick Erickson wrote: >> >>> In the past I've had to ping the dev list with an "include patch XYZ >>> please" message.... >> >> Yeah... doesn't that strike you as a problem though? Maybe I should dig up >> all my issues and start bugging the dev list with "Commit this, pretty >> please?" messages. Or not and they will say in the JIRA graveyard. >> >>> But I've just assigned it to myself, I'll see if I can get it >>> committed, I'm new enough at the process that I need the practice.... >> >> I noticed, thanks. >> >>> Best >>> Erick >>> >>> On Wed, Jul 6, 2011 at 1:51 PM, Smiley, David W. <dsmi...@mitre.org> wrote: >>>> How do committers recommend that patch contributors (like me) get their >>>> patches committed? At the moment I'm thinking of this one: >>>> https://issues.apache.org/jira/browse/SOLR-2535 >>>> This is a regression bug. I found the bug, I added a patch which fixes the >>>> bug and tested that it was fixed. The tests are actually new tests that >>>> tested code that wasn't tested before. I put the "fix version" in JIRA as >>>> 3.3 at the time I did this, because it was ready to go. Well 3.3 came and >>>> went, and the version got bumped to 3.4. There are no processes in place >>>> for committers to recognize completed patches. I think that's a problem. >>>> It's very discouraging, as the contributor. I think prior to a release >>>> and ideally at other occasions, issues assigned to the next release number >>>> should actually be examined. Granted there are ~250 of them on the Solr >>>> side: >>>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+SOLR+AND+resolution+%3D+Unresolved+AND+fixVersion+%3D+12316683+ORDER+BY+priority+DESC >>>> And some initial triage could separate the wheat from the chaff. >>>> >>>> ~ David Smiley >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
