<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 6 June 2018 at 11:36, Boris Kolpackov <span dir="ltr"><<a href="mailto:boris@codesynthesis.com" target="_blank">boris@codesynthesis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
> If yes, 1. in which repository's issue list? it seems hard to decide when<br>
> tools use each others, because one could pass wrong data to the other so<br>
> the source is not where there is the crash.<br>
><br>
> 2. consider only having one issue list for the whole project? using tags<br>
> to have an idea of the identified tools involved.<br>
><br>
> 3. I believe If no, consider closing all the issue pages and clarify<br>
> where to report issues.<br>
<br>
</span>Yes, this is a very good point. We looked into having a single, project-<br>
wide issue list (that would probably be ideal) but it appears this is not<br>
supported by GitHub (unless we miss something). Any suggestions?<br>
<br></blockquote><div><br></div><div>I thought they added organization-wide issue lists and wiki but </div><div>it's actually more like a page gathering issues from all projects in your organization.</div><div>The only organization-wide feature is "projects" which is basically a Trello-like board.</div><div><br></div><div>Anyway, looks like the reasonable (and often used) options would be:</div><div><br></div><div>A. Not use github for issue tracking, own the issue tracker (a lot of organization do that, in particular when they prefer the gerrit/phabricator review model, or when using a hosted gitlab);</div><div>    (this alternative also allow for issues to be automatically posted to the mailing list and vice-versa)</div><div>    In this case, github remains as a popular mirror, but the main development medium is on your side and you can chose how the issue tracking system is configured</div><div>   (I mean more than in github).</div><div><br></div><div>B. Close all issue trackers of all projects except the one of the super-project build2-toolchain.</div><div>    In this case, you will need to clarify int he Readme of all projects that issues must be reported there or on the mailing list.</div><div>    You can still use tags to mark issues touching to specific projects.</div><div><br></div><div>C. Status Quo: let people try to report in specific project issue lists, as it is now. Maybe there is not so much confusion potential </div><div>    and people will manage to realize the most pertinent place to report themselves (because people using build2 will, for now, probably not be beginners).</div><div>    Apparently you cannot move tickets from repo to repo, which shows the simplistic aspect of github for issue tracking (I think all specialized issue tracking tools can do that).</div><div><br></div><div>Personally I would go with A but IFF I have the workforce and/or patience to setup something like this. I did it in the past and I believe it depends a lot on the tool you want to use.</div><div>I would probably with gitlab or phabricator depending on how (non-)expert-friendly I want reviews to be. Gitlab have the advantage of having extensions to mirror on github.</div><div><br></div><div>In doubt, maybe start with C and decide one of the other solutions as soon as you see failures to spot the right place to report issues?</div><div><br></div><div>In any way, having a tracking number will become very useful as soon as you enter Beta stage I believe.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Now with the issue [...]<br>
<br>
This should be fixed in the latest staged version.<br>
<br></blockquote><div><br></div><div>Ok I'll try it soon.</div><div><br></div><div><br></div><div>Joël</div><div><br></div></div></div></div>