Re: [Scons-dev] SCons, Mercurial, BitBucket, Git, and GitHub
Dirk, Re bug scraper If we migrate all bugs to GitHub, isn't there an issue # associated with github issues? If so, can we migrate the bugs such that the issue #'s stay the same? -Bill On Mon, Aug 28, 2017 at 2:02 PM, Dirk Bächle wrote: > Hi Russel, > > > On 28.08.2017 09:43, Russel Winder wrote: > >> [...] >> >> >> The question then has to be how to bring the issues from Tigris to >> GitHub. GitHub issues has an API. If Tigris Issues also has an API then >> it is a question of writing a program, I guess in Python3, since that >> is likely easier than trying to find tools to do the job. For me, there >> is no point in leaving the issues at Tigris. No matter how much better >> the interface is perceived to be compared to GitHub issues, to get the >> integrated workflow of GitHub, it is essential to have the issues on >> GitHub. >> >> > not so quick young grasshopper. ;) (Sorry, I couldn't resist) > > 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. > > 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. > > 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. > > 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. > > Best regards, > > Dirk > > ___ > Scons-dev mailing list > Scons-dev@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev > ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Problematic conflicts between C/C++ and D
so a better solution would be:
env['SHOBJSUFFIX'] = env.get('SHOBJSUFFIX','.os')
?
On Mon, Aug 28, 2017 at 2:17 AM, Russel Winder wrote:
> On Wed, 2017-08-23 at 09:56 -0700, Bill Deegan wrote:
> > Don't avoid TARGET..
> >
> > Here's where it's defined:
> > src/engine/SCons//Tool/cc.py:env['SHOBJSUFFIX'] = '.os'
> > src/engine/SCons//Tool/cxx.py:env['SHOBJSUFFIX'] = '.os'
> >
> > Will setting the SHOBJSUFFIX in the relevant D tools do the trick?
>
> The problem is that the setting is global in the default tool set so it
> being set to .os in cc and cxx affects all the global default tool set.
> If I set this is the dmd, ldc, and gdc tools to .o then it breaks the
> cc and cxx tools. Been there, tried this, removed the experiment.
>
> The default tools share a single namespace of environment variables and
> this is the problem if the tools disagree on anything. In this case the
> majority has to win so the dmd and ldc tools are just going to have to
> remain broken in the default toolset. :-(
>
> --
> Russel.
>
> =
> Dr Russel Winder t: +44 20 7585 2200 voip:
> sip:russel.win...@ekiga.net
> 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
> London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] SCons, Mercurial, BitBucket, Git, and GitHub
Hi Russel, On 28.08.2017 09:43, Russel Winder wrote: [...] The question then has to be how to bring the issues from Tigris to GitHub. GitHub issues has an API. If Tigris Issues also has an API then it is a question of writing a program, I guess in Python3, since that is likely easier than trying to find tools to do the job. For me, there is no point in leaving the issues at Tigris. No matter how much better the interface is perceived to be compared to GitHub issues, to get the integrated workflow of GitHub, it is essential to have the issues on GitHub. not so quick young grasshopper. ;) (Sorry, I couldn't resist) 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. 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. 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. 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. Best regards, Dirk ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Problematic conflicts between C/C++ and D
On Wed, 2017-08-23 at 09:56 -0700, Bill Deegan wrote: > Don't avoid TARGET.. > > Here's where it's defined: > src/engine/SCons//Tool/cc.py:env['SHOBJSUFFIX'] = '.os' > src/engine/SCons//Tool/cxx.py:env['SHOBJSUFFIX'] = '.os' > > Will setting the SHOBJSUFFIX in the relevant D tools do the trick? The problem is that the setting is global in the default tool set so it being set to .os in cc and cxx affects all the global default tool set. If I set this is the dmd, ldc, and gdc tools to .o then it breaks the cc and cxx tools. Been there, tried this, removed the experiment. The default tools share a single namespace of environment variables and this is the problem if the tools disagree on anything. In this case the majority has to win so the dmd and ldc tools are just going to have to remain broken in the default toolset. :-( -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +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
[Scons-dev] SCons, Mercurial, BitBucket, Git, and GitHub
Whist I can't commit to working on anything in the next few weeks, I wanted to chip this in to the discussions. With bookmarks, remote head tracking and hgview working (at least on Debian Sid, not Fedora Rawhide), I have a renewed real like of Mercurial. It is better than Git for me. However hgview now seems to be broken – the word moved on, hgview has not been maintained – so practical Mercurial workflow is demolished, unless I can find an equivalent replacement, "hg log -G" just doesn't cut it. BitBucket really seems to be loosing dramatically to GitHub as the central resource for distributed version control – central being critical to distributed has to count as the ultimate irony of software development. The connectedness of pull requests, issues, CI, etc. on GitHub is a workflow model that BitBucket seems to have lost somewhere since Atlassian took it over, promoted Git over Mercurial and lost track of how to keep FOSS people happy to promote a commercial product. Much is wrong with GitHub, but it is far superior to BitBucket, which is a 2017 tragedy. I believe that switching SCons from Mercurial to Git on BitBucket, and then moving the repository to GitHub is the right thing to do, and the sooner the better. But as I said at the outset, I can't help for a few weeks yet. Once SCons itself is on GitHub, I will migrate all the separate tools and plugins repositories that I have control over to GitHub from BitBucket – even though I prefer Mercurial over Git. I will then update the wiki page – will this transfer to GitHub? or maybe the current website and wiki provision is secure? The question then has to be how to bring the issues from Tigris to GitHub. GitHub issues has an API. If Tigris Issues also has an API then it is a question of writing a program, I guess in Python3, since that is likely easier than trying to find tools to do the job. For me, there is no point in leaving the issues at Tigris. No matter how much better the interface is perceived to be compared to GitHub issues, to get the integrated workflow of GitHub, it is essential to have the issues on GitHub. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +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
