Re: SCons, Mercurial, BitBucket, Git, and GitHub

Russel Winder <[email protected]> Wed, 30 Aug 2017 13:31:51 +0100
Newsgroups	gmane.comp.programming.tools.scons.devel
Message-ID	<[email protected]>
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:[email protected]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [email protected]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

_______________________________________________
Scons-dev mailing list
[email protected]
https://pairlist2.pair.net/mailman/listinfo/scons-dev
signature.asc (application/pgp-signature, 833 B)