www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Out of sight out of mind

reply Andrew Edwards <ridimz yahoo.com> writes:
Observe the following truths:
     1) Issue tricking and resolution are kept separate in our community
     2) That which is not visible garners no attention

Presently, we file bugs/issues through issues.dlang.org, the maintenance 
of which is no small task and is certainly appreciated. However, it is 
an environment completely detached from where the actual work is 
performed. As such, it breeds neglect on the part of the developers: not 
because they do not care, but rather because they do not see.

Take issue #143 for instance. It is the oldest open issue on the DLang 
Issue Tracking System. Submitted by Jarrett Billingsley on May 17, 2006, 
it received one comment two days later but was ignored for four years 
before Michal Minich made the second comment. Another two years went by 
before Martin Nowak addressed the issue, which Walter promptly reverted 
(reason unknown). The end result? Eight years flew by and the issue 
remains unresolved.

This happens because we have two separate systems (one tracking 
problems, another tracking the resolution), both of which compete for 
the same precious and extremely limited resource: the volunteer time of 
developers.

Already proven a valuable resource, GitHub offers the tools necessary to 
resolve this problem. The "issues" feature (not currently activated for 
any D-Programming-Language repo) allows us to set milestones (with due 
dates), assign tasks, and create and apply labels (multiple where required).

Observe the following:

	https://github.com/AndrewEdwards/druntime/issues?state=open

Note how quickly you can see the total number of open issues, traverse 
to any category, and identify what is important for a given milestone. 
We can even track our progress toward a specific milestone in seconds, 
or which issues we created or was assigned to us.

By using this feature, we will eliminate the fire and forget problem 
currently observed with Bugzilla. We will be able to automatically link 
resolution to issue, by a mere mention of the issue number within the 
resolution. Issues become far more visible and, consequently, are not so 
easily forgotten.

A complete win in my book.

-Andrew
Jun 15 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
Big problem with GitHub issues is how simplistic those are. All 
categorization is done by labels with no internal 
differentiation, advanced search queries are not possible. Also 
bugzilla is self-hosted solution we have full control about and 
with GitHub you can only rely on what external API exposes.

Also consider effort needed for moving all issues from existing 
database and breaking routine workflow of all active dmd/Phobos 
developers.

Personally I don't think this is as much of an issue. Issues 
don't get much attention because there are only few people 
looking at them (other than own issues). Most D users don't have 
any reason to do so.
Jun 15 2014
parent Andrew Edwards <ridimz yahoo.com> writes:
On 6/15/14, 11:46 AM, Dicebot wrote:
 Big problem with GitHub issues is how simplistic those are. All

Simplistic they are indeed. But how does that detract from the utility of the product. As programmers we are may be drawn to complexity, but some things need not be complex to be effective.
 categorization is done by labels with no internal differentiation,
 advanced search queries are not possible. Also bugzilla is self-hosted
 solution we have full control about and with GitHub you can only rely on
 what external API exposes.

True, we do not have access to anything but the external API, however I don't see that as a limiting factor. When I conduct a search in DITS, I effectively search through labels. Of course those labels present themselves as data fields/values in some row of a table but they are labels none the less. If I want to find issues filed under multiple labels, i simply include all labels of interest in my search. The same is possible in GitHub, except they are presented right there on the screen for immediate access. Want to know how many "bug" request were "closed" as "invalid" or "wontfix"? Click on the labels and walla, your search is complete. I have had experienced zero issues finding information on GitHub, in spite of their overly simplistic interface. As for internal differentiation of labels... A label is simply a label. It has no differentiation or meaning except that applied to it by the community. Marking something as Product: D Component: DMD Version: D1 & D2 Hardware: All All is absolutely no different than creating the labels D1, D2, and All in the DMD repo and assigning all three labels to the issue. The only thing that gives increase meaning to the labels any label (P1, P2, etc.), is the value we, the users, assign to them. As far as I can see the only thing GitHub is missing is a way to vote up the value of a label.
 Also consider effort needed for moving all issues from existing database
 and breaking routine workflow of all active dmd/Phobos developers.

Breaking what routine workflow? You can claim that if it's required to file an issue in DITS before anything can be done on GitHub but that's not the case. You can also claim that if every issue resolved via GitHub is explicitly linked to it's originating issue on DITS but that's not the case either. As for the effort to move the issues I'm sure there is a process for automatically moving the DITS records to GitHub. And if there isn't, I'm not against doing the work myself.
 Personally I don't think this is as much of an issue. Issues don't get
 much attention because there are only few people looking at them (other
 than own issues). Most D users don't have any reason to do so.

