matplotlib-devel Mailing List for matplotlib

Hi Darren,

> -----Message d'origine-----
> De : Darren Dale [mailto:dsd...@gm...] 
> Envoyé : dimanche 27 février 2011 22:02
> À : Pierre Raybaut
> Cc : matplotlib-devel
> Objet : Re: [matplotlib-devel] Enhancement to matplotlib's 
> PyQt4 backend
> 
> On Sun, Feb 27, 2011 at 3:27 PM, Darren Dale 
> <dsd...@gm...> wrote:
> > Hi Pierre,
> >
> > Are you still maintaining the qt4 plot editor dialog? It doesn't 
> > appear to be working properly: setting the marker and linestyle 
> > options does not effect the plot (tested on Ubuntu Natty 
> alpha, with 
> > the v1.0.x branch on python-2.7 and PyQt4-4.8.3).
> 
> Sorry, I think this was a mistake on my part...
> 
> > I have a really hard
> > time following the code.
> 
> ... but I do have a really hard time understanding the code.

Well it seems quite self-explanatory to me (especially the 'formlayout'
module which is very OO which tends to hide code complexity), hence the lack
of comments. But hey, I wrote it so I guess it's easier for me to read it.
Anyway, please don't hesitate to ask questions about the part of the code
that seems unclear.

> > Also, the dialog makes the qt4 backend unusable with 
> PyQt4's API v2, 
> > which does not provide a QString object.
> 
> This can be addressed with the following change, which I just
> 
> @@ -56,9 +56,9 @@ from PyQt4.QtGui import (QWidget, 
> QLineEdit, QComboBox, QLabel
>                           QPixmap, QTabWidget, QApplication, 
> QStackedWidget,
>                           QDateEdit, QDateTimeEdit, QFont, 
> QFontComboBox,
>                           QFontDatabase, QGridLayout) -from 
> PyQt4.QtCore import (Qt, SIGNAL, SLOT, QSize, QString,
> +from PyQt4.QtCore import (Qt, SIGNAL, SLOT, QObject, QSize,
>                            pyqtSignature, pyqtProperty) 
> import datetime
> 
> 
>  class ColorButton(QPushButton):
> @@ -102,7 +102,8 @@ def text_to_qcolor(text):
>      Avoid warning from Qt when an invalid QColor is instantiated
>      """
>      color = QColor()
> -    if isinstance(text, QString):
> +    if isinstance(text, QObject):
> +        # actually a QString, which is not provided by the 
> new PyQt4 API:
>          text = str(text)
>      if not isinstance(text, (unicode, str)):
>          return color
> 

This seems ok to me.

Cheers,
Pierre

On Sun, Feb 27, 2011 at 9:45 AM, Darren Dale <dsd...@gm...> wrote:
> On Sun, Feb 27, 2011 at 8:32 AM, Darren Dale <dsd...@gm...> wrote:
>> If we are not convinced that github issues provides
>> everything we need, I think we should provide feedback to the github
>> devs and stick with sourceforge for the time being.
>
> Here is a copy of a message I just sent to su...@gi.... If you
> have other specific concerns, please let me know, and I will pass them
> along if I hear back from someone at github.

Here is the exchange I had with one of github's support staff:

GH: Thank you very much for your feedback. We already work on improving issues.

DD: Thank you for your reply. Is it ok if I relay this information to
the other developers on my project?

GH: Yes, but let me just say that we never have an ETA and also I
can't confirm that you'll be completely satisfied with our
improvements.

On Sun, Feb 27, 2011 at 3:27 PM, Darren Dale <dsd...@gm...> wrote:
> Hi Pierre,
>
> Are you still maintaining the qt4 plot editor dialog? It doesn't
> appear to be working properly: setting the marker and linestyle
> options does not effect the plot (tested on Ubuntu Natty alpha, with
> the v1.0.x branch on python-2.7 and PyQt4-4.8.3).

Sorry, I think this was a mistake on my part...

> I have a really hard
> time following the code.

... but I do have a really hard time understanding the code.

> Also, the dialog makes the qt4 backend
> unusable with PyQt4's API v2, which does not provide a QString object.

This can be addressed with the following change, which I just

@@ -56,9 +56,9 @@ from PyQt4.QtGui import (QWidget, QLineEdit, QComboBox, QLabel
                          QPixmap, QTabWidget, QApplication, QStackedWidget,
                          QDateEdit, QDateTimeEdit, QFont, QFontComboBox,
                          QFontDatabase, QGridLayout)
-from PyQt4.QtCore import (Qt, SIGNAL, SLOT, QSize, QString,
+from PyQt4.QtCore import (Qt, SIGNAL, SLOT, QObject, QSize,
                           pyqtSignature, pyqtProperty)
import datetime


 class ColorButton(QPushButton):
@@ -102,7 +102,8 @@ def text_to_qcolor(text):
     Avoid warning from Qt when an invalid QColor is instantiated
     """
     color = QColor()
-    if isinstance(text, QString):
+    if isinstance(text, QObject):
+        # actually a QString, which is not provided by the new PyQt4 API:
         text = str(text)
     if not isinstance(text, (unicode, str)):
         return color

Hi Pierre,

Are you still maintaining the qt4 plot editor dialog? It doesn't
appear to be working properly: setting the marker and linestyle
options does not effect the plot (tested on Ubuntu Natty alpha, with
the v1.0.x branch on python-2.7 and PyQt4-4.8.3). I have a really hard
time following the code. Also, the dialog makes the qt4 backend
unusable with PyQt4's API v2, which does not provide a QString object.

Darren

On Sun, Feb 27, 2011 at 1:21 PM, John Hunter <jd...@gm...> wrote:

> On Sun, Feb 27, 2011 at 1:13 PM, Benjamin Root <ben...@ou...> wrote:
> > I was just looking through some code and I realized that if we are now
> > willing (able?) to drop support for 2.4-2.5, then maybe we could benefit
> > from some updates to our coding practices?  For example, I would
> personally
> > love to see more use of conditional expressions (new in 2.5).
>
> We are only talking about the python 3 branch here.  The master branch
> should remain 2.4 compliant until we merge the 3.x into master.
> Before we do that, we'll probably want to do a 1.1 or 1.2 or
> 1.whatever release and maintenance branch so we have a python 2.4
> which is as current as possible.
>
> JDH
>


Ah, that wasn't entirely clear.  Good to know before I started messing
things up.

Ben Root

On Sun, Feb 27, 2011 at 1:13 PM, Benjamin Root <ben...@ou...> wrote:
> I was just looking through some code and I realized that if we are now
> willing (able?) to drop support for 2.4-2.5, then maybe we could benefit
> from some updates to our coding practices?  For example, I would personally
> love to see more use of conditional expressions (new in 2.5).

We are only talking about the python 3 branch here.  The master branch
should remain 2.4 compliant until we merge the 3.x into master.
Before we do that, we'll probably want to do a 1.1 or 1.2 or
1.whatever release and maintenance branch so we have a python 2.4
which is as current as possible.

JDH

On Sat, Feb 26, 2011 at 12:22 PM, Eric Firing <ef...@ha...> wrote:

> On 02/26/2011 04:51 AM, Darren Dale wrote:
> > On Sat, Feb 26, 2011 at 9:23 AM, Pauli Virtanen<pa...@ik...>  wrote:
> >> On Sat, 26 Feb 2011 07:29:55 -0500, Michael Droettboom wrote:
> >> [clip]
> >>> Yes.  The minimum version for this Python 3.x compatibility work is
> >>> Python 2.6.  Anything earlier is just insane ;)
> >>
> >> Out of curiosity: did you consider using a single source tree for Python
> >> 2.x and 3.x, rather than a separate branch; providing Python 3 support
> by
> >> running 2to3 on build stage and #ifdef's + compatibility headers in C
> >> code?
> >>
> >> This approach allowed Numpy to support Pythons down to 2.4 with little
> >> extra work, and requires manual Python 3 specific fixes only when
> >> something breaks (which does not seem to occur often in practice).
> >
> > At some point, it will make sense to discontinue support for
> > <=python-2.5 (maybe even 2.6). I have used numpy's 2to3 for my
> > quantities project (admittedly a *much* smaller project with *much*
> > smaller exposure), but recently dropped backwards compatibility and
> > now 2.6-3.2 are supported in a single branch without use of 2to3. I
> > prefer this approach, it seems to be working out without too much
> > trouble so far.
> >
> > Darren
> >
>
> Supporting earlier versions is nice--I work with many machines running
> 2.5, and keep mpl up to date on several of them, but thankfully I have
> nothing still stuck on 2.4--but for mpl, now that we have a pretty good
> 1.x version, I don't think it would be too hard on users if we made a
> last release supporting earlier pythons and then dropped support for
> them in subsequent releases.  It would not mean people with earlier
> pythons couldn't run mpl, it would just mean they would get no new
> improvements, and no new bug fixes unless someone stepped forward to
> maintain the old branch.
>
> Dropping 2.6 any time soon would be too drastic for my liking, though.
> It would require that any development work done on recent ubuntu
> systems, for example, would require first installing a non-default
> version of python.  So, I hope the py3k work can result in a 2.6-and-up
> codebase--is that the present goal?  Those of us developing on 2.6 will
> need to learn exactly how to avoid breaking 3.1 compatibility.
>
> Eric
>
>
I was just looking through some code and I realized that if we are now
willing (able?) to drop support for 2.4-2.5, then maybe we could benefit
from some updates to our coding practices?  For example, I would personally
love to see more use of conditional expressions (new in 2.5).

