<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">Le jeu. 15 févr. 2018 à 13:03, Jürgen E. Fischer <<a href="mailto:jef@norbit.de">jef@norbit.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Denis,<br>
<br>
On Thu, 15. Feb 2018 at 15:05:14 +0000, Denis Rouzaud wrote:<br>
> On practical points, proof of concept was achieved by Matthias (and some<br>
> others) and showed all of this is possible except attributing comments to<br>
> the original author...bummer ;).<br>
<br>
News to me.  The migration didn't go though - I thought Matthias had given up<br>
on the migration, because he was uncertain that we'd go through with it and it<br>
might end up as a waste of energy.  And his target was not to do a full<br>
migration - IIRC.<br></blockquote><div><br></div><div>Well, it depends on what we mean by migration of course (moving all tickets? all tags? etc). <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I tried a full migration - and ran into obstacles from github (eg. throtteling)<br></blockquote><div><br></div><div>proposition was to contact Github, correct?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and had doubts about mapping all what we have in redmine to tags in github </blockquote><div><br></div><div>well, again depends on what we're migrating. History or tags. My proposition is to start with a new empty list for QGIS 3 and migrate issues on demand (with an assitant tool, triggered from Redmine or semi-manually).</div><div>And for the history, to keep Redmine as read-only.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-<br>
and how useable it would be which such a large number of issues and/or tags as<br>
ours.<br>
<br>
Richard tried again later and also gave up.<br>
<br>
Attributing comments to the original author was just one thing that couldn't be<br>
done at all.<br>
<br>
We finally settled to upgrade and move redmine to a faster machine - and that<br>
was that.<br></blockquote><div><br></div><div>Upgrading Redmine should certainely help the migration as the original migration tool was for more recent version, correct? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
And when this was brought up again, we didn't talk about the implementation<br>
(ie. how we map the trac/redmine ticket numbers to github issues - our commit<br>
messages reference the tickets).<br>
<br>
And then there was this sudden vote...<br></blockquote><div><br></div><div>I understand that. Let's wait for Madeira then. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> (because, damn, it's not integrated with the source code!).<br>
<br>
Of course it is linked to the source code.  It's just not linked to github,<br>
because github doesn't allow us to - otherwise we'd just address PRs and issues<br>
differently and let one point to github and the other to redmine.<br></blockquote><div><br></div><div>Of course, I meant source code repo! </div><div><br></div><div>I think we can discuss for ever on what has been done and what is possible. Then, we can adapt the decision tree and add the question:</div><div><br></div><div>If we can't keep the whole history, shall we stick to Redmine?</div><div>And what do we mean with whole history (added files, comments, tags, etc).</div><div><br></div><div>Denis</div><div><br></div></div></div>