You are quite correct, most people will only work on what they want to work on. But I think a lot of these issues are ignored because they are just not being seen. This move may not motivate any specific person to work on any specific bug but it integrates the two processes, and automates some of the more often neglected trivialities. It also has the added benefit of always visible so it has the positive effect of being a constant reminder.
Jun 15 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrew Edwards:

 Already proven a valuable resource, GitHub offers the tools 
 necessary to resolve this problem. The "issues" feature (not 
 currently activated for any D-Programming-Language repo) allows 
 us to set milestones (with due dates), assign tasks, and create 
 and apply labels (multiple where required).

How do you move the Bugzilla issues and their attach files and cross links to GitHub? And how do you move all that back to Bugzilla (or another bug manager) once something terrible happens to GitHub four years from now? Bye, bearophile
Jun 15 2014
parent Andrew Edwards <ridimz yahoo.com> writes:
On 6/15/14, 12:21 PM, bearophile wrote:
 Andrew Edwards:

 Already proven a valuable resource, GitHub offers the tools necessary
 to resolve this problem. The "issues" feature (not currently activated
 for any D-Programming-Language repo) allows us to set milestones (with
 due dates), assign tasks, and create and apply labels (multiple where
 required).

How do you move the Bugzilla issues and their attach files and cross links to GitHub? And how do you move all that back to Bugzilla (or another bug manager) once something terrible happens to GitHub four years from now?

How do you recover your work from the GitHub five years from now when GitHub falls off the edge of the earth and simultaneously your PC with the only backup copy gets fried by an electrical surge? Say GitHub never recovers from said disaster: what will you do to reunite all the developers working on D that seem far more productive than before moving to GitHub? And while we are predicting the demise of GitHub, what happens when the server housing DITS fall into the same black hole as GitHub? People repeatedly file the same bug report, even though those reports are publicly visible on an infinitely more powerful and internally controlled system than GitHub. The database will be rebuilt by this very action. And that's assuming the worst case scenario: the GitHub server farm (and every productive member of the GitHub team) gets swallowed up by a black hole and no knows how to bring them back. As for transferring the data to GitHub, nothing says the transition has to be instantaneous. It can be accomplished in two steps: 1) Open all new issues in GitHub 2) Migrate reports individually to GitHub and close out from on Bugzilla #1 would cause the problem of requiring people to use two systems at the same time, but since we are already doing that, it does not add to the cognitive load. #2 poses the problem of who will do the work. Assuming there is no automatic way to get it done, I am willing to personally migrate every single report by hand.
Jun 15 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Sunday, 15 June 2014 at 16:21:03 UTC, bearophile wrote:
 Andrew Edwards:

 Already proven a valuable resource, GitHub offers the tools 
 necessary to resolve this problem. The "issues" feature (not 
 currently activated for any D-Programming-Language repo) 
 allows us to set milestones (with due dates), assign tasks, 
 and create and apply labels (multiple where required).

How do you move the Bugzilla issues and their attach files and cross links to GitHub? And how do you move all that back to Bugzilla (or another bug manager) once something terrible happens to GitHub four years from now? Bye, bearophile

Moving itself can be done automatically via GitHub API (I had script for copying isues between GitHub repos for example). Problem is that GitHub issues don't provide same set of features bugzilla does so moving inevitably comes with information loss.
Jun 15 2014
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/15/2014 8:37 AM, Andrew Edwards wrote:
 Take issue #143 for instance.

