[Ohrrpgce] Importing bugzilla bugs into github

James Paige Bob at hamsterrepublic.com
Mon Feb 24 02:49:19 PST 2020


I have no strong preference for whether we use projects or milestones. I
guess for bigger projects with more people there must be a use case for
both.

Splitting web and tools into different git repos sounds good to me. If that
breaks anything regarding the subversion repo, I would be okay with
splitting them out of the svn repo also if needed.

On Sun, Feb 23, 2020, 8:16 PM Ralph Versteegen <teeemcee at gmail.com> wrote:

> 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
>>
> _______________________________________________
> 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/647e959f/attachment-0001.html>


More information about the Ohrrpgce mailing list