[build2] [bug] Failed assertion with hacky repository/package
Klaim - Joël Lamotte
mjklaim at gmail.com
Wed Jun 6 10:32:43 UTC 2018
On 6 June 2018 at 11:36, Boris Kolpackov <boris at codesynthesis.com> wrote:
> > If yes, 1. in which repository's issue list? it seems hard to decide when
> > tools use each others, because one could pass wrong data to the other so
> > the source is not where there is the crash.
> > 2. consider only having one issue list for the whole project? using tags
> > to have an idea of the identified tools involved.
> > 3. I believe If no, consider closing all the issue pages and clarify
> > where to report issues.
> Yes, this is a very good point. We looked into having a single, project-
> wide issue list (that would probably be ideal) but it appears this is not
> supported by GitHub (unless we miss something). Any suggestions?
I thought they added organization-wide issue lists and wiki but
it's actually more like a page gathering issues from all projects in your
The only organization-wide feature is "projects" which is basically a
Anyway, looks like the reasonable (and often used) options would be:
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);
(this alternative also allow for issues to be automatically posted to
the mailing list and vice-versa)
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
(I mean more than in github).
B. Close all issue trackers of all projects except the one of the
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.
You can still use tags to mark issues touching to specific projects.
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
and people will manage to realize the most pertinent place to report
themselves (because people using build2 will, for now, probably not be
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).
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.
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.
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?
In any way, having a tracking number will become very useful as soon as you
enter Beta stage I believe.
> > Now with the issue [...]
> This should be fixed in the latest staged version.
Ok I'll try it soon.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users