Convenient linky: https://issues.dlang.org/show_bug.cgi?id=143
Jun 15 2014
prev sibling next sibling parent "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
On Sunday, 15 June 2014 at 15:37:22 UTC, Andrew Edwards wrote:
 Observe the following truths:
     1) Issue tricking and resolution are kept separate in our 
 community
     2) That which is not visible garners no attention

 Presently, we file bugs/issues through issues.dlang.org, the 
 maintenance of which is no small task and is certainly 
 appreciated. However, it is an environment completely detached 
 from where the actual work is performed. As such, it breeds 
 neglect on the part of the developers: not because they do not 
 care, but rather because they do not see.

 Take issue #143 for instance. It is the oldest open issue on 
 the DLang Issue Tracking System. Submitted by Jarrett 
 Billingsley on May 17, 2006, it received one comment two days 
 later but was ignored for four years before Michal Minich made 
 the second comment. Another two years went by before Martin 
 Nowak addressed the issue, which Walter promptly reverted 
 (reason unknown). The end result? Eight years flew by and the 
 issue remains unresolved.

 This happens because we have two separate systems (one tracking 
 problems, another tracking the resolution), both of which 
 compete for the same precious and extremely limited resource: 
 the volunteer time of developers.

 Already proven a valuable resource, GitHub offers the tools 
 necessary to resolve this problem. The "issues" feature (not 
 currently activated for any D-Programming-Language repo) allows 
 us to set milestones (with due dates), assign tasks, and create 
 and apply labels (multiple where required).

 Observe the following:

 	https://github.com/AndrewEdwards/druntime/issues?state=open

 Note how quickly you can see the total number of open issues, 
 traverse to any category, and identify what is important for a 
 given milestone. We can even track our progress toward a 
 specific milestone in seconds, or which issues we created or 
 was assigned to us.

 By using this feature, we will eliminate the fire and forget 
 problem currently observed with Bugzilla. We will be able to 
 automatically link resolution to issue, by a mere mention of 
 the issue number within the resolution. Issues become far more 
 visible and, consequently, are not so easily forgotten.

 A complete win in my book.

 -Andrew

I agree with this quite a lot. If for nothing else, I agree with this because I think it makes the most sense to have the place we do pull requests be the same place we track issues. There are a few other reasons I agree with this, but the point is that I would very much like to see this happen.
Jun 15 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrew Edwards:

 How do you recover your work from the GitHub five years from 
 now when GitHub falls off the edge of the earth

Online sites are ephemeral. So unless there is a way to move the bug repository off GitHub if the need arises, I am not going to appreciate the idea of moving bugs to GitHub. Bye, bearophile
Jun 15 2014
prev sibling next sibling parent reply Brad Roberts via Digitalmars-d <digitalmars-d puremagic.com> writes:
While I agree that some of these points are true, what's not true is that the
use of bugzilla and 
it's separateness from github is the cause.  Bugzilla has a similar set of
features for 
categorization and future release management as github.  Having bugs tracked
via github's issue 
tracker won't make the use of those types of features any more or less doable
or easy.  Having the 
bugs tracked via github will not make it any easier to manage, just different. 
What's missing is 
actually using those features, which is not inconsiderable work.

On 6/15/14, 8:37 AM, Andrew Edwards via Digitalmars-d wrote:
 Observe the following truths:
      1) Issue tricking and resolution are kept separate in our community
      2) That which is not visible garners no attention

 Presently, we file bugs/issues through issues.dlang.org, the maintenance of
which is no small task
 and is certainly appreciated. However, it is an environment completely
detached from where the
 actual work is performed. As such, it breeds neglect on the part of the
developers: not because they
 do not care, but rather because they do not see.

 Take issue #143 for instance. It is the oldest open issue on the DLang Issue
Tracking System.
 Submitted by Jarrett Billingsley on May 17, 2006, it received one comment two
days later but was
 ignored for four years before Michal Minich made the second comment. Another
two years went by
 before Martin Nowak addressed the issue, which Walter promptly reverted
(reason unknown). The end
 result? Eight years flew by and the issue remains unresolved.

 This happens because we have two separate systems (one tracking problems,
another tracking the
 resolution), both of which compete for the same precious and extremely limited
resource: the
 volunteer time of developers.

 Already proven a valuable resource, GitHub offers the tools necessary to
resolve this problem. The
 "issues" feature (not currently activated for any D-Programming-Language repo)
allows us to set
 milestones (with due dates), assign tasks, and create and apply labels
(multiple where required).

 Observe the following:

      https://github.com/AndrewEdwards/druntime/issues?state=open

 Note how quickly you can see the total number of open issues, traverse to any
category, and identify
 what is important for a given milestone. We can even track our progress toward
a specific milestone
 in seconds, or which issues we created or was assigned to us.

 By using this feature, we will eliminate the fire and forget problem currently
observed with
 Bugzilla. We will be able to automatically link resolution to issue, by a mere
mention of the issue
 number within the resolution. Issues become far more visible and,
consequently, are not so easily
 forgotten.

 A complete win in my book.

 -Andrew

