I think you're right-- it's best to keep all the info about a bug in one place.
What else could we associate with the bug to help out committers? Is there a preferred format for unit tests? Struts has a bunch of different facets, maybe there would be several different formats that would make sense. Fears about regression issues are well-founded. What do people think about including a version of the example application that uses the patch, and updating the example as a way of maintaining a "reference" integration testbed? That way, you'd be able to assess the impact of patches on each other to some degree. Just a thought. -----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 12:04 PM To: Struts Developers List Subject: RE: Applying patches On Fri, 4 Oct 2002, Taylor, Jason wrote: > Date: Fri, 4 Oct 2002 11:23:39 -0700 > From: "Taylor, Jason" <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: 'Struts Developers List' <[EMAIL PROTECTED]> > Subject: RE: Applying patches > > I suppose you could log a bug that refers to a patch of another bug, if that > isn't too weird. That way, you could vote for a bug you want fixed and you > could vote for a patch that fixes it separately and the severity of the > problem could be tracked along with the relative confidence people have in > proposed solution. The trick would be making it easy to get rid of the > patch votes when a bug is resolved. Anyone out there a bugzilla wizard? > Votes go away automatically when an issue is FIXED, so that's not a problem. I can also adjust the vote parameters on Struts bug reports, which are currently: * Maximum votes per person = 6 * Maximum votes per person on a single bug = 3 if we want to. Personally, I'd prefer that alternative patches to the same problem be attached to the same bug report -- it's a lot easier to keep things straight that way -- and arguments for or against particular fix approaches can be made in your notes on the bug report and/or on STRUTS-DEV. Craig > -----Original Message----- > From: Scott Carlson [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 04, 2002 11:08 AM > To: [EMAIL PROTECTED] > Subject: RE: Applying patches > > > - Maybe we should start a discussion on using the Voting in bugzilla? > Although > that is meant for prioritizing > - Or maybe a "+1 I tried it" in the comments to help committers feel more > comfortable. > > > I am one of those people that is trying to be more active on the list and in > the code. If I can help in this type of area by trying patches and voting > for > ones that work, that would be great. > > > > > rom: Taylor, Jason <[EMAIL PROTECTED]> > Subject: Applying patches > Date: Fri, 4 Oct 2002 10:43:48 -0700 > Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C26BCD.98088C80" > > > Maybe we can come up with some process of reviewing patches so that > struts-dev subscribers can take care of some of the quality control tasks > and committers can review the reviews, if that makes sense. Struts is so > good at divvying up work between people and creating specialized tasks that > somehow make up a development process, it seems appropriate that the process > of managing the framework itself should benefit from similar specialization. > > > Is there anything we can do to help committers review patches? Maybe people > could post their own digests of the bug list that prioritize bugs, scope the > issues and give their opinions on the possible solutions or the posted > patches that are available. We could also find bugs that we recommend be > dismissed to get them off the list. Maybe morale would improve if there was > a sense that the effort required was actually *not* infinite. > > __________________________________________________ > Do you Yahoo!? > New DSL Internet Access from SBC & Yahoo! > http://sbc.yahoo.com > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
