struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hubert Rabago <>
Subject RE: thoughts on encouraging user development
Date Mon, 05 Jul 2004 20:00:48 GMT
--- Ted Husted <> wrote:
> I can personally guarantee that if two or three developers post to a ticket
> and say "works for me", especially if they are names that I've seen before,
> the patch will be (and has been) applied. [Of course, whether it "sticks"
> is up to the rest of the committers :)]

I have no doubt about that.  What I tried to point out is my observation that
people don't seem to try out a patch just by pure coincidence.  Out of the
few who do nightly builds to use in their production apps, coincidentally
trying out the very same patch out of the two dozen reports with patches seem
like long odds.  My suggestion was for a committer who's interested in
applying a patch, but not having the time to try it out himself, to make a
call for developers to try it out.  IIRC, I've seen this happen, and indeed
the patch got applied.  Sort of a "committer-approved short list".

> When I review tickets, the ones with additional comments do get the most
> attention, the ones that stand alone do get the least. 
> This is a meritocracy, and hands-on effort
> counts for more than does clicking on a radio button.
> We need to hear from other members of the community that this
> issue is a problem for people <snip/>

Some people might feel that voting for a bug actually "counts" as a stronger
comment, especially since they can leave a limited number of bugs yet leave
comments all over.  Also, some might choose not to comment when whatever
comment they might already make has already been said by somebody else.  

Maybe there's a way to disable voting for bugs if votes don't count anyway,
or at least let people know that textual comments count more than votes, just
to avoid the misconception.  I've seen reports where there were more votes
than comments.  If those people knew leaving a comment counted more than
casting their limited votes, it's a good bet that they would've actually left
comments instead.

> Here's another reason why: All the committers are very busy guys right now.

I think people sense this, and that's why there were calls sometime ago for
more committers.  Personally, I don't feel there's a need for more
committers.  I think the current batch of committers are doing a wonderful
job, and I'm glad the bigger changes (such as struts-chain) aren't being
treated as an overnight job.  I'm also glad that just submitting a patch
doesn't make a contributor a committer.

I think the fact that there aren't a whole bunch of changes right now reflect
the stability of Struts.  Struts already provides so much, and yet remains
very reliable -- only a small percentage of the 262 tickets are really bugs,
most are just enhancement requests.  The few bugs I've seen on the tickets
seem to only affect really obscure situations.

> We have very few hours to spend on Apache, and need to take care that we
> spend these hours wisely. Seeing interest in a patch helps us set
> priorities. All the reports do go to the DEV list, and older reports often"
> bubble to the top" that way.
> -Ted.
> On Mon, 05 Jul 2004 02:00:52 -0700 (PDT), Hubert Rabago wrote:
> >
> > Steve,
> >
> > If I had to guess, I think it's more likely that a person will
> > submit a patch than try someone else's patch and report its
> > effectiveness.
> >
> > A great number of people use Struts, that's a given, but I think
> > it's a much smaller percentage that use the nightly builds (mostly
> > brave and/or trusting souls and those whose hands aren't tied by
> > corporate standards or probably work alone or in a small team).  An
> > even smaller percentage use the nightly build by building it
> > themselves.  (Maybe some still remember the series of emails
> > before, about the experience of other folks having difficulty
> > setting up to build Struts.)  From that group, I'm not sure a whole
> > lot of them would try out a patch on a bug report that the
> > committers aren't noticing.  You'd have to find several people from
> > that small group who are also affected enough by an
> > issue/enhancement the patch addresses to be able to spend the time
> > and apply, rebuild, and test, only to end up with a forked version
> > which will be incompatible with the next nightly build/release.
> > Although I can see this happening in an ideal scenario (poor guys
> > with incompatible binaries, though), this just never struck me as
> > realistic.
> >
> > With 262 tickets, or over two dozen with patches, to get "several
> > people" reporting back on the same patch, enough to get the
> > feedback that said patch is "probably good", seems unlikely.
> >
> > I can't recall several people reporting on the same patch so much
> > that it prompted a committer to eventually review and commit it.  I
> > think the closest I've seen is add'l feedback to get a bug solved,
> > or an enhancement added, maybe by messages to dev list or add'l
> > votes on the bug report.  There were a couple or more times I've
> > seen someone else look at the submitted patch and suggest
> > improvements or alternate solutions.  Still, s/he didn't really say
> > "I applied the patch to my local Struts copy and tried it out and I
> > think blah blah blah...".
> >
> > Maybe a more realistic scenario would be a call from a committer
> > for volunteers to specifically review, apply, and test a patch that
> > he's thinking of applying to CVS.  I think this has happened at
> > least once during the time I've been lurking, and IIRC it got a few
> > responses and the patch got applied.
> >
> > Also, I hope this isn't the only criteria for determining whether
> > an issue is one that affects many people.  I know it's been said
> > here before that "patches are the only votes that count", but
> > still, maybe we can use the bugzilla voting mechanism to encourage
> > users to give feedback on which ones affect them the most.
> >
> > Hubert

Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage! 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message