Jun 15 2014
next sibling parent Andrew Edwards <ridimz yahoo.com> writes:
On 6/15/14, 4:13 PM, Brad Roberts via Digitalmars-d wrote:
 While I agree that some of these points are true, what's not true is
 that the use of bugzilla and it's separateness from github is the
 cause.  Bugzilla has a similar set of features for categorization and
 future release management as github.  Having bugs tracked via github's
 issue tracker won't make the use of those types of features any more or
 less doable or easy.  Having the bugs tracked via github will not make
 it any easier to manage, just different.  What's missing is actually
 using those features, which is not inconsiderable work.

I am not suggesting that bugzilla is "the" cause, rather that the separation of systems foster the condition. You are absolutely correct though. Without people actually using the features it matters not what system we use. My proposal for using one homogeneous system is geared on the idea that people doesn't care to admit that the problem exists or take initiative to fix it if they never have to look at it. Presented with it everyday however, "some" become motivated to take action to resolve the issue. I cannot see how doing this would negatively impact the community.
Jun 15 2014
prev sibling parent Martin Nowak <code dawg.eu> writes:
On 06/15/2014 10:52 PM, David Nadlinger wrote:
 One thing that might be nice to have, though, is a "What Should I Work
 On Next?" type of page for newcomers, with a few saved searches and
 maybe some big-picture suggestions in addition to that.

Go to https://issues.dlang.org/colchange.cgi and change your columns to include the votes helps a lot. Could we enable this by default? It's probably not the best idea for newcomers to work on the most voted problems, as those are usually very hard.
Jun 15 2014
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Sunday, 15 June 2014 at 20:14:09 UTC, Brad Roberts via 
Digitalmars-d wrote:
 While I agree that some of these points are true, what's not 
 true is that the use of bugzilla and it's separateness from 
 github is the cause.  Bugzilla has a similar set of features 
 for categorization and future release management as github.  
 Having bugs tracked via github's issue tracker won't make the 
 use of those types of features any more or less doable or easy.
  Having the bugs tracked via github will not make it any easier 
 to manage, just different.  What's missing is actually using 
 those features, which is not inconsiderable work.

I couldn't agree more. GitHub certainly is not more capable than Bugzilla, and would be just as easy or hard to navigate with our large number of open issues. One thing that might be nice to have, though, is a "What Should I Work On Next?" type of page for newcomers, with a few saved searches and maybe some big-picture suggestions in addition to that. David
Jun 15 2014
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Sunday, 15 June 2014 at 20:51:59 UTC, Andrew Edwards wrote:
 My proposal for using one homogeneous system is geared on the 
 idea that people doesn't care to admit that the problem exists 
 or take initiative to fix it if they never have to look at it.

How do I have to look at the "Issues" tab on GitHub any more than I have to look at issues.dlang.org?
 I cannot see how doing this would negatively impact the 
 community.

It's a lot of work that could be invested much better, plus we'd lose all the authorship information on the issues and comments (you can copy them as text, but all the issue subscriptions, … are no longer there). David
Jun 15 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Sunday, 15 June 2014 at 17:40:58 UTC, Andrew Edwards wrote:
 True, we do not have access to anything but the external API, 
 however I don't see that as a limiting factor. When I conduct a 
 search in DITS, I effectively search through labels. Of course 
 those labels present themselves as data fields/values in some 
 row of a table but they are labels none the less. If I want to 
 find issues filed under multiple labels, i simply include all 
 labels of interest in my search. The same is possible in 
 GitHub, except they are presented right there on the screen for 
 immediate access. Want to know how many "bug" request were 
 "closed" as "invalid" or "wontfix"? Click on the labels and 
 walla, your search is complete. I have had experienced zero 
 issues finding information on GitHub, in spite of their overly 
 simplistic interface.

You can _either_ use text search _or_ chose labels. This is critical IMHO.
Jun 15 2014
prev sibling next sibling parent Martin Nowak <code dawg.eu> writes:
On 06/15/2014 05:37 PM, Andrew Edwards wrote:
 Take issue #143 for instance. It is the oldest open issue on the DLang
 Issue Tracking System. Submitted by Jarrett Billingsley on May 17, 2006,
 it received one comment two days later but was ignored for four years
 before Michal Minich made the second comment. Another two years went by
 before Martin Nowak addressed the issue, which Walter promptly reverted
 (reason unknown). The end result? Eight years flew by and the issue
 remains unresolved.

