Hi Dave,<div><br>On Sun, Apr 3, 2016 at 11:36 AM, Dave Crossland <dave@lab6.com> wrote:<br>
<blockquote type="cite"><div dir="ltr"><div><br></div>Hi<div><br></div><div>When sugar git moved from <a href="http://git.sugarlabs.org/sugar-old">http://git.sugarlabs.org/sugar-old</a> to <a href="https://github.com/sugarlabs/sugar">https://github.com/sugarlabs/sugar</a>  in 2013, why did issue tracking stay at <a href="http://bugs.sugarlabs.org">bugs.sugarlabs.org</a> and not move to <a href="https://github.com/sugarlabs/sugar/issues">https://github.com/sugarlabs/sugar/issues</a> ?</div></div></blockquote><div><br></div><div>Why do we want to mix our coding and our program?  Our bug tracker is sorted by program (eg. Sugar, Write, TurtleBlocks), but our code as many more lines.  We need to make reporting bugs as easy as writing steps to reproduce.  Go and ask a student in a classroom and half can probably do that.  But none of them can tell you the difference between sugar shell and sugar toolkit gtk3 and sugar datastore (I don't even know what that does).</div><div><br></div><blockquote type="cite"><div dir="ltr"><div><br></div><div>I think it would be a good idea to move the issues, since pull requests can then be linked to issues (and even close them automatically by including "closes #issue_id" in the commit/pr message :) and development is concentrated in 1 place, with 1 UX.</div></div></blockquote><div><br></div><div>I'm pretty hyped that we use hyperlinks currently to link patches to issues.  That works fine.</div><div><br></div><div>We still write "closed #X" in our commits.  We used to have something to automatically close it.  For some reason we decided to go back to manually closing tickets - separating the testing from the coding.</div><br><blockquote type="cite"><div dir="ltr"><div><div><br></div></div><div>There are only 182 open issues on <a href="http://bugs.sugarlabs.org">bugs.sugarlabs.org</a> (<a href="https://bugs.sugarlabs.org/query?status=new&status=assigned&status=accepted&status=reopened&component=Sugar&order=priority">https://bugs.sugarlabs.org/query?status=new&status=assigned&status=accepted&status=reopened&component=Sugar&order=priority</a>) so moving them over would likely take one person 3-4 hours. I'm happy to do this if it would be helpful. </div></div></blockquote><div><br></div><div>No, open issues are not the only thing.  We need closed issues as well - all the commits, code comments, etc have references to them.  If we fragment the issue placement we will eventually forget about trac and loose the old issues.  One place is better than 2.</div><div><br></div><div>If we migrate to a new platform, we also need to take care to keep the numbers the same.  That makes a github migration hard - it is a closed platform and we don't control that aspect of it.  We need to choose a new platform that gives us more flexibility - maybe something like GitLab, Phabricator [1], Bugzilla or Trac.</div><div><br></div><div>Thanks,</div><div>Sam</div><div><br></div><div>[1] <a href="https://phabricator.wikimedia.org/">https://phabricator.wikimedia.org/</a></div><br><blockquote type="cite"><div dir="ltr"><div><div><br></div>-- <br><div class="gmail_signature">Cheers<br>Dave</div>
</div></div>
</blockquote></div>