Do we really need a centralized bug-tracker or would it be best to leave that to the individual packages, e.g., using the github tracker via the github-svn-bridge? Many are probably already doing that.
Michael On Fri, May 23, 2014 at 11:16 AM, Cook, Malcolm <m...@stowers.org> wrote: > Martin, > > I'm sure you're watching this thread..... > > Can we take it as some "feedback from other developers" that you requested > way back in > https://stat.ethz.ch/pipermail/bioc-devel/2011-October/002854.html when I > wished for similar.... > > In any case, > > +1, > > Malcolm > > >-----Original Message----- > >From: bioc-devel-boun...@r-project.org [mailto: > bioc-devel-boun...@r-project.org] On Behalf Of Keith Hughitt > >Sent: Friday, May 23, 2014 12:53 PM > >To: Nicolas Delhomme > >Cc: bioc-devel@r-project.org > >Subject: Re: [Bioc-devel] Bug tracker for Bioconductor? > > > >Hi Nico, > > > >It's a shame that the effort did not gain more traction in 2004. I wonder > >if things would look differently now as the community has grown > >significantly larger? > > > >It does seem like there are a relatively small number of bug-related > >questions on the mailing lists. I wonder though if this could be in part > >because some people may be hesitant to ask their questions on such a > large > >list, and instead end up either forgoing the question or contacting the > >software authors directly? > > > >Also, even if there is only a trickle of bug and feature-request related > >posts to the mailing list across time, without any way to keep track of > how > >many of those issues are open/unresolved, it's hard to gauge whether the > >project really is low-maintenance, or if there are actually a large > number > >of issues that have just been unanswered or forgotten. > > > >There would definitely be a burden associated with setting up a more > >sophisticated system for dealing with bugs. I am just not convinced that > >the burden would be too great, or that it is not worth taking on :) > > > >Cheers, > >Keith > > > > > >On Tue, May 20, 2014 at 10:33 AM, Nicolas Delhomme > ><nicolas.delho...@umu.se>wrote: > > > >> Hej Keith! > >> > >> I agree that this would be useful. For having been very close to the > 2004 > >> attempt - a then colleague of mine set up a solution similar to what > you > >> describe - I can tell you that the main reason for it dying out was > that > >> despite advertising it, it never got widely used. I donât know what the > >> reasons for that really were, but from experience I know that many > fellow > >> bioinformaticians find such tools more time-consuming than handling > bug > >> tracking through emails. And after all very few packages require > frequent > >> support, as can be devised from questions to the mailing list, so I do > >> understand their point. > >> > >> Cheers, > >> > >> Nico > >> > >> --------------------------------------------------------------- > >> Nicolas Delhomme > >> > >> The Street Lab > >> Department of Plant Physiology > >> UmeÃ¥ Plant Science Center > >> > >> Tel: +46 90 786 5478 > >> Email: nicolas.delho...@plantphys.umu.se > >> SLU - UmeÃ¥ universitet > >> UmeÃ¥ S-901 87 Sweden > >> --------------------------------------------------------------- > >> > >> On 20 May 2014, at 15:04, Keith Hughitt <keith.hugh...@gmail.com> > wrote: > >> > >> > Hello all, > >> > > >> > I was wondering if there had been any progress towards adopting a bug > >> > tracking system for Bioconductor? > >> > > >> > It has been discussed at least a couple times in the past, e.g.: > >> > > >> > - > https://stat.ethz.ch/pipermail/bioc-devel/2011-October/002844.html > >> > - > https://stat.ethz.ch/pipermail/bioc-devel/2004-October/000040.html > >> > > >> > But as far as I can tell, no such system has been set up and the > current > >> > approach is to report issues to the mailing list. > >> > > >> > The main reasons I see for adopting such a system would be: > >> > > >> > 1. Centralized location for reporting and tracking bugs and feature > >> > requests; this also makes it more straight-forward to see if anyone > else > >> > has already reported a specific issue. > >> > > >> > 2. Ability to associate a given issue with specific a project > >> > > >> > 3. Ability to assign priorities to various issues and assign > developers > >> to > >> > work on them. > >> > > >> > 4. Easy to track changes made to a given release. > >> > > >> > 5. Separate usage and development discussion (mailing list) for > >> > issue-related discussion. > >> > > >> > Something like trac <http://trac.edgewall.org/> would be sufficient > to > >> > cover all of the above issues, although something with closer > integration > >> > to the codebase such as Github <https://github.com/> or > >> > Bitbucket<https://bitbucket.org/>might provide some additional > >> > benefits. Of course, migrating to a separate > >> > VCS not a trivial matter and would itself merit a separate > discussion. > >> > > >> > A couple examples of issue trackers working well for R projects: > >> > > >> > https://github.com/hadley/ggplot2/issues > >> > https://github.com/yihui/knitr > >> > > >> > Thank you all for your excellent work on Bioconductor! It is a really > >> > amazing resource. > >> > > >> > Regards, > >> > Keith > >> > > >> > [[alternative HTML version deleted]] > >> > > >> > _______________________________________________ > >> > Bioc-devel@r-project.org mailing list > >> > https://stat.ethz.ch/mailman/listinfo/bioc-devel > >> > >> > > > > [[alternative HTML version deleted]] > > _______________________________________________ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > [[alternative HTML version deleted]]
_______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
