[IPython-dev] Bug blitz: a weekend report

[Brian Granger]

Fernando,

Great job.  I love it!

> my little bug blitz has been fairly successful.  I forgot to write the
> numbers down yesterday morning when I started, but I think we had
> around 100 new bugs, most of which hadn't even been looked at.  Now
> the numbers are:
>
> amirbar[hydrazine]> ./capture-bug-counts
> loaded existing credentials
> getting project... ipython (IPython - Enhanced Interactive Python)
> By Status..................................................................................................................................................................................................................
>     4 In Progress
> https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.status=In
> Progress
>    78 Fix Committed
> https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.status=Fix
> Committed
>    14 Triaged https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.status=Triaged
>    96 Confirmed
> https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.status=Confirmed
>    18 Incomplete
> https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.status=Incomplete
>
> Bugs with patches................
>    16 HasPatch
> https://bugs.edge.launchpad.net/ipython/+bugs?search=Search&field.has_patch=on
>
> Of those 16 with patches, 15 have already been committed, and the
> remaining one is 400600 that Brian and Vishal are helping with, so it
> will be in as well.

I will look at this one soon.

> We have now *zero* bugs marked 'new'.  I was able to close a ton of
> small things, applied all available patches (I was trying to ensure no
> user contribution went ignored), and in general marked as 'confirmed'
> anything that looked remotely reasonable.  So in this case,
> 'confirmed' doesn't always mean that I actually confirmed the bug,
> just that the report looked sensible enough to keep the bug alive on
> github.

OK I think this makes sense.

> If you now look at our bug page:
>
> https://bugs.launchpad.net/ipython
>
> we appear to have 210 open ones, but in reality a good chunk of those
> have committed fixes, just awaiting a release of 0.10.1/0.11.  If we
> exclude 'fix committed', we get:
>
> https://bugs.launchpad.net/ipython/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&search=Search
>
> for a total of 132 open ones.
>
> I can already download those 132 in Python, and I hope later this week
> to find the time to write the github upload part, so this time around
> we will not lose any bug history or data.  I still feel bad that we
> abandoned some bugs reported in our old trac instance at scipy.org,
> and I really don't want to repeat that mistake.

It will be great to have all of these tickets migrated to github.  At
the same time, deleting all bug reports (like we did when we moved to
LP) is not *that* bad.  The real and important bugs always show up
again - it is sort of a way of testing which are real and important.
The only bummer is work that people have done in tracking the bugs
down, fixing them etc.  But it sounds like this time we won't loose
any of that, which is great.

> Importantly, once we close #400600, we won't have any bug with a patch
> left on LP (I can't migrate those easily). For the others, I'm pretty
> certain that I can migrate them back up to GH with all comment
> discussion and most relevant metadata (as labels).
>
> Upon upload, since all we have are labels, I'm going to use something
> similar to what Robert showed us Google code uses: label-value for
> key/value labels.  For now GH doesn't provide any semantic support
> behind this syntax, but we can later ask them for it based on the
> Google model, and if they follow through, we'll be ready :)

Sounds great, but lets keep our labels and values simple.

> So little by little, we're making good progress towards being able to
> move 100% of our relevant code and bug history from bzr/Launchpad to
> git/github.  Thanks for everyone's patience.  I hope that this setup
> will give us a smoother workflow where contributions will be both
> easier to make and to integrate.

Thanks for working on this!

Brian

> Regards,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com