In addition, I wonder if we could possibly consider updating our policy
regarding function parameter handling?  In particular, I am referring to
this section of our coding guide:

In some cases, you may want to consume some keys in the local function, and
> let others pass through. You can pop the ones to be used locally and pass
> on the rest. For example, in plot()<http://matplotlib.github.com/api/axes_api.html#matplotlib.axes.Axes.plot>,
> scalex and scaley are local arguments and the rest are passed on as
> Line2D()<http://matplotlib.github.com/api/artist_api.html#matplotlib.lines.Line2D>keyword arguments:
>
> # in axes.py
> def plot(self, *args, **kwargs):
>
>     scalex = kwargs.pop('scalex', True)
>
>     scaley = kwargs.pop('scaley', True)
>
>     if not self._hold: self.cla()
>
>     lines = []
>     for line in self._get_lines(*args, **kwargs):
>
>         self.add_line(line)
>         lines.append(line)
>
> Note: there is a use case when kwargs are meant to be used locally in the
> function (not passed on), but you still need the **kwargs idiom. That is
> when you want to use *args to allow variable numbers of non-keyword args.
> In this case, python will not allow you to use named keyword args after the
> *args usage, so you will be forced to use **kwargs. An example is
> matplotlib.contour.ContourLabeler.clabel():
>
# in contour.py
def clabel(self, *args, **kwargs):
fontsize = kwargs.get('fontsize', None)
inline = kwargs.get('inline', 1)
self.fmt = kwargs.get('fmt', '%1.3f')
colors = kwargs.get('colors', None)
if len(args) == 0:
levels = self.levels
indices = range(len(self.levels))
elif len(args) == 1:
...etc...

