Re: Out of sight out of mind
On Mon, 2014-06-16 at 09:28 +, 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.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Out of sight out of mind
On Tue, 2014-06-17 at 02:24 +, 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.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Out of sight out of mind
On Tuesday, 17 June 2014 at 06:07:22 UTC, Russel Winder via Digitalmars-d wrote: On Tue, 2014-06-17 at 02:24 +, 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.
Re: Out of sight out of mind
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/6f5b4c125db396c0e195e7824dbe108852315ab6 ). 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
Re: Out of sight out of mind
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.
Re: Out of sight out of mind
On Tue, 17 Jun 2014 09:23:50 -0400, Andrew Edwards rid...@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
Re: Out of sight out of mind
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 rid...@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
Re: Out of sight out of mind
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.
Re: Out of sight out of mind
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.
Re: Out of sight out of mind
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.
Re: Out of sight out of mind
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.
Re: Out of sight out of mind
On Sun, 2014-06-15 at 19:28 +, 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.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Out of sight out of mind
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.
Re: Out of sight out of mind
Russel Winder: Given the current site is equally ephemeral, The current site is under dlang.org, it's not ephemeral. Bye, bearophile
Re: Out of sight out of mind
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
Re: Out of sight out of mind
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.
Re: Out of sight out of mind
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.
Out of sight out of mind
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
Re: Out of sight out of mind
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.
Re: Out of sight out of mind
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
Re: Out of sight out of mind
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.
Re: Out of sight out of mind
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.
Re: Out of sight out of mind
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.
Re: Out of sight out of mind
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
Re: Out of sight out of mind
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.
Re: Out of sight out of mind
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
Re: Out of sight out of mind
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
Re: Out of sight out of mind
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.
Re: Out of sight out of mind
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
Re: Out of sight out of mind
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
Re: Out of sight out of mind
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.
Re: Out of sight out of mind
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.
Re: Out of sight out of mind
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.
Re: Out of sight out of mind
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
