<div dir="ltr">For what it's worth, I tried to follow the instructions on <a href="https://code.google.com/p/support-tools/wiki/IssueExporterTool">https://code.google.com/p/support-tools/wiki/IssueExporterTool</a> today to grab a backup of our issues, and failed in the very first step:<div><br></div><div><div>% git clone <a href="https://code.google.com/p/support-tools">https://code.google.com/p/support-tools</a></div><div>Cloning into 'support-tools'...</div><div>fatal: missing blob object '2f78cf5b66514f2506d9af5f3dadf3dee7aa6d9f'</div><div>fatal: remote did not send all necessary objects</div><div>Unexpected end of command stream</div><div>zsh: exit 128</div></div><div><br></div><div>I don't suppose any of you have a copy of the tool because you exported issues from a different project...?</div><div>~d</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 6, 2015 at 11:47 AM, Peter Jones <span dir="ltr"><<a href="mailto:mlists@pmade.com" target="_blank">mlists@pmade.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Tuncer Ayaz <<a href="mailto:tuncer.ayaz@gmail.com">tuncer.ayaz@gmail.com</a>><br>
writes:<br>
<span class="">> On Thu, Aug 6, 2015 at 4:51 PM, Brandon Allbery wrote:<br>
>> So are we going to do anything about Google Code Issues going away<br>
>> in a little over two weeks?<br>
><br>
> First question is whether existing tickets have to be preserved. If<br>
> so, then where should the migration lead to?<br>
><br>
> Second question is whether Darcs a strict requirement. If so,<br>
> <a href="http://hub.darcs.net" rel="noreferrer" target="_blank">hub.darcs.net</a> could work, as darcs support on <a href="http://haskell.org" rel="noreferrer" target="_blank">haskell.org</a> seems to be<br>
> deprecated.<br>
><br>
> Either way, wasn't the plan to move to <a href="http://haskell.org" rel="noreferrer" target="_blank">haskell.org</a>'s infrastructure<br>
> and leverage Phabricator (with hg or git)? For a feature overview, see<br>
> <a href="http://phabricator.org/comparison/" rel="noreferrer" target="_blank">http://phabricator.org/comparison/</a>. That seems like a good<br>
> "future-proof" path to take, if you ask me.<br>
><br>
> Alternatively, Bitbucket, Gitlab, or Github could make sense. Gitlab<br>
> has its own CI tool, so that's a plus, but other than that (for<br>
> XMonad's case) there's no clear winner between the three.<br>
><br>
> Also, like the pending release, this is another administrative topic<br>
> for which there seems to be nobody responsible who also happens to be<br>
> blessed with enough free time. Therefore, it's important to assign the<br>
> tasks, once the migration path has been decided.<br>
<br>
<br>
</span>We all have strong opinions about which tools and hosting providers we<br>
should be using.  That seems to have stalled any movement on this front.<br>
We're not all going to agree on this so we should just accept that all<br>
of the options are workable and pick the one with the least amount of<br>
resistance.<br>
<br>
I volunteer to be the release manager for the project if we switch to<br>
Git and host the code and tickets on Github.<br>
<br>
It's not a perfect solution but it does have everything we need and<br>
there's almost an expectation these days that open source projects are<br>
hosted on it.  This might have the side effect of increasing the number<br>
of contributions to xmonad.  At the very least it gives the project more<br>
visibility.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Peter Jones, Founder, Devalot.com<br>
Defending the honor of good code<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
xmonad mailing list<br>
<a href="mailto:xmonad@haskell.org">xmonad@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad</a><br>
</div></div></blockquote></div><br></div>