I know that this restriction is no longer the case in later versions of
python, but I can't seem to find out which version this restriction was
changed.

Are there other practices that we can now allow?

Ben Root

On Sun, Feb 27, 2011 at 8:32 AM, Darren Dale <dsd...@gm...> wrote:
> If we are not convinced that github issues provides
> everything we need, I think we should provide feedback to the github
> devs and stick with sourceforge for the time being.

Having said that, depending on how the github devs respond, we might
want to give lighthouse (lighthouseapp.com) a look. It claims to
integrate with github, supports attachments, integrates with email,
would support separate trackers for the various matplotlib repos, and
it is apparently free for open-source projects:
http://matplotlib.lighthouseapp.com/projects/70830-matplotlib/overview
.

If you are interested in playing around with lighthouse and want
elevated privileges, send me (off list) the email address you used to
sign up at lighthouse. If it looks promising, we could see how well it
integrates with github.

On Sun, Feb 27, 2011 at 8:32 AM, Darren Dale <dsd...@gm...> wrote:
> If we are not convinced that github issues provides
> everything we need, I think we should provide feedback to the github
> devs and stick with sourceforge for the time being.

Here is a copy of a message I just sent to su...@gi.... If you
have other specific concerns, please let me know, and I will pass them
along if I hear back from someone at github.:

Hello,

Thank you for all your great work on github.

I am one of the developers of the matplotlib project
(matplotlib.github.com). We recently converted our svn repositories to
git, and started hosting them at github. This weekend I worked on
testing migrating the issues from the sourceforge tracker (see
https://github.com/darrendale/mpl-issues), but we have some concerns
about the usability of the github issue tracker:

* Our project produces graphical output, so the ability to attach
files (like images and test scripts) to an issue is of critical
importance to our project.
* We would miss the ability to file tickets through the browser
without signing in to github.
* Having to repeatedly request "more" to see all the tickets is rather painful
* We would miss the ability to assign a ticket to a developer.
Creating a label for a developer is not seen to be enough. It would be
nice if we could actually assign a developer to an issue, and from
then on only the developer would receive emails concerning activity on
the issue, unless others requested notifications.
* It would be nice if people could register/unregister to receive
notifications when there is activity on a specific issue that affects
them.
* It would be nice to be able to mark issues as pending after they are
committed, and mark them as closed when publicly released, along with
the release version(s) which addressed the problem (this latter
feature would be brilliant if github had project management features)
* It would be nice to mark an issue as a duplicate, automatically
linking to the appropriate issue and registering the reporter for
updates on the open issue

I have made the case to the other devs that the benefits of github
issues integration with the rest of the site is compelling, but at the
end of the day, some of these features are too important to us to
migrate to github issues at this time.

Concerning the websites, in general I like the gh-pages and
myproject.github.com solutions. However, the matplotlib documentation
is generated from RestructuredText using Sphinx. The resulting html is
about 80 MB, and has a lot of graphics and examples. We would rather
not track changes to this generated content, since we already track
changes to the (much smaller) source: it takes up additional space and
takes a long time to upload to the server.

Finally, I was hoping that you might consider adding some project
management features to github. About a year ago, I migrated a project
(github.com/python-quantities) from Launchpad. I like github much
better, but miss some of Launchpad's project management features. For
instance, it would be nice if we could specify and schedule an
upcoming release at github (which could be used to integrate with
pending issue closures), and then once we create the corresponding tag
in git, github creates a new directory in an official releases
downloads area (perhaps along with .zip and .tgz files). Also, the
release graph at a projects main page at Launchpad was nice.

I hope this doesn't seem too critical, I just wanted to give some
constructive feedback. Thank you again for all you've done!

Best regards,
Darren Dale

On Sun, Feb 27, 2011 at 1:06 AM, Eric Firing <ef...@ha...> wrote:

> That's a good point.  Until fairly recently, interactive behavior worked
> across backends only via ipython magic, so I think the non-interactive
> default had a solid historical rationale.  Now, however, we could
> probably make interactive mode the startup default for interactive
> backends without causing any problems.  I agree that this would be more
> intuitive and more familiar to people coming from matlab.

Probably right -- this was a design decision made early on when I did
not see a good way around the problem that the idle drawing across
backends now solves.  There will probably be some unintended
consequences of changing the default, but as long as we document it
prominently and provide a way for people to change the behavior to the
old wan in their rc, it is probably a good idea to make this change.

On Sun, Feb 27, 2011 at 7:46 AM, Jouni K. Seppänen <jk...@ik...> wrote:
> Darren Dale <dsd...@gm...> writes:
>
>> On Sat, Feb 26, 2011 at 5:58 PM, Eric Firing <ef...@ha...> wrote:
>>> On 02/26/2011 10:54 AM, Darren Dale wrote:
>>>
>>> The submitter info is lost?
>>> And when it was originally submitted?
>>
>> No, I can improve it so this information is included.
>
> That's clearly in the xml file, except that I don't know if we can map
> sourceforge userids to email addresses - that sounds like something that
> spammers would want to do.

I was thinking to just use the SourceForge IDs.

> One thing that I think is missing in the xml file are the attachment
> contents. There are filenames and some kind of ids that presumably can
> be used to get the files via the sf bug pages, but this information only
> occurs in the artifact_history subsection. To get the correct files
> you'll have to first parse this to figure out that file 396374 was added
> but then deleted and then file 396688 was added

That's a good idea. But given the limitations of attaching files to
issues at github, I thought it would be better to instead provide
enough context in the github issue (SourceForge messages and history)
so that if such files are needed, they could be retrieved from
SourceForge.

My thinking on issue tracking is similar to Fernando's. Github issues
integration with some of the other features of the site is really
nice, and makes the issue tracker much more a part of the development
process than was the case at sourceforge. But its a different
paradigm: patches are submitted as pull requests rather than
attachments in the issue tracker.

Here is another big change difference: tickets can be created at
sourceforge without a sourceforge account (hence the spam). At github,
you have to have an account to file a ticket.

>> I agree that the github interface is not great. The github devs seem
>> to know that everybody complains about it.
>>
>> There are some good things about it though. Labels, the ability to
>> link between an issue and the commits that resolve it, the ability for
>> people to provide feedback on what issues are important to them.
>
> Does anyone have experience with other trackers? bugs.python.org seems
> to be using Roundup - any experiences with that?

I have not worked with Roundup. I have a little experience with Trac
(meh), and with Launchpad (good integration with project management
features, which are lacking at github.) What I was thinking to achieve
by testing migration of the issues to github was not simply to get
away from sourceforge, but to benefit from the integration of
services. If we are not convinced that github issues provides
everything we need, I think we should provide feedback to the github
devs and stick with sourceforge for the time being.

Darren

Darren Dale <dsd...@gm...> writes:

> On Sat, Feb 26, 2011 at 5:58 PM, Eric Firing <ef...@ha...> wrote:
>> On 02/26/2011 10:54 AM, Darren Dale wrote:
>>
>> The submitter info is lost?
>> And when it was originally submitted?
>
> No, I can improve it so this information is included.

That's clearly in the xml file, except that I don't know if we can map
sourceforge userids to email addresses - that sounds like something that
spammers would want to do.

One thing that I think is missing in the xml file are the attachment
contents. There are filenames and some kind of ids that presumably can
be used to get the files via the sf bug pages, but this information only
occurs in the artifact_history subsection. To get the correct files
you'll have to first parse this to figure out that file 396374 was added
but then deleted and then file 396688 was added:

	<field name="artifact_history">
<history>
		<field name="field_name">File Added</field>
		<field name="old_value">396688: set_verts_cleanup_2.patch</field>
		<field name="entrydate">1293000689</field>
		<field name="mod_by">notmuchtotell</field>
</history>

<history>
		<field name="field_name">File Deleted</field>
		<field name="old_value">396374: </field>
		<field name="entrydate">1293000467</field>
		<field name="mod_by">notmuchtotell</field>
</history>

<history>
		<field name="field_name">File Added</field>
		<field name="old_value">396374: set_verts_cleanup.patch</field>
		<field name="entrydate">1292605835</field>
		<field name="mod_by">notmuchtotell</field>
</history>


> I agree that the github interface is not great. The github devs seem
> to know that everybody complains about it.
>
> There are some good things about it though. Labels, the ability to
> link between an issue and the commits that resolve it, the ability for
> people to provide feedback on what issues are important to them.

Does anyone have experience with other trackers? bugs.python.org seems
to be using Roundup - any experiences with that?

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On 02/26/2011 04:25 PM, Michiel de Hoon wrote:
> --- On Sat, 2/26/11, Eric Firing<ef...@ha...>  wrote:
>> What about the non-interactive mode behavior--is it hard to
>> make the  MaxOSX backend behave like the others in that
>> respect?
> I agree that this should be done, but I just haven't found the time to look at it (recently I have been looking at getting animations to work with the MacOSX backend). Probably it is not all that hard, and I would welcome contributions from other developers who use the MacOSX backend to get the non-interactive mode behavior consistent with the other backends.
>
> On a related note, something I found confusing for new matplotlib users is that after first installing it, matplotlib is non-interactive by default. After installing matplotlib, I think users should be able to try it out and make some simple plots that appear on the screen without having to find out about interactive behavior and edit matplotlibrc. Especially people that are new to programming or to Python may be disappointed if their first plotting attempts don't seem to produce a figure.

That's a good point.  Until fairly recently, interactive behavior worked 
across backends only via ipython magic, so I think the non-interactive 
default had a solid historical rationale.  Now, however, we could 
probably make interactive mode the startup default for interactive 
backends without causing any problems.  I agree that this would be more 
intuitive and more familiar to people coming from matlab.

Eric

>
> --Michiel.

On Sat, Feb 26, 2011 at 6:14 PM, Eric Firing <ef...@ha...> wrote:
> It is impressive, and improves some aspects, but I don't see that it
> makes the github tracker usable for new tickets.  I don't see any
> facility for attaching a file--is this correct?  We really want users
> with problems and suggestions to attach minimal example files, patches,
> whatever--as downloadable files, not pasted into the comment box.

No, that's a current limitation of the github tracker.  As a poor
man's attachment system, github does have the gist system:

https://gist.github.com/

that makes it easy to drop any file (small or large) and have it
permanently stored on GH with a stable url.

But I agree that the tracker should have proper file attachments
built-in, using gist is just a workaround, and one most people won't
necessarily know about gist or think of it as a way to attach files to
the tracker.

> My inclination would be to keep using the SF tracker exclusively until
> the github tracker improves substantially, and then switch.

Since we did switch for ipython, here's me keeping my fingers
painfully crossed for that day to come earlier rather than later...

Cheers,

f

--- On Sat, 2/26/11, Eric Firing <ef...@ha...> wrote:
> What about the non-interactive mode behavior--is it hard to
> make the  MaxOSX backend behave like the others in that
> respect?
I agree that this should be done, but I just haven't found the time to look at it (recently I have been looking at getting animations to work with the MacOSX backend). Probably it is not all that hard, and I would welcome contributions from other developers who use the MacOSX backend to get the non-interactive mode behavior consistent with the other backends.

On a related note, something I found confusing for new matplotlib users is that after first installing it, matplotlib is non-interactive by default. After installing matplotlib, I think users should be able to try it out and make some simple plots that appear on the screen without having to find out about interactive behavior and edit matplotlibrc. Especially people that are new to programming or to Python may be disappointed if their first plotting attempts don't seem to produce a figure.

--Michiel.


      

On 02/26/2011 01:44 PM, Fernando Perez wrote:
> On Sat, Feb 26, 2011 at 3:24 PM, Darren Dale<dsd...@gm...>  wrote:
>>
>> I agree that the github interface is not great. The github devs seem
>> to know that everybody complains about it.
>
> Yup.  I hold on to the hope that, because it's so egregiously,
> painfully broken and braindead and it stands out so badly in
> comparison to the rest of github (which is brilliant), that it won't
> be too long before this improves. Granted, we can't know what's on
> their internal todo list, but those guys are obviously good and listen
> to feedback (from what I've seen elsewhere on the site), and their bug
> tracker has become something of a laughing stock, so I can only
> imagine that they're actually working on it.
>
> In the meantime, Min recently pointed out this interesting alternative:
>
> http://githubissues.heroku.com/#darrendale/mpl-issues

It is impressive, and improves some aspects, but I don't see that it 
makes the github tracker usable for new tickets.  I don't see any 
facility for attaching a file--is this correct?  We really want users 
with problems and suggestions to attach minimal example files, patches, 
whatever--as downloadable files, not pasted into the comment box.

My inclination would be to keep using the SF tracker exclusively until 
the github tracker improves substantially, and then switch.

Eric

>
> You can point it to any repository you want, and it makes interacting
> with the issue list far, far saner than via github itself.
>
> We're using now that interface ourselves for IPython:
>
> http://githubissues.heroku.com/#ipython/ipython
>
> and I have to say that I like it quite a bit.  For those on OSX, this
> can even be installed to run locally, with the feel of a native app
> (it's still a webkit app, but it launches like a local app).
>
> Something to keep in mind as you make the decision...
>
> In the end, in IPython we decided to move to github in order to
> benefit from the close integration between pull requests, bugs and
> commits.  Pull requests automatically create an issue, one can close
> bugs automatically from the commit message, etc.  I figured these
> things would be nice to have for an everyday workflow, and that
> eventually github itself would improve its native bug system.
>
> Cheers,
>
> f
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search&  Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Sat, Feb 26, 2011 at 3:24 PM, Darren Dale <dsd...@gm...> wrote:
>
> I agree that the github interface is not great. The github devs seem
> to know that everybody complains about it.

Yup.  I hold on to the hope that, because it's so egregiously,
painfully broken and braindead and it stands out so badly in
comparison to the rest of github (which is brilliant), that it won't
be too long before this improves. Granted, we can't know what's on
their internal todo list, but those guys are obviously good and listen
to feedback (from what I've seen elsewhere on the site), and their bug
tracker has become something of a laughing stock, so I can only
imagine that they're actually working on it.

In the meantime, Min recently pointed out this interesting alternative:

http://githubissues.heroku.com/#darrendale/mpl-issues

You can point it to any repository you want, and it makes interacting
with the issue list far, far saner than via github itself.

We're using now that interface ourselves for IPython:

http://githubissues.heroku.com/#ipython/ipython

and I have to say that I like it quite a bit.  For those on OSX, this
can even be installed to run locally, with the feel of a native app
(it's still a webkit app, but it launches like a local app).

Something to keep in mind as you make the decision...

In the end, in IPython we decided to move to github in order to
benefit from the close integration between pull requests, bugs and
commits.  Pull requests automatically create an issue, one can close
bugs automatically from the commit message, etc.  I figured these
things would be nice to have for an everyday workflow, and that
eventually github itself would improve its native bug system.

Cheers,

f

On Sat, Feb 26, 2011 at 6:15 PM, Benjamin Root <ben...@ou...> wrote:
> Github has been a wonderful tool for *developers*, but for
> users of projects, I haven't seen the amount of sophistication and polish
> that sourceforge has.
>
> I am personally fine with continuing to use sourceforge for the tracker (I
> know I need to catch up on bugs there...).  My main concern, though, is
> having two active issue trackers -- one on sourceforge and one on github.

The one at github can be easily disabled.

On Sat, Feb 26, 2011 at 5:58 PM, Eric Firing <ef...@ha...> wrote:
> On 02/26/2011 10:54 AM, Darren Dale wrote:
>> On Sat, Feb 26, 2011 at 3:52 PM, Darren Dale<dsd...@gm...>  wrote:
>>> On Sat, Feb 26, 2011 at 2:52 PM, Eric Firing<ef...@ha...>  wrote:
>>>> On 02/26/2011 09:26 AM, Darren Dale wrote:
>>>>> On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing<ef...@ha...>    wrote:
>>>>>> On 02/16/2011 08:38 AM, Darren Dale wrote:
>>>>>>> On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez<fpe...@gm...>      wrote:
>>>>>>>> are you guys planning on transfering the old bugs to github?
>>>>>>>
>>>>>>> Probably at some point.
>>>>>>>
>>>>>>>> As I
>>>>>>>> mentioned, I have code lying around for the upload (and to download
>>>>>>>> from launchpad, but that's irrelevant here).  I'm going to be mosly
>>>>>>>> offline til Monday (conference trip), but if someone pings me on my
>>>>>>>> Berkeley email address, which I monitor even while traveling, I'll be
>>>>>>>> happy to help out.
>>>>>>>
>>>>>>> Thanks, that would be very helpful. I'll follow up once I figure out
>>>>>>> how to extract the information from sourceforge.
>>>>>>
>>>>>> Darren,
>>>>>>
>>>>>> Just a heads-up on that: In November the tracker was heavily spammed.
>>>>>> Recently I marked a few hundred items with the "delete" disposition, but
>>>>>> I don't think that actually gets rid of them.  If it doesn't, then maybe
>>>>>> they can be filtered out during the transfer.
>>>>>
>>>>> We have some additional spam that needs to be deleted. How did you do
>>>>> it? When I try to delete several at once (mass change), I get an error
>>>>> message: "XSRF Attempt Detected!"
>>>>>
>>>>
>>>> I made the tracker display the maximum number of entries per page, then
>>>> clicked "check all", then "mass update" with "delete", and it marked
>>>> them as "deleted"--but they never get deleted.  They are still there,
>>>> but marked "deleted". It sounds like that is the same as what you tried,
>>>> so I don't know why you are getting that error message.
>>>>
>>>> Which tracker category is showing the new spam?
>>>
>>> The Feature Requests. I was not able to mark the spam as deleted, but
>>> I filtered it out in the conversion.
>>
>> Let me try again:
>>
>> The tracker export xml file and conversion script are up at
>> https://github.com/darrendale/mpl-issues , and the issues can be
>> previewed at https://github.com/darrendale/mpl-issues/issues . Devs,
>> please have a
>> look. I only imported the open issues, including bugs, patches,
>> feature requests and support requests. If we decide to use the github
>> tracker, we can tell sourceforge we have relocated the project, and
>> the project will remain intact and archived. I don't know if that
>> would mean that we can no longer host the homepage at sourceforge.
>
> The submitter info is lost?
> And when it was originally submitted?

No, I can improve it so this information is included.

> If yes to either, then I think that we should not transfer these from
> sourceforge, but deal with them there.

Each issue has a hyperlink to the report at sourceforge.

> Overall, the tracking interface on github looks so bad that I can't see
> why we would want to move.  Sourceforge is slow, but at least the
> tracker has the right sort of functionality: the ability to scan a lot
> of info on one screen, the ability to categorize, attach files, assign,
> etc.  Maybe some of this is available but not evident in the github
> tracker, but what I see is not encouraging.

I agree that the github interface is not great. The github devs seem
to know that everybody complains about it.

There are some good things about it though. Labels, the ability to
link between an issue and the commits that resolve it, the ability for
people to provide feedback on what issues are important to them.

> Mpl historically has not done well in using the tracker.  I hope that
> eventually we can transition to a tool that will help us do better, not
> worse.

I disagree that we would do worse with the github tracker.

On Sat, Feb 26, 2011 at 4:58 PM, Eric Firing <ef...@ha...> wrote:

> On 02/26/2011 10:54 AM, Darren Dale wrote:
> > On Sat, Feb 26, 2011 at 3:52 PM, Darren Dale<dsd...@gm...>  wrote:
> >> On Sat, Feb 26, 2011 at 2:52 PM, Eric Firing<ef...@ha...>
>  wrote:
> >>> On 02/26/2011 09:26 AM, Darren Dale wrote:
> >>>> On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing<ef...@ha...>
>  wrote:
> >>>>> On 02/16/2011 08:38 AM, Darren Dale wrote:
> >>>>>> On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez<fperez.net@
> gmail.com>      wrote:
> >>>>>>> are you guys planning on transfering the old bugs to github?
> >>>>>>
> >>>>>> Probably at some point.
> >>>>>>
> >>>>>>> As I
> >>>>>>> mentioned, I have code lying around for the upload (and to download
> >>>>>>> from launchpad, but that's irrelevant here).  I'm going to be mosly
> >>>>>>> offline til Monday (conference trip), but if someone pings me on my
> >>>>>>> Berkeley email address, which I monitor even while traveling, I'll
> be
> >>>>>>> happy to help out.
> >>>>>>
> >>>>>> Thanks, that would be very helpful. I'll follow up once I figure out
> >>>>>> how to extract the information from sourceforge.
> >>>>>
> >>>>> Darren,
> >>>>>
> >>>>> Just a heads-up on that: In November the tracker was heavily spammed.
> >>>>> Recently I marked a few hundred items with the "delete" disposition,
> but
> >>>>> I don't think that actually gets rid of them.  If it doesn't, then
> maybe
> >>>>> they can be filtered out during the transfer.
> >>>>
> >>>> We have some additional spam that needs to be deleted. How did you do
> >>>> it? When I try to delete several at once (mass change), I get an error
> >>>> message: "XSRF Attempt Detected!"
> >>>>
> >>>
> >>> I made the tracker display the maximum number of entries per page, then
> >>> clicked "check all", then "mass update" with "delete", and it marked
> >>> them as "deleted"--but they never get deleted.  They are still there,
> >>> but marked "deleted". It sounds like that is the same as what you
> tried,
> >>> so I don't know why you are getting that error message.
> >>>
> >>> Which tracker category is showing the new spam?
> >>
> >> The Feature Requests. I was not able to mark the spam as deleted, but
> >> I filtered it out in the conversion.
> >
> > Let me try again:
> >
> > The tracker export xml file and conversion script are up at
> > https://github.com/darrendale/mpl-issues , and the issues can be
> > previewed at https://github.com/darrendale/mpl-issues/issues . Devs,
> > please have a
> > look. I only imported the open issues, including bugs, patches,
> > feature requests and support requests. If we decide to use the github
> > tracker, we can tell sourceforge we have relocated the project, and
> > the project will remain intact and archived. I don't know if that
> > would mean that we can no longer host the homepage at sourceforge.
>
> The submitter info is lost?
> And when it was originally submitted?
> If yes to either, then I think that we should not transfer these from
> sourceforge, but deal with them there.
> Overall, the tracking interface on github looks so bad that I can't see
> why we would want to move.  Sourceforge is slow, but at least the
> tracker has the right sort of functionality: the ability to scan a lot
> of info on one screen, the ability to categorize, attach files, assign,
> etc.  Maybe some of this is available but not evident in the github
> tracker, but what I see is not encouraging.
>
> Mpl historically has not done well in using the tracker.  I hope that
> eventually we can transition to a tool that will help us do better, not
> worse.
>
> Eric
>
>
Ditto on this.  Github has been a wonderful tool for *developers*, but for
users of projects, I haven't seen the amount of sophistication and polish
that sourceforge has.

I am personally fine with continuing to use sourceforge for the tracker (I
know I need to catch up on bugs there...).  My main concern, though, is
having two active issue trackers -- one on sourceforge and one on github.

Ben Root

On 02/26/2011 10:54 AM, Darren Dale wrote:
> On Sat, Feb 26, 2011 at 3:52 PM, Darren Dale<dsd...@gm...>  wrote:
>> On Sat, Feb 26, 2011 at 2:52 PM, Eric Firing<ef...@ha...>  wrote:
>>> On 02/26/2011 09:26 AM, Darren Dale wrote:
>>>> On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing<ef...@ha...>    wrote:
>>>>> On 02/16/2011 08:38 AM, Darren Dale wrote:
>>>>>> On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez<fpe...@gm...>      wrote:
>>>>>>> are you guys planning on transfering the old bugs to github?
>>>>>>
>>>>>> Probably at some point.
>>>>>>
>>>>>>> As I
>>>>>>> mentioned, I have code lying around for the upload (and to download
>>>>>>> from launchpad, but that's irrelevant here).  I'm going to be mosly
>>>>>>> offline til Monday (conference trip), but if someone pings me on my
>>>>>>> Berkeley email address, which I monitor even while traveling, I'll be
>>>>>>> happy to help out.
>>>>>>
>>>>>> Thanks, that would be very helpful. I'll follow up once I figure out
>>>>>> how to extract the information from sourceforge.
>>>>>
>>>>> Darren,
>>>>>
>>>>> Just a heads-up on that: In November the tracker was heavily spammed.
>>>>> Recently I marked a few hundred items with the "delete" disposition, but
>>>>> I don't think that actually gets rid of them.  If it doesn't, then maybe
>>>>> they can be filtered out during the transfer.
>>>>
>>>> We have some additional spam that needs to be deleted. How did you do
>>>> it? When I try to delete several at once (mass change), I get an error
>>>> message: "XSRF Attempt Detected!"
>>>>
>>>
>>> I made the tracker display the maximum number of entries per page, then
>>> clicked "check all", then "mass update" with "delete", and it marked
>>> them as "deleted"--but they never get deleted.  They are still there,
>>> but marked "deleted". It sounds like that is the same as what you tried,
>>> so I don't know why you are getting that error message.
>>>
>>> Which tracker category is showing the new spam?
>>
>> The Feature Requests. I was not able to mark the spam as deleted, but
>> I filtered it out in the conversion.
>
> Let me try again:
>
> The tracker export xml file and conversion script are up at
> https://github.com/darrendale/mpl-issues , and the issues can be
> previewed at https://github.com/darrendale/mpl-issues/issues . Devs,
> please have a
> look. I only imported the open issues, including bugs, patches,
> feature requests and support requests. If we decide to use the github
> tracker, we can tell sourceforge we have relocated the project, and
> the project will remain intact and archived. I don't know if that
> would mean that we can no longer host the homepage at sourceforge.

The submitter info is lost?
And when it was originally submitted?
If yes to either, then I think that we should not transfer these from 
sourceforge, but deal with them there.
Overall, the tracking interface on github looks so bad that I can't see 
why we would want to move.  Sourceforge is slow, but at least the 
tracker has the right sort of functionality: the ability to scan a lot 
of info on one screen, the ability to categorize, attach files, assign, 
etc.  Maybe some of this is available but not evident in the github 
tracker, but what I see is not encouraging.

Mpl historically has not done well in using the tracker.  I hope that 
eventually we can transition to a tool that will help us do better, not 
worse.

Eric

On Sat, Feb 26, 2011 at 1:22 PM, Eric Firing <ef...@ha...> wrote:
> Dropping 2.6 any time soon would be too drastic for my liking, though.
> It would require that any development work done on recent ubuntu
> systems, for example, would require first installing a non-default
> version of python.  So, I hope the py3k work can result in a 2.6-and-up
> codebase--is that the present goal?

Yes, it is.

On Sat, Feb 26, 2011 at 3:52 PM, Darren Dale <dsd...@gm...> wrote:
> On Sat, Feb 26, 2011 at 2:52 PM, Eric Firing <ef...@ha...> wrote:
>> On 02/26/2011 09:26 AM, Darren Dale wrote:
>>> On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing<ef...@ha...>  wrote:
>>>> On 02/16/2011 08:38 AM, Darren Dale wrote:
>>>>> On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez<fpe...@gm...>    wrote:
>>>>>> are you guys planning on transfering the old bugs to github?
>>>>>
>>>>> Probably at some point.
>>>>>
>>>>>> As I
>>>>>> mentioned, I have code lying around for the upload (and to download
>>>>>> from launchpad, but that's irrelevant here).  I'm going to be mosly
>>>>>> offline til Monday (conference trip), but if someone pings me on my
>>>>>> Berkeley email address, which I monitor even while traveling, I'll be
>>>>>> happy to help out.
>>>>>
>>>>> Thanks, that would be very helpful. I'll follow up once I figure out
>>>>> how to extract the information from sourceforge.
>>>>
>>>> Darren,
>>>>
>>>> Just a heads-up on that: In November the tracker was heavily spammed.
>>>> Recently I marked a few hundred items with the "delete" disposition, but
>>>> I don't think that actually gets rid of them.  If it doesn't, then maybe
>>>> they can be filtered out during the transfer.
>>>
>>> We have some additional spam that needs to be deleted. How did you do
>>> it? When I try to delete several at once (mass change), I get an error
>>> message: "XSRF Attempt Detected!"
>>>
>>
>> I made the tracker display the maximum number of entries per page, then
>> clicked "check all", then "mass update" with "delete", and it marked
>> them as "deleted"--but they never get deleted.  They are still there,
>> but marked "deleted". It sounds like that is the same as what you tried,
>> so I don't know why you are getting that error message.
>>
>> Which tracker category is showing the new spam?
>
> The Feature Requests. I was not able to mark the spam as deleted, but
> I filtered it out in the conversion.

Let me try again:

The tracker export xml file and conversion script are up at
https://github.com/darrendale/mpl-issues , and the issues can be
previewed at https://github.com/darrendale/mpl-issues/issues . Devs,
please have a
look. I only imported the open issues, including bugs, patches,
feature requests and support requests. If we decide to use the github
tracker, we can tell sourceforge we have relocated the project, and
the project will remain intact and archived. I don't know if that
would mean that we can no longer host the homepage at sourceforge.

On Sat, Feb 26, 2011 at 2:52 PM, Eric Firing <ef...@ha...> wrote:
> On 02/26/2011 09:26 AM, Darren Dale wrote:
>> On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing<ef...@ha...>  wrote:
>>> On 02/16/2011 08:38 AM, Darren Dale wrote:
>>>> On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez<fpe...@gm...>    wrote:
>>>>> are you guys planning on transfering the old bugs to github?
>>>>
>>>> Probably at some point.
>>>>
>>>>> As I
>>>>> mentioned, I have code lying around for the upload (and to download
>>>>> from launchpad, but that's irrelevant here).  I'm going to be mosly
>>>>> offline til Monday (conference trip), but if someone pings me on my
>>>>> Berkeley email address, which I monitor even while traveling, I'll be
>>>>> happy to help out.
>>>>
>>>> Thanks, that would be very helpful. I'll follow up once I figure out
>>>> how to extract the information from sourceforge.
>>>
>>> Darren,
>>>
>>> Just a heads-up on that: In November the tracker was heavily spammed.
>>> Recently I marked a few hundred items with the "delete" disposition, but
>>> I don't think that actually gets rid of them.  If it doesn't, then maybe
>>> they can be filtered out during the transfer.
>>
>> We have some additional spam that needs to be deleted. How did you do
>> it? When I try to delete several at once (mass change), I get an error
>> message: "XSRF Attempt Detected!"
>>
>
> I made the tracker display the maximum number of entries per page, then
> clicked "check all", then "mass update" with "delete", and it marked
> them as "deleted"--but they never get deleted.  They are still there,
> but marked "deleted". It sounds like that is the same as what you tried,
> so I don't know why you are getting that error message.
>
> Which tracker category is showing the new spam?

The Feature Requests. I was not able to mark the spam as deleted, but
I filtered it out in the conversion.

The tracker export xml file and conversion script are up at
https://github.com/darrendale/mpl-issues , and the issues can be
previewedeThe tracker export xml file and conversion script are up at
https://github.com/darrendale/mpl-issues/issues at The tracker export
xml file and conversion script are up at
https://github.com/darrendale/mpl-issues/issues . Devs, please have a
look. I only imported the open issues, including bugs, patches,
feature requests and support requests. If we decide to use the github
tracker, we can tell sourceforge we have relocated the project, and
the project will remain intact and archived. I don't know if that
would mean that we can no longer host the homepage at sourceforge.

On 02/26/2011 09:26 AM, Darren Dale wrote:
> On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing<ef...@ha...>  wrote:
>> On 02/16/2011 08:38 AM, Darren Dale wrote:
>>> On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez<fpe...@gm...>    wrote:
>>>> are you guys planning on transfering the old bugs to github?
>>>
>>> Probably at some point.
>>>
>>>> As I
>>>> mentioned, I have code lying around for the upload (and to download
>>>> from launchpad, but that's irrelevant here).  I'm going to be mosly
>>>> offline til Monday (conference trip), but if someone pings me on my
>>>> Berkeley email address, which I monitor even while traveling, I'll be
>>>> happy to help out.
>>>
>>> Thanks, that would be very helpful. I'll follow up once I figure out
>>> how to extract the information from sourceforge.
>>
>> Darren,
>>
>> Just a heads-up on that: In November the tracker was heavily spammed.
>> Recently I marked a few hundred items with the "delete" disposition, but
>> I don't think that actually gets rid of them.  If it doesn't, then maybe
>> they can be filtered out during the transfer.
>
> We have some additional spam that needs to be deleted. How did you do
> it? When I try to delete several at once (mass change), I get an error
> message: "XSRF Attempt Detected!"
>

I made the tracker display the maximum number of entries per page, then 
clicked "check all", then "mass update" with "delete", and it marked 
them as "deleted"--but they never get deleted.  They are still there, 
but marked "deleted". It sounds like that is the same as what you tried, 
so I don't know why you are getting that error message.

Which tracker category is showing the new spam?

Eric