[Ohrrpgce] Importing bugzilla bugs into github

Sun Feb 23 17:15:29 PST 2020

An update: I haven't worked on this for a couple weeks, but I was pretty
close to having it working, just making tweaks. Want to get it done before
I get distracted with this year's 7DRL. All the old attachments are
uploaded (along with http://rpg.hamsterrepublic.com/bugzilla/quips.txt and
http://rpg.hamsterrepublic.com/bugzilla/buglist.xml). Then I can look at
Sourceforge.

I'd never paid much attention to "Projects" on Github before, but they seem
more useful than using Milestones for todo lists. Milestones let you
reorder issues/PRs, but Projects let you also sort into columns, eg for
priority. The project UI is very different. But the most important feature
is that you can add note cards, not just issues. They can also contain
issues from multiple repositories, although project-issue crosslinking only
works if project and issue are in the same repo or it's a project in the
'ohrrpgce' organisation and the issue is in a repo under the ohrrpgce
organisation**.

Compare:
https://github.com/ohrrpgce/ohrrpgce/milestone/1
https://github.com/orgs/ohrrpgce/projects/1

But milestones and projects seem pretty redundant to each other. I wonder
whether to use milestones at all. (Maybe just to tag closed bugs, not as a
todo list for a release?)

** Adding an issue to a project crosslinks it from the issue itself, see eg
https://github.com/ohrrpgce/ohrrpgce/issues/5.
We might want to add more repos to the ohrrpgce organisation, so could make
sense to put the projects there instead of the repo. For example, I'm
thinking of splitting 'web' and 'tools' branches out to separate git repos,
since it's pretty inconvenient and strange to have them as orphaned
branches.
I'm also wondering whether a separate repo where crash reports are
automatically uploaded to could be a handy way to manage them.

On Sat, 8 Feb 2020 at 01:51, James Paige <Bob at hamsterrepublic.com> wrote:

> That is even better!
>
> On Fri, Feb 7, 2020, 4:50 AM Ralph Versteegen <teeemcee at gmail.com> wrote:
>
>> https://rpg.hamsterrepublic.com/bugzilla/ already exists (it's a
>> redirect to the sf buglist, plus hosts
>> https://rpg.hamsterrepublic.com/bugzilla/buglist.txt). So I guess the
>> logical URL to use is
>> https://rpg.hamsterrepublic.com/bugzilla/old-attachments/
>>
>> <https://rpg.hamsterrepublic.com/old-bugzilla-attachments/>
>>
>> On Fri, 7 Feb 2020 at 14:40, James Paige <Bob at hamsterrepublic.com> wrote:
>>
>>> Oops! Yes!
>>>
>>> How about putting them at
>>> https://rpg.hamsterrepublic.com/old-bugzilla-attachments/ ?
>>>
>>>
>>> On Thu, Feb 6, 2020, 5:53 PM Ralph Versteegen <teeemcee at gmail.com>
>>> wrote:
>>>
>>>> Oh, right! The main reason I wrote that email was to ask about
>>>> uploading the bug attachments somewhere. I see there are still various
>>>> redirects and remnants of bugzilla left behind.
>>>>
>>>> On Fri, 7 Feb 2020 at 02:47, Ralph Versteegen <teeemcee at gmail.com>
>>>> wrote:
>>>>
>>>>> I agree that too many labels aren't helpful. Labels are most useful
>>>>> when you can't just do a text search (all crash bugs will be easily found
>>>>> with a search for "crash"), eg for bug priorities.
>>>>> I think maybe I'll combine "cosmetic" and "minor" into a single
>>>>> "minor" tag, since we likely want that one anyway while "cosmetic" is too
>>>>> specific. Wait, how much difference is there between "minor" and "needs
>>>>> improvement"?  Plenty of outright bugs are merely cosmetic. Argh!
>>>>> Really, "bug" is a region of the continuum (nearly the whole
>>>>> continuum) from feature request to "needs improvement" to blocker.
>>>>>
>>>>> But... major/high priority bugs is possible the most likely thing of
>>>>> all that we would want to categorise and search for. And they aren't
>>>>> necessarily going to be put on the todo list for the next release
>>>>> (milestone). So I guess I should map major/critical/blocker to "major".
>>>>> Although the categorisation of bug severities on bugzilla is pretty
>>>>> dubious, it is a useful starting point.
>>>>>
>>>>> 7d344553-34f0-0310-a9b1-970ce8f1c3a2 is the "Repository UUID" you see
>>>>> when running "svn info".
>>>>> It's also possible to give git-svn a file with mapping from username
>>>>> to actual email, but that won't apply retroactively.
>>>>>
>>>>> On Fri, 7 Feb 2020 at 02:08, James Paige <Bob at hamsterrepublic.com>
>>>>> wrote:
>>>>>
>>>>>> Cool!
>>>>>>
>>>>>> I like the idea of rel: and resolved: prefixes.
>>>>>>
>>>>>> I vote for eliminating the "bug" tag completely. In general I say err
>>>>>> on the side of fewer tags when the specific need for a tag is not obvious.
>>>>>>
>>>>>> That GitHub contributions trick is cool. I'll try it. Is
>>>>>> 7d344553-34f0-0310-a9b1-970ce8f1c3a2 the internal ID of our svn repo?
>>>>>>
>>>>>> On Thu, Feb 6, 2020, 8:04 AM Ralph Versteegen <teeemcee at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, 7 Feb 2020 at 01:43, Ralph Versteegen <teeemcee at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I've been putting this off for years (two years since my last
>>>>>>>> attempt in fact) but I've finally managed to get bugzilla running locally
>>>>>>>> and import the databases so that I can export the buglist as xml and use this
>>>>>>>> script
>>>>>>>> <https://gist.github.com/Zimmi48/d923e52f64fe17c72852d9c148bfcdc6#file-bugzilla2github>
>>>>>>>> to import it into github.
>>>>>>>>
>>>>>>>> I'm now in the process of customising the script and the mapping to
>>>>>>>> labels.
>>>>>>>>
>>>>>>>> Github doesn't have an API that allows attaching files to issue
>>>>>>>> comments, so I suggest that we upload all the attachments to a directory on
>>>>>>>> hamsterrepublic.com so that we can link to them.
>>>>>>>> (Unfortunately I first have to write a script to extract them out
>>>>>>>> of the bugzilla DB.)
>>>>>>>>
>>>>>>>> With all the labels for components, versions, severity, status,
>>>>>>>> etc, we'll have a lot of labels. I think it makes sense to organise our
>>>>>>>> labels a bit better. All version labels could be prefixed with "rel: ",
>>>>>>>> like "rel: alectormancy". And maybe duplicate, wontfix, invalid,
>>>>>>>> worksforme, tooconfusing
>>>>>>>> could be prefixed with "resolved:" or "closed:"?
>>>>>>>>
>>>>>>>> I'm going to translate the "feature request", "cosmetic", "blocker"
>>>>>>>> severities into labels. I think I'll leave behind "major", "minor",
>>>>>>>> "normal" and "critical", and the priority levels. They (if not default
>>>>>>>> value) will still be in the bug description.
>>>>>>>>
>>>>>>>> There isn't really anything that corresponds closely to our gh
>>>>>>>> "bug" and "needs improvement" labels. I wonder whether we should just
>>>>>>>> remove the "bug" label, since although it's informative and useful in
>>>>>>>> searches, it's already a nuisance to accurately tag all the bugs** and
>>>>>>>> we'll get an extra 1000 bugs missing it. "bug" is basically the absense of
>>>>>>>> numerous special categories like "new feature", "invalid" and "tracking".
>>>>>>>>
>>>>>>> Or, I could just apply "bug" as a guess according to something like
>>>>>>> that simple rule, and we can fix up any mistakes. Will be looking through
>>>>>>> all the open imported bugs anyway.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> **See
>>>>>>>> https://github.com/ohrrpgce/ohrrpgce/issues?utf8=%E2%9C%93&q=-label%3Abug+-label%3A%22needs+improvement%22++-label%3A%22new+feature%22
>>>>>>>>
>>>>>>>> Bugzilla hides people's email addresses (by stripping the domain)
>>>>>>>> by default so user names will be something like "David Gowers <00ai99>". I
>>>>>>>> think that's fine. I can (am planning to) also replace the username with a
>>>>>>>> github @ mention (it shouldn't cause any notifications, because this is the
>>>>>>>> mass import API), but the only people who I know the github username of are
>>>>>>>> myself, James and Mike. Doesn't matter.
>>>>>>>>
>>>>>>>>
>>>>>>>> BTW, I found that it's possible to make svn commits copied to the
>>>>>>>> git-svn mirror on github count towards your "contributions" shown on your
>>>>>>>> github profile page. To do so, add a new email address to your github
>>>>>>>> account with the form svncommitername at 7d344553-34f0-0310-a9b1-970ce8f1c3a2,
>>>>>>>> where svncommitername is e.g. teeemcee or james. The email can be private.
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Ohrrpgce mailing list
>>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>>>
>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Ohrrpgce mailing list
>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>>>
>>>>> _______________________________________________
>>>> Ohrrpgce mailing list
>>>> ohrrpgce at lists.motherhamster.org
>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>
>>> _______________________________________________
>>> Ohrrpgce mailing list
>>> ohrrpgce at lists.motherhamster.org
>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20200224/de2852e5/attachment.html>