The main reasons why issues get stuck are unfinished debates, missing decisions and the general lack of manpower. Prioritization, focus and a bit of planning would help most to improve this IMO.
Jun 15 2014
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 16 Jun 2014 00:35:33 +0200
Martin Nowak via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On 06/15/2014 05:37 PM, Andrew Edwards wrote:
 Take issue #143 for instance. It is the oldest open issue on the
 DLang Issue Tracking System. Submitted by Jarrett Billingsley on
 May 17, 2006, it received one comment two days later but was
 ignored for four years before Michal Minich made the second
 comment. Another two years went by before Martin Nowak addressed
 the issue, which Walter promptly reverted (reason unknown). The end
 result? Eight years flew by and the issue remains unresolved.

The main reasons why issues get stuck are unfinished debates, missing decisions and the general lack of manpower. Prioritization, focus and a bit of planning would help most to improve this IMO.

Exactly. I really don't think that moving the issues to github would help us much at all, and it would cost us quite a bit of time in terms of manpower (something that we're already sorely lacking), and from what I know of github's features, we'd end up with a bugtracker that was worse anyway. The only real advantage that it would have would be that it would be integrated with what we were using to do pull requests. And I don't think that that's anywhere near worth the cost. - Jonathan M Davis
Jun 15 2014
prev sibling next sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 2014-06-15 at 19:28 +0000, bearophile via Digitalmars-d wrote:
 Andrew Edwards:
 
 How do you recover your work from the GitHub five years from 
 now when GitHub falls off the edge of the earth

Online sites are ephemeral. So unless there is a way to move the bug repository off GitHub if the need arises, I am not going to appreciate the idea of moving bugs to GitHub.

Given the current site is equally ephemeral, isn't this a sophistic argument? Switching bug reporting systems is not-trivial, always. The issue though is workflow for those who "should" be using it. The point being made here is really: what is the best system for creating an active system of users reporting and developers fixing bugs. There has been a directly analogous argument going on with SCons. We shifted from Subversion on Tigris with it's bug tracker, to Mercurial on BitBucket but keeping the Tigris bug tracker because it has lots of wizzy functionality and the BitBucket bug tracker was poor. However despite the wizzy functionality of the bugtracker, it has become fallow – no-one uses it because it is not "front and centre" with the repository. However the BitBucket system is not good enough, and the Tigris one cannot be sanely connected to BitBucket. We are in the middle of experiments with a third way: an independent bugtracker that allows for two way linkage to the BitBucket repositories. It is a lot of work to prepare the ground and make the change, but it is being done because the current workflow is failing. Just because a bugtracker is a good one, doesn't make it one that is good to use in a given context. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jun 16 2014
prev sibling next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Andrew Edwards"  wrote in message news:lnkeji$5ve$1 digitalmars.com...

 This happens because we have two separate systems (one tracking problems, 
 another tracking the resolution), both of which compete for the same 
 precious and extremely limited resource: the volunteer time of developers.

I disagree, github is only manage because it has an order of magnitude less information. Having a prettier and more closely integrated bug tracker would be nice, but the disruption and information loss caused by switching makes it seem not worthwhile to me.
Jun 16 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Russel Winder:

 Given the current site is equally ephemeral,

The current site is under dlang.org, it's not ephemeral. Bye, bearophile
Jun 16 2014
prev sibling next sibling parent reply Byron Heads <byron.heads gmail.com> writes:
Does github link issues with pull requests (and the conversation) and 
commits?  Does it link issues with sub issues/tasks?  Can Issues link to 
other repos (link issues that are in both runtime and std lib)?  If it 
does have these features (and they are easy to use) then I would back it.

I have found jira to be one of the best trackers out there. 

-Byron
Jun 16 2014
next sibling parent "ed" <gmail gmail.com> writes:
On Monday, 16 June 2014 at 13:53:39 UTC, Byron Heads wrote:
 Does github link issues with pull requests (and the 
 conversation) and
 commits?  Does it link issues with sub issues/tasks?  Can 
 Issues link to
 other repos (link issues that are in both runtime and std lib)?
  If it
 does have these features (and they are easy to use) then I 
 would back it.

 I have found jira to be one of the best trackers out there.

 -Byron

I agree, but it is rather pricey for OSS.
Jun 16 2014
prev sibling next sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2014-06-17 at 02:24 +0000, ed via Digitalmars-d wrote:
[…]
 I agree, but it is rather pricey for OSS.

JIRA is free for FOSS projects if you apply to them and they agree. Groovy, GPars and Gant all use the Codehaus infrastructure that has a free JIRA and Bamboo. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jun 16 2014
prev sibling next sibling parent "ed" <gmail gmail.com> writes:
On Tuesday, 17 June 2014 at 06:07:22 UTC, Russel Winder via 
Digitalmars-d wrote:
 On Tue, 2014-06-17 at 02:24 +0000, ed via Digitalmars-d wrote:
 […]
 I agree, but it is rather pricey for OSS.

