[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-cpp-sig
Subject:    Re: [C++-sig] Off-topic: Personal bug tracking
From:       "Niall Douglas" <s_sourceforge () nedprod ! com>
Date:       2011-10-04 15:59:11
Message-ID: 4E8B2D4F.28025.2A18442E () s_sourceforge ! nedprod ! com
[Download RAW message or body]

On 3 Oct 2011 at 11:13, Dave Abrahams wrote:

> > I'd also say personal bug trackers are much more of a 
> > design/development tool than a deployment/support tool. They're 
> > really a type of post-it note tied into the repository.
> 
> I'd like to try it.  But now, suppose you have a project on github and
> you want to make it easy for people to report bugs.  Clearly you need to
> enable the GitHub issue tracker, right?  How do you integrate that with
> your be workflow?

That problem, for me personally at least, comes up infrequently 
enough that copying & pasting is sufficient for now.

I absolutely agree that it would be simply great that should say a 
github bug be assigned to dabrahams on github then it automagically 
gets pushed into your personal branch. You'd probably need a custom 
tracker plugin for github though given github's design (github is 
weird and doesn't appear to export its issues as RSS). Redmine and 
Trac are much more accommodating.

A post-fetch hook in git could pull the RSS bug feed, scan it for 
things referencing you and push them into your personal BE easily 
enough once it had a JSON-RPC interface.

> > I agree though that a JSON-RPC interface to BE would be a very useful 
> > addition, not just to aid BEurtle's performance, and of course from 
> > that a dynamic web interface becomes much easier. My thread regarding 
> > the topic (http://void.printf.net/pipermail/be-devel/2011-
> > September/thread.html) went nowhere though. Again, I might add the 
> > support myself for the next BEurtle release and upload it as a fork 
> > to pypi as BE's author is unwilling to permit BE to go onto pypi.
> 
> Seriously?  That's not a very good sign.  Why not?  I found installing
> BE to be a bit of a struggle.

I agree :) not helped by unspecified dependencies.

BE's author feels that BE ought to be supplied as a vendor distro 
package e.g. .deb for debian, .rpm for Fedora etc. He feels that 
anything which parallels that is unhelpful. He did mention that once 
BE is ported to Python3k he'd support using distribute.py.

In http://void.printf.net/pipermail/be-devel/2011-
September/000839.html I pointed out that Linux still occupies a small 
minority of developer eyeballs. Windows still is the overwhelming 
majority, and pypi is the best you have there. I argued for a pypi 
based windows distro especially as it makes dealing with Windows 
Installer easier (I hope you have never had to deal with Windows 
Installer. It sucks, even with WiX to hand).

In http://void.printf.net/pipermail/be-devel/2011-
September/000845.html I asked for permission to upload a windows fork 
of BE fixing several show stopping Windows-specific bugs to pypi but 
there was no answer.

I'll give it a while longer out of grace. I might make a new BEurtle 
release a Christmas holiday personal project :) I originally wrote 
nedmalloc that way too.

Niall

-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.



_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

[prev in list] [next in list] [prev in thread] [next in thread]