<br><br><div class="gmail_quote">On Wed, Aug 11, 2010 at 1:28 PM, Phil Linttell <span dir="ltr"><<a href="mailto:phil.linttell@rogers.com">phil.linttell@rogers.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
How does providing the valuable information that a patch no longer<br>
applies, and querying it status, warrant the action of locking a<br>
ticket? </blockquote><div><br></div><div>Because it's discussion that adds no technical information to the ticket whatsoever, coupled with a plea for someone besides the poster to clean it up and commit it. Every bit of this could and should be done on the list. This is nothing new.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">By all means direct the discussion to the list, but don't lock<br>
the ticket - someone might want to update the patch at make it useful<br>
again.<br></blockquote><div><br></div><div>Which they can do to a locked ticket. A lock does not prevent patch submission.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Spending time and effort to test a patch, and then report back the<br>
results against the ticket is, to me, the kind of behaviour and<br>
engagement the Project should encourage. Locking the ticket as a reward<br>
for their time and effort is like slapping them across the face with a<br>
wet fish,<br></blockquote><div><br></div><div>We have easily over 100 patches that no longer apply to current trunk in trac. Probably twice that. If we got a message from every user reporting every bit of unsupported code being unusable, trac would be even more impossible for us to tread through than it already is. Exchanges between users and patch submitters pleading for the ticket to be updated for their use, and further pleading with devs to look at the ticket only serve to make the ticket impossible to read. I understand that you do not need to look at it from this perspective as you are not in the position of triaging, working on, or committing the code, but we need to make sure trac remains functional *for us*. In short, trac is for exchanges between developers and patch authors/bug submitters. Interested third parties chiming in with non-technical information or unsolicited "me toos" only delays ticket solution.</div>
<div><br></div><div>Robert</div></div>