JIRA is free for FOSS projects if you apply to them and they agree. Groovy, GPars and Gant all use the Codehaus infrastructure that has a free JIRA and Bamboo.

Cool, I wasn't aware of this.
Jun 16 2014
prev sibling parent "Mathias LANG" <perso.mathias.lang gmail.com> writes:
On Monday, 16 June 2014 at 13:53:39 UTC, Byron Heads wrote:
 Does github link issues with pull requests (and the 
 conversation) and
 commits?  Does it link issues with sub issues/tasks?  Can 
 Issues link to
 other repos (link issues that are in both runtime and std lib)?
  If it
 does have these features (and they are easy to use) then I 
 would back it.

 I have found jira to be one of the best trackers out there.

 -Byron

It have. A pull request is just 'a kind of issue with code'. You can cross link to repository, as you would in commit message ( https://github.com/rejectedsoftware/vibe.d/commit/6f5b4c125db396c0e195 7824dbe108852315ab6 ). You also have github's markdown. /// See_Also: https://help.github.com/articles/writing-on-github#references Taking as an example: https://github.com/rejectedsoftware/vibe.d Github would have several advantages: + Better visibility: you can see directly the number of issues, and they are more likely to stay in sync with the code; + Better documentation: you can do the PR without having to fill an issue for it, so the problem and the fix are in the same place (for the changelog); + No maintenance cost; + Nicer interface: https://github.com/rejectedsoftware/vibe.d/pulse/monthly + Markdown: HUGE plus IMO (for code, or even direct linking to a specific file/commit). + WIP: if someone is working on something in his fork, and put as commit message "[...], fix #650", github detects it and will put a link to the commit in the main repository, so you can see if someone is working on it. Example: https://github.com/rejectedsoftware/vibe.d/issues/655#ref-commit-5d80a00 (each rebase is referenced) Overall, if we were to start over, I would advocate usage of Github's issues. It's simple, yet powerful: it does the job well, and is way more convenient/accessible to use than bugzilla, given one has no prior knowledge. However, we are not to start over, and someone would have to do the job if we were to change. I'm sure using github issues over bugzilla would be worthy, but switching would be extermely expensive in manpower. Here's some big projects that use issues: https://github.com/rust-lang/rust https://github.com/angular/angular.js https://github.com/dotcloud/docker
Jun 17 2014
prev sibling next sibling parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Sunday, 15 June 2014 at 15:37:22 UTC, Andrew Edwards wrote:
 Observe the following truths:
     1) Issue tricking and resolution are kept separate in our 
 community
     2) That which is not visible garners no attention

Your message has not convinced me that the change would address the issues present. From what I've seen Bugzilla has integrated well with Github. Mentioning a bug in a conversation may not get an autolink, but that doesn't sound like the issue trying to be solved.
Jun 16 2014
parent reply Andrew Edwards <ridimz yahoo.com> writes:
On 6/16/14, 10:09 PM, Jesse Phillips wrote:
 On Sunday, 15 June 2014 at 15:37:22 UTC, Andrew Edwards wrote:
 Observe the following truths:
     1) Issue tricking and resolution are kept separate in our community
     2) That which is not visible garners no attention

Your message has not convinced me that the change would address the issues present. From what I've seen Bugzilla has integrated well with Github. Mentioning a bug in a conversation may not get an autolink, but that doesn't sound like the issue trying to be solved.

The issue I'm trying to solve is to make "issues" more visible to people who work on them. By putting those issues in the same location where developers work, they immediately become more visible. Does it solve the overall problem? No, definitely not! Doing so will not "MAKE" anyone properly categorize, update, or even look at those issues. But it does them more and therefore, garners more attention than if it were hidden away in a separate system. I log into github and, even though I'm unable to do much to improve the situation by way of coding knowledge, I cannot but help clicking on the list of outstanding pull requests, or the pulse tab to get a quick glance of what's happening. If the issues where there, I would click on them too: who knows, there may be a problem that I can solve. Comparatively, the only time I access bugzilla is to check the list of regressions when preparing for release. That doesn't even require me to go to the system... just copy the link from the last message I posted. The argument I'm hearing from the majority (at least those who choose to respond) is "too much work for minimal gain." My question is too much work for who? I'm volunteering to do the entire move myself. All the community has to do is start creating new issues in GitHub and, until such time as all reports are transferred to GitHub, continue to closeout task on bugzilla where appropriate. That is no more work than what is being done now because we are already using both systems.
Jun 17 2014
next sibling parent Andrew Edwards <ridimz yahoo.com> writes:
Understood... Sorry for the noise.

On 6/17/14, 9:53 AM, Steven Schveighoffer wrote:
 On Tue, 17 Jun 2014 09:23:50 -0400, Andrew Edwards <ridimz yahoo.com>
 wrote:

 On 6/16/14, 10:09 PM, Jesse Phillips wrote:
 On Sunday, 15 June 2014 at 15:37:22 UTC, Andrew Edwards wrote:
 Observe the following truths:
     1) Issue tricking and resolution are kept separate in our community
     2) That which is not visible garners no attention

Your message has not convinced me that the change would address the issues present. From what I've seen Bugzilla has integrated well with Github. Mentioning a bug in a conversation may not get an autolink, but that doesn't sound like the issue trying to be solved.

The issue I'm trying to solve is to make "issues" more visible to people who work on them. By putting those issues in the same location where developers work, they immediately become more visible. Does it solve the overall problem? No, definitely not! Doing so will not "MAKE" anyone properly categorize, update, or even look at those issues. But it does them more and therefore, garners more attention than if it were hidden away in a separate system.

I don't think this is an issue. All developers looking at bugs and/or pull requests know that they are two different systems. The two systems are linked, generally by the post-commit hook on github. Also, these statements are lacking some basis in evidence. Are there developers who work on any of our projects who agree with this statement? It's not always worth looking at who "might" work on it if we do X or Y, as that group of people often is all talk. I think the largest issue is the daunting backlog of open bugs in bugzilla. You can close 100 bugs and still not really make a dent in it. Bugzilla has recently improved quite a bit. Little things are now much more pleasant (e.g. keywords now pop up a list of valid keywords instead of having to click on a separate page to see them).
 The argument I'm hearing from the majority (at least those who choose
 to respond) is "too much work for minimal gain." My question is too
 much work for who? I'm volunteering to do the entire move myself.

I don't think that's the main argument, I think the main argument is that github issues does not have comparable features, which means we lose data and/or functions if we switch over. I don't think the fact that both would be on the same site is enough of a gain to offset that. -Steve

Jun 17 2014
prev sibling parent Andrew Edwards <ridimz yahoo.com> writes:
On 6/17/14, 10:32 AM, Jesse Phillips wrote:
 On Tuesday, 17 June 2014 at 13:23:48 UTC, Andrew Edwards wrote:
 The issue I'm trying to solve is to make "issues" more visible to
 people who work on them. By putting those issues in the same location
 where developers work, they immediately become more visible. Does it
 solve the overall problem? No, definitely not! Doing so will not
 "MAKE" anyone properly categorize, update, or even look at those
 issues. But it does them more and therefore, garners more attention
 than if it were hidden away in a separate system.

I don't see it being resulting in more visibility. Maybe for outsiders wanting check out the project and wanting to submit a bug. But developers know where both are and start with Bugzilla, then Github (a bug can be completed without ever touching Github, and likely a command-line tool exists to author a pull request.)

Again... I understand. We can stop the discussion now.
 Are you aware of the bugs NG which gets a new entry for each bug
 and comment? This was the old way of reporting bugs... people may
 even use it for tracking new bugs and development.

No desire to further the conversation.
Jun 17 2014
prev sibling next sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 2014-06-16 at 09:28 +0000, bearophile via Digitalmars-d wrote:
 Russel Winder:
 
 Given the current site is equally ephemeral,

The current site is under dlang.org, it's not ephemeral.

I quote from your email of Sunday 2014-06-15 20:28+0100 which is the one I replied to: "Online sites are ephemeral." dlang.org is an online site I believe. Given this is totally non-constructive debate, I propose stopping it now and getting on with stuff that is constructive. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jun 16 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 17 Jun 2014 09:23:50 -0400, Andrew Edwards <ridimz yahoo.com>  
wrote:

 On 6/16/14, 10:09 PM, Jesse Phillips wrote:
 On Sunday, 15 June 2014 at 15:37:22 UTC, Andrew Edwards wrote:
 Observe the following truths:
     1) Issue tricking and resolution are kept separate in our community
     2) That which is not visible garners no attention

Your message has not convinced me that the change would address the issues present. From what I've seen Bugzilla has integrated well with Github. Mentioning a bug in a conversation may not get an autolink, but that doesn't sound like the issue trying to be solved.

