On 12/12/2012 8:57 PM, Chris Hostetter wrote:
: Subject: Re: Solr patches for 4x - how to get committer attention?
FWIW: there is a big difference between getting attention for a patch, and
getting attention for an open issue that has no patch -- several of the
issues you mentioned have no patch at all, which doesn't really put them
on the same playing field.
The concern is that sort of situation should not be "how do i get
committer's attention" as "how can i help contribute to moving this
forward, and how do i rally other people into thinking this feature/bug is
important enough to get them to also want to contribute as well."
Even if you don't know how to fix a bug, or implement a desired feature:
take a stab at writing a test case that demonstrates the problem and/or
how you think things should work. That saves time for someone (committer
or othwerwise) to work on implementing the code to make th test pass -- or
at the very least, helps start the conversation as to what the code should
look like.
the more active an issue is, the more people work on a patch, the more
iterations there are as people help find problems and fix them, the more
people say "this patch works well for me" -- the more likely it is to get
the attention of someone to do that last little bit: commit the thing.
For me, these past few weeks, i've really been trying to prioritize my
time on committing fixes for bugs (in particular: silent bugs that users
may not even notice). if someone else has already submitted a patch with
a text & a fix, great, that saves me time and i try to tackle those as
soon as i see them -- all i have to do is sanity check it and commit. if
someone has submitted a patch with just a test, or just a fix -- that's
more work, but still better then nothing, i try to work on those as soon
as i have an idea how to deal with them. last on the list is bugs with no
test or proposed fix ... those tend to take the most amount of
time/energy/thought, so unless the description makes it clera that they
are really heinous and/or have no work arround, they tend to be at the
bottom of the queue.
New features tend to enter my thought process the same way -- they
just have a higher burden in my own mind before i'm confortable committing
them, because they open up the "expected functionality" vectors of solr,
and it takes some careful consideration of what the long term
support/viability of a feature is realtive other features/refactorings
might be desirable -- the bigger the feature, the more surface area it
exposes, the more carefully i want to think it through and think about how
it interacts with other features (and see tests verifying how well it
works in conjunction with other features) before i'm confortable
committing.
Thanks for the info, and taking the time to look into this and reply.
I'd like to thank everyone connected with Lucene for all the hard work
that has gone into Solr.
I was most concerned about attention for the issues where I have
contributed a patch, but then I started looking at the big list of
issues I've created and those I'm watching, so I cooked up the major
list you've already reviewed. I was a little shocked at how much I've
already done and how much more there is I could be doing.
Most of the issues where I haven't contributed a patch are because I
have no idea where to even begin. That honestly is where I started out
for many of the ones where I *did* make a patch, but eventually I
figured it out. SOLR-2906 and SOLR-3393 are prime examples of this.
My spare time is becoming limited at the moment due to some non-Solr
work projects reaching critical, so I will probably not be able to do
much more on 4.1, but when those projects finish up I hope to be back
helping for 4.2, and try to make some patches.
Having looked into the belly of the beast, 4.1 looks to me like a big
leap forward. It's not nearly as earth-shattering as the jump from 3.x
to 4.0, but I'm amazed at what I've seen go into it.
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
