<div dir="ltr">In the process to review a patch, recently Quozl added this comment:<div><br></div><div>"Really a pity all this discussion gets lost in each pull request when it should really go on the ticket. ;-)" [1]<div><div><br></div><div>Sam replied:</div>"Re: we should use tickets more... I don't get enough emails to remember that we have a bug tracker (hint: why dosn't tarc email?). I also feel that tarc is not as sleek and usable as GitHub. Maybe you should lead by example, email the mailing list or create a ticket. Hopefully your bug ticket won't be forgotten in the static-feeling, talking-to-a-brick-wall site that bugs.sl.o is (hint: I always feels like your talking to yourself on tarc, there is no real form of conversation)." [2]<div><br></div><div>I want bring this conversation here, to try to involve more players in the community,</div><div>and find a good strategy.</div><div><br></div><div>Personally, I recognize our trac implementation have problems (more below)</div><div>but I can't count how many times the comments in a old ticket have saved me </div><div>hours of work or helped me avoid the same errors. </div><div>The tickets have been a invaluable resource by example to run GCI,</div><div>even when didn't have the resources to solve the for a long time, </div><div>are a good resource to guide volunteers to collaborate.</div><div>The bug database is permanent and searchable, the pull request are difficult</div><div>to find, more when there are more than one for a single commit.</div><div> </div><div>Then, from my point of view, GitHub is ok to make comments about the code,</div><div>but there are issues we need keep record. Why we do that?</div><div>What is the best strategy to solve the problem? How can we reproduce the bug?</div><div>At a time, we didn't merged code to solve errors if we didn't have a bug associated.</div><div><br></div><div>About trac problems, would be good to solve:</div><div>* We have hundred of spam users, we need clean them.</div><div>* I don't know why, but I see a lot of ticket editions by logged users waiting for moderation. I suppose is a configuration to deal with spam, but I am not sure.</div><div>* Trac and Git integration can be improved, right now, we use a GitHub service</div><div>to add a comment and close a ticket when a "Fixes #NNNN" string is in the header.</div><div>But the configuration page for that ticket say:</div><div>"This service is deprecated. To integrate GitHub with Trac, follow the<br>instructions at: <a href="http://github.com/aaugustin/trac-github">http://github.com/aaugustin/trac-github</a><br>If you're currently relying on this service, please consider upgrading to<br>trac-github. It uses a standard webhook to provide the same features and it's<br>more actively maintained." <br></div><div>Maybe we can add another key to save a comment in trac from a GitHub comment,</div><div>when is something we want keep record?</div><div><br></div><div>Another alternative is configure github to send emails o sugar-devel</div><div>with the pr updates. I don't know if will be too much spam.</div><div>Or configure trac to send a email to sugar-devel when a bug is created,</div><div>to avoid the sensation of talking with a wall, like Sam said.</div><div><br></div><div>What you think? Other ideas? Anybody volunteer to improve trac configuration?</div><div>I can help with admin permissions in github and trac. </div><div><br></div>-- <br><div><div dir="ltr">Gonzalo Odiard<br><br><div>SugarLabs - Software for children learning <br></div><div><br></div><div>[1] <a href="https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/188#issuecomment-69104257" target="_blank">https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/188#issuecomment-69104257</a> </div>[2] <a href="https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/190#issuecomment-69159430" target="_blank">https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/190#issuecomment-69159430</a></div></div>
</div></div></div>