The issue I'm trying to solve is to make "issues" more visible to people who work on them. By putting those issues in the same location where developers work, they immediately become more visible. Does it solve the overall problem? No, definitely not! Doing so will not "MAKE" anyone properly categorize, update, or even look at those issues. But it does them more and therefore, garners more attention than if it were hidden away in a separate system.

I don't think this is an issue. All developers looking at bugs and/or pull requests know that they are two different systems. The two systems are linked, generally by the post-commit hook on github. Also, these statements are lacking some basis in evidence. Are there developers who work on any of our projects who agree with this statement? It's not always worth looking at who "might" work on it if we do X or Y, as that group of people often is all talk. I think the largest issue is the daunting backlog of open bugs in bugzilla. You can close 100 bugs and still not really make a dent in it. Bugzilla has recently improved quite a bit. Little things are now much more pleasant (e.g. keywords now pop up a list of valid keywords instead of having to click on a separate page to see them).
 The argument I'm hearing from the majority (at least those who choose to  
 respond) is "too much work for minimal gain." My question is too much  
 work for who? I'm volunteering to do the entire move myself.

I don't think that's the main argument, I think the main argument is that github issues does not have comparable features, which means we lose data and/or functions if we switch over. I don't think the fact that both would be on the same site is enough of a gain to offset that. -Steve
Jun 17 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 17 June 2014 at 13:23:48 UTC, Andrew Edwards wrote:
 The argument I'm hearing from the majority (at least those who 
 choose to respond) is "too much work for minimal gain."

I stand by the point that gain is not minimal, it is actually negative. Loss of power search tools is huge damage, absolutely not worth better exposure. We use GitHub issues for project management at Sociomantic and it is very inconvenient even with 100+ open issues. I simply can't imagine this working for bug database of DMD/Phobos size.
Jun 17 2014
prev sibling next sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Tuesday, 17 June 2014 at 13:23:48 UTC, Andrew Edwards wrote:
 The issue I'm trying to solve is to make "issues" more visible 
 to people who work on them. By putting those issues in the same 
 location where developers work, they immediately become more 
 visible. Does it solve the overall problem? No, definitely not! 
 Doing so will not "MAKE" anyone properly categorize, update, or 
 even look at those issues. But it does them more and therefore, 
 garners more attention than if it were hidden away in a 
 separate system.

I don't see it being resulting in more visibility. Maybe for outsiders wanting check out the project and wanting to submit a bug. But developers know where both are and start with Bugzilla, then Github (a bug can be completed without ever touching Github, and likely a command-line tool exists to author a pull request.) Are you aware of the bugs NG which gets a new entry for each bug and comment? This was the old way of reporting bugs... people may even use it for tracking new bugs and development.
Jun 17 2014
prev sibling parent Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 15/06/14 17:37, Andrew Edwards via Digitalmars-d wrote:
 Observe the following truths:
      1) Issue tricking and resolution are kept separate in our community
      2) That which is not visible garners no attention

Without wanting to get into the broader debate going on here, there are a few things that can easily be done to fix the visibility problem: add a link to the issue tracker right next to the top of the README file for dmd and druntime. Phobos already has such a link, but it's to the old address d.puremagic.com, so that needs to be updated. In principle this could be supplemented by adding one GitHub issue to each project, titled something like "Issue tracking is provided on issues.dlang.org".
 Take issue #143 for instance. It is the oldest open issue on the DLang Issue
 Tracking System. Submitted by Jarrett Billingsley on May 17, 2006, it received
 one comment two days later but was ignored for four years before Michal Minich
 made the second comment. Another two years went by before Martin Nowak
addressed
 the issue, which Walter promptly reverted (reason unknown). The end result?
 Eight years flew by and the issue remains unresolved.

 This happens because we have two separate systems (one tracking problems,
 another tracking the resolution), both of which compete for the same precious
 and extremely limited resource: the volunteer time of developers.

I don't think that competition for attention between GitHub and issues.dlang.org is really the problem here. The problem is that when you have a scale of issues as we do, it's easy for individual issues to get lost unless someone goes out of their way to find and address them. Actually, in my experience, GitHub issues become pretty difficult to keep track of with far fewer total open issues. If there is an issue with issues.dlang.org it's probably the good old "multiple logins" problem: perhaps some people don't sign up to report or comment on issues because they can't be bothered to have Yet Another Login.
Jun 17 2014