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.


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 reply 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
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 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
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 parent reply 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


same time, but since we are already doing that, it does not add to the 

there is no automatic way to get it done, I am willing to personally 
migrate every single report by hand.
Jun 15 2014
parent reply "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
parent reply 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
parent reply "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
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 Walter Bright <newshound2 digitalmars.com> writes:
On 6/15/2014 8:37 AM, Andrew Edwards wrote:




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.


 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 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.


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 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
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 parent reply "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
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 reply Martin Nowak <code dawg.eu> writes:
On 06/15/2014 05:37 PM, Andrew Edwards wrote:


 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
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:


 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 "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 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 reply "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
parent reply 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
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 

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 reply "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
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 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 parent reply "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
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 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".



 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