On Mon, 2017-08-28 at 23:02 +0200, Dirk Bächle wrote: > […] > > not so quick young grasshopper. ;) (Sorry, I couldn't resist)
Resistance is futile. (7of9) Do or do not, there is no try. (Yoda) > I already have a working and complete scraper for the Tigris > bugtracker. > It's written in Python2 though, but this wouldn't really be a > showstopper, would it? > I contributed the code in a slightly changed form to the OpenHatch > project, but it's also available in a stand-alone form. It downloads > all > issues, together with their notes and attachments into XML files. > There > exist also "wrapper" classes for accessing single issues and > messages. Given it is a one off tool and we need to use it, let's not get too hung up about Python 2 or 3 for this one – even though Python 2 is now just wrong. :-0 > It may be true that Github has an API for entering bugs, so a > migration > looks like it's a "piece of cake". But be warned that there is caveat > in > the form of the "creation date" of single issues. As far as I know, > and > the last time I looked, there is no API method to set the creation > date > of an issue. > The OpenHatch project itself learned this the hard way when they > migrated their issue database to Github. Suddenly all issues would > have > the same creation date. There was no chance to distinguish between > old > and new issues (something that I would still like to be able to) and > a > lot of tears were cried. Given we are moving from Tigris to GitHub, I can't get worked up about issue creation dates. To be honest I can't get that worked up about transferring the issues, I'd just start from scratch on GitHub issues and have people manually transfer the ones from Tigris they actually care about. Having done something analogous twice, not doing a full automated transfer is a great way of getting rid of all the ancient and out of date issues. Removing all the weight of ancient issues is a great way of creating new energy for a project. > A while ago someone showed up on the dev mailing list, being > interested > in migrating our issue tracker to Jira. I gave him my scraper > sources, > mentioned the "creation date" problem...and then never heard about > this > project again. Providing hurdles too high to jump is a great way of reducing enthusiasm to zero. > Finally and trying to not sound like a broken record, I also do have > an > almost complete migration to the Roundup bug tracker. We've > demonstrated > in a live instance that the basic migration works and all data is > kept. > That's where the work stopped, because I'm still waiting for a > "go/no > go" decision to migrate to a separate Roundup tracker instance. This > hasn't happened yet...and I don't say this all while holding grief > over > the whole issue. I'm simply reporting what the status of work on > this > topic is, or better: was when I left it. > > How to continue from here is definitely worth a discussion. For a very few volunteers organisation such as this, low overhead, low cost, low maintenance, high leverage solutions are the only ones worth following up on. To this end if SCons is to move to GitHub then I suggest using the GitHub issues is the only viable solution for an issue tracker – no matter how bad the system is. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev