I couldn't find the old thread about Sourceforge bug tracker vs. the Github issue tracker, but maybe we should reevaluate based on the new Github issue tracker announced on Saturday:
https://github.com/blog/831-issues-2-0-the-next-generation
The integration with git commits (closing issues by mentioning them in the commit message) is particularly compelling.
Cheers,
Mike
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA
The new issue tracker is a really big improvement over the old github
tracker, and I prefer it to the one at sourceforge since it integrates
so nicely with github version control. The github tracker is still
missing some features that we may want to consider: prioritize issues,
add attachments, and perhaps report issues without opening a github
account.
On Mon, Apr 11, 2011 at 12:13 PM, Michael Droettboom <mdroe@...31...> wrote:
I couldn't find the old thread about Sourceforge bug tracker vs. the
Github issue tracker, but maybe we should reevaluate based on the new
Github issue tracker announced on Saturday:Issues 2.0: The Next Generation - The GitHub Blog
The integration with git commits (closing issues by mentioning them in
the commit message) is particularly compelling.
Darren Dale, on 2011-04-11 13:24, wrote:
> I couldn't find the old thread about Sourceforge bug tracker vs. the
> Github issue tracker, but maybe we should reevaluate based on the new
> Github issue tracker announced on Saturday:
>
> Issues 2.0: The Next Generation - The GitHub Blog
>
> The integration with git commits (closing issues by mentioning them in
> the commit message) is particularly compelling.The new issue tracker is a really big improvement over the old github
tracker, and I prefer it to the one at sourceforge since it integrates
so nicely with github version control. The github tracker is still
missing some features that we may want to consider: prioritize issues,
add attachments, and perhaps report issues without opening a github
account.
I'm fine either way - though moving to GitHub certainly makes
sense as it has momentum - whereas SF.net has been stagnating and
not getting any faster for quite some time now.
My only concern / request is that we transfer and/or clean up
(wholesale) the sf.net bug tracker before we move to GH. It'd be
a disservice to our users if we just ignored or mass-closed those
issues in the transition to GH.
best,
On Mon, Apr 11, 2011 at 12:13 PM, Michael Droettboom <mdroe@...31...> wrote:
--
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
I spent a weekend working on porting the issues to github.
GitHub - ddale/mpl-issues contains an xml dump of the
sourceforge tracker, along with the script I used to parse the dump
file, filter it, and upload the issues to that repo. It could be
improved to add labels, assign to developers, assign milestones, once
github provides API access to issues-2.0.
On Mon, Apr 11, 2011 at 3:02 PM, Paul Ivanov <pivanov314@...149...> wrote:
Darren Dale, on 2011-04-11 13:24, wrote:
On Mon, Apr 11, 2011 at 12:13 PM, Michael Droettboom <mdroe@...31...> wrote:
> I couldn't find the old thread about Sourceforge bug tracker vs. the
> Github issue tracker, but maybe we should reevaluate based on the new
> Github issue tracker announced on Saturday:
>
> Issues 2.0: The Next Generation - The GitHub Blog
>
> The integration with git commits (closing issues by mentioning them in
> the commit message) is particularly compelling.The new issue tracker is a really big improvement over the old github
tracker, and I prefer it to the one at sourceforge since it integrates
so nicely with github version control. The github tracker is still
missing some features that we may want to consider: prioritize issues,
add attachments, and perhaps report issues without opening a github
account.I'm fine either way - though moving to GitHub certainly makes
sense as it has momentum - whereas SF.net has been stagnating and
not getting any faster for quite some time now.My only concern / request is that we transfer and/or clean up
(wholesale) the sf.net bug tracker before we move to GH. It'd be
a disservice to our users if we just ignored or mass-closed those
issues in the transition to GH.
It is better, but to my eye, still not good.
Prioritization can be handled via labels or milestones, but the lack of a simple, obvious attachment facility is a huge omission. As far as I know there is also no simple set of categories for closed status--maybe that would also be done with labels. (I'm not positive; I have not closed an item, and nothing happens when I click the "60 closed issues" tab, expecting to see the closed issues. Similarly, nothing happens when I click the "submitted" "updated", and "comments" buttons. Maybe all these things are bugs that show up if one does not have Firefox 4 or Chrome?) The automatic, compulsory, irrevocable Markdown parsing of all comments is a horrible design, and all the more so in the absence of file up/download facility.
It's being used; I think we are stuck with it. I have no objection to getting the migration over with, if you have the machinery to do it, Dale.
Eric
On 04/11/2011 07:24 AM, Darren Dale wrote:
On Mon, Apr 11, 2011 at 12:13 PM, Michael Droettboom<mdroe@...31...> wrote:
I couldn't find the old thread about Sourceforge bug tracker vs. the
Github issue tracker, but maybe we should reevaluate based on the new
Github issue tracker announced on Saturday:Issues 2.0: The Next Generation - The GitHub Blog
The integration with git commits (closing issues by mentioning them in
the commit message) is particularly compelling.The new issue tracker is a really big improvement over the old github
tracker, and I prefer it to the one at sourceforge since it integrates
so nicely with github version control. The github tracker is still
missing some features that we may want to consider: prioritize issues,
add attachments, and perhaps report issues without opening a github
account.
I couldn't find the old thread about Sourceforge bug tracker vs. the
Github issue tracker, but maybe we should reevaluate based on the new
Github issue tracker announced on Saturday:Issues 2.0: The Next Generation - The GitHub Blog
The integration with git commits (closing issues by mentioning them in
the commit message) is particularly compelling.
The new issue tracker is a really big improvement over the old github
tracker, and I prefer it to the one at sourceforge since it integrates
so nicely with github version control. The github tracker is still
missing some features that we may want to consider: prioritize issues,
add attachments, and perhaps report issues without opening a github
account.
It is better, but to my eye, still not good.
Prioritization can be handled via labels or milestones, but the lack of
a simple, obvious attachment facility is a huge omission. As far as I
know there is also no simple set of categories for closed status--maybe
that would also be done with labels.
Labels could be used for that purpose -- but it would be "by convention", so I can imagine we'd forget to do that from time to time.
(I'm not positive; I have not
closed an item, and nothing happens when I click the "60 closed issues"
tab, expecting to see the closed issues. Similarly, nothing happens
when I click the "submitted" "updated", and "comments" buttons.
I see this too. And I think we're not the only ones -- there's a bug filed about it:
(Hmm... git doesn't use its own issue tracker for tracking its own issues... what does that say? <wink>)
Maybe
all these things are bugs that show up if one does not have Firefox 4 or
Chrome?) The automatic, compulsory, irrevocable Markdown parsing of all
comments is a horrible design,
The Wikis on github support a handful of formatting languages, including reStructuredText (which is what my fingers know best) -- so they "have the technology" to do something else. But honestly, for short issue comments, I think plain text is the best choice.
and all the more so in the absence of
file up/download facility.
They've got gist, of course, but it is neither easy or intuitive for casual use.
Mike
On 04/11/2011 03:51 PM, Eric Firing wrote:
On 04/11/2011 07:24 AM, Darren Dale wrote:
On Mon, Apr 11, 2011 at 12:13 PM, Michael Droettboom<mdroe@...31...> wrote:
It's being used; I think we are stuck with it. I have no objection to
getting the migration over with, if you have the machinery to do it, Dale.Eric
------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now! http://p.sf.net/sfu/ibm-webcastpromo
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA
Brilliant, whatever they use allows uploading attachments.
On Mon, Apr 11, 2011 at 3:40 PM, Michael Droettboom <mdroe@...31...> wrote:
(Hmm... git doesn't use its own issue tracker for tracking its own
issues... what does that say? <wink>)
Maybe it would be made available for “Issues: Deep Space Nine”, or do I have to wait until “Voyager”?
Ben Root
On Mon, Apr 11, 2011 at 4:19 PM, Darren Dale <dsdale24@…55…149…> wrote:
On Mon, Apr 11, 2011 at 3:40 PM, Michael Droettboom <mdroe@…31…> wrote:
(Hmm… git doesn’t use its own issue tracker for tracking its own
issues… what does that say? )
Brilliant, whatever they use allows uploading attachments.
They are using this: http://tenderapp.com/
On 04/11/2011 11:19 AM, Darren Dale wrote:
On Mon, Apr 11, 2011 at 3:40 PM, Michael Droettboom<mdroe@...31...> wrote:
(Hmm... git doesn't use its own issue tracker for tracking its own
issues... what does that say?<wink>)Brilliant, whatever they use allows uploading attachments.
I know this isn't ideal, but a workaround for screenshots/images in
mpl bug reports would be to upload them to something like imgur (free
- no registration required):
and then put the image link in the markdown for the bug report:
I realize it's a workaround, but better than nothing...
f
On Mon, Apr 11, 2011 at 2:19 PM, Darren Dale <dsdale24@...149...> wrote:
Brilliant, whatever they use allows uploading attachments.
I'm willing to continue working on the conversion, iff (not a typo) it
is what the other developers want. It may be a while before I could
get to it though.
Darren
On Mon, Apr 11, 2011 at 3:51 PM, Eric Firing <efiring@...229...> wrote:
On 04/11/2011 07:24 AM, Darren Dale wrote:
On Mon, Apr 11, 2011 at 12:13 PM, Michael Droettboom<mdroe@...31...> wrote:
I couldn't find the old thread about Sourceforge bug tracker vs. the
Github issue tracker, but maybe we should reevaluate based on the new
Github issue tracker announced on Saturday:Issues 2.0: The Next Generation - The GitHub Blog
The integration with git commits (closing issues by mentioning them in
the commit message) is particularly compelling.The new issue tracker is a really big improvement over the old github
tracker, and I prefer it to the one at sourceforge since it integrates
so nicely with github version control. The github tracker is still
missing some features that we may want to consider: prioritize issues,
add attachments, and perhaps report issues without opening a github
account.It is better, but to my eye, still not good.
Prioritization can be handled via labels or milestones, but the lack of
a simple, obvious attachment facility is a huge omission. As far as I
know there is also no simple set of categories for closed status--maybe
that would also be done with labels. (I'm not positive; I have not
closed an item, and nothing happens when I click the "60 closed issues"
tab, expecting to see the closed issues. Similarly, nothing happens
when I click the "submitted" "updated", and "comments" buttons. Maybe
all these things are bugs that show up if one does not have Firefox 4 or
Chrome?) The automatic, compulsory, irrevocable Markdown parsing of all
comments is a horrible design, and all the more so in the absence of
file up/download facility.It's being used; I think we are stuck with it. I have no objection to
getting the migration over with, if you have the machinery to do it, Dale.