On Fri, May 23, 2014 at 12:42 PM, Kasper Daniel Hansen <
kasperdanielhansen at gmail.com> wrote:
I want to remind some posters in this thread that most Bioconductor
packages are being developed by non-overlapping sets of people and
that it
is therefore not clear at all that a common bug tracker across the
project
is necessary (says the person who has definitely "lost" bugs
reported per
email).
For example, with the new github bridge I am intending to use
github as a
devel repository for my packages because I get 1) pull requests
(aka bug
fixes and feature enhancements) and 2) bug tracking. But this
workflow may
not work well for everyone.
In general, for every bug reported on the email list I get quite a
few
more private emails. But the flip side is that the number of bugs
reported
for me packages is much smaller than the number of bugs reported
across all
bioc packages,
Best,
Kasper
On Fri, May 23, 2014 at 3:35 PM, Cook, Malcolm <MEC at stowers.org>
wrote:
Michael,
Well, BioC has many suggestions and requirements for how packages
are to
be constructed, documented, and deployed.
http://www.bioconductor.org/developers/package-guidelines/
The only thing about bugs is: Response to bug reports and
questions from
users regarding your package as posted on the bioconductor mailing
list.
I think this is minimalistic.
In a similar vein as your suggestion, though, this might read
instead ?as
posted on the some mailing list of your choosing but you don?t
have to let
us know what it is.?
I hope I am sort of funny.
Sort of.
So, to answer your question ?do we really need...?, I?d vote
+2
!Malcolm
From: Michael Lawrence [mailto:lawrence.michael at gene.com]
Sent: Friday, May 23, 2014 1:31 PM
To: Cook, Malcolm
Cc: Keith Hughitt; Nicolas Delhomme; Martin Morgan;
bioc-devel at r-project.org
Subject: Re: [Bioc-devel] Bug tracker for Bioconductor?
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
<MEC at stowers.org<mailto:
MEC at 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-bounces at r-project.org<mailto:
bioc-devel-bounces at r-project.org> [mailto:
bioc-devel-bounces at r-project.org<mailto:bioc-devel-bounces at r-project.org>]
On Behalf Of Keith Hughitt
>Sent: Friday, May 23, 2014 12:53 PM
>To: Nicolas Delhomme
>Cc: bioc-devel at r-project.org<mailto:bioc-devel at 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
>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
>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
>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
>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.delhomme at umu.se<mailto:nicolas.delhomme at umu.se>>wrote:
>> Hej Keith!
>>
>> I agree that this would be useful. For having been very close
>> to the
>> attempt - a then colleague of mine set up a solution similar
>> to what
>> describe - I can tell you that the main reason for it dying
>> out was
>> despite advertising it, it never got widely used. I don?t know
>> what
>> reasons for that really were, but from experience I know that
>> many
>> bioinformaticians find such tools more time-consuming than
>> handling
>> tracking through emails. And after all very few packages
>> require
>> 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<tel:%2B46%2090%20786%205478>
>> Email: nicolas.delhomme at plantphys.umu.se<mailto:
nicolas.delhomme at plantphys.umu.se>
>> SLU - Ume? universitet
>> Ume? S-901 87 Sweden
>> ---------------------------------------------------------------
>>
>> On 20 May 2014, at 15:04, Keith Hughitt
>> <keith.hughitt at gmail.com
<mailto:keith.hughitt at gmail.com>> wrote:
>> > Hello all,
>> >
>> > I was wondering if there had been any progress towards
>> > adopting a
>> > tracking system for Bioconductor?
>> >
>> > It has been discussed at least a couple times in the past,
>> > e.g.:
>> >
>> > -
>> >
>> > But as far as I can tell, no such system has been set up and
>> > the
>> > 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
>> > 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
>> > 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
>> > cover all of the above issues, although something with
>> > closer
>> > 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
>> > amazing resource.
>> >
>> > Regards,
>> > Keith
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > _______________________________________________
>> > Bioc-devel at r-project.org<mailto:Bioc-devel at r-project.org>
>> > mailing
>
> [[alternative HTML version deleted]]