On Thu, Sep 12, 2019 at 12:59 AM David Tellenbach <
david.tellenb...@tellnotes.org> wrote:

> But is it our responsibility to archive such forks? There could be forks
> for personal purpose only with no intend to create a PR at all. Should we
> really bother to archive these? (At least) everyone with a mercurial repo
> on bitbucket has received an email that mercurial support will be dropped.
> If someone thinks his fork is worth keeping, the person should archive it
> or open a PR. I think the keeping the changesets of all PRs is enough.
>

We're talking about open-source code. IMO this should be the responsibility
of bitbucket to keep them read-only for a few more years. Anyways, I
already have them archived on my computer, so that's a minor aspect. Let's
focus on the other ones.


>
>> > ** Pull-Requests **
>>
>> Does gitlab allow to map "[Bb]ug (\d+)" to (an archive of) our bugzilla
>> page and "\#(\d+)" to either the archived old PRs or new PRs/issues? (if
>> need be, we could manually create issues #1 to #7xx with just a link to
>> the archived PRs.
>>
>
> I haven't check that yet.
>
>
> If there's no possibility to automatically forward Bugs/PRs, it should
> again be possible to create those automatically using the GitLab API.
>

In gitlab issues are referenced with #123 and merge-requests with !123 (see
https://docs.gitlab.com/ee/user/markdown.html#special-gitlab-references)

So when switching from hg to git, we could do: "([Bb]ug) (\d+)" -> "\2 #\1"
in the commit messages. For bug comments, this change is already taken care
by the bz2gitlab migration script.

For old pullrequests, it is possible to automatically link WHATEVER-XYZ to
https://some_url/XYZ via the "custom issue tracker" service. Demo:
https://gitlab.inria.fr/guenneba/eigen-bzmigration-test2/issues/1#note_234549
So we could rewrite old PR references as PR-XYZ. One shortcoming though is
that you cannot configure what "WHATEVER" is. The underlying matching regex
seems to be as general as: "[a-zA-Z]-(\d+)". Still ok I guess.


> Another topic: How about creating a gitlab.com group (since eigen is
> taken I suggest eigen-official) and create a migration repo where we host
> all the migration stuff and scripts?
>

I've asked the owner of gitlab.com/eigen last week to see if he would be
super kind to release the "eigen" username for us (as it seems to be used
by himself only), but no answer yet. Without a positive answer we could
think about:

eigen-official
eigen-team
libeigen

gael



>
>     David
>
> On 11. Sep 2019, at 23:27, Gael Guennebaud <gael.guenneb...@gmail.com>
> wrote:
>
>
>
> On Wed, Sep 11, 2019 at 6:50 PM Christoph Hertzberg <
> c...@informatik.uni-bremen.de> wrote:
>
>>
>> > ** Forks **
>> >
>> > You can see the summary of the fork script there:
>> > http://manao.inria.fr/eigen_tmp/archive_forks_log.html
>> >
>> > The hg clones (history+checkout) represents 20GB, maybe 12GB if we
>> remove
>> > the checkouts. Among the 460 forks, 214 seems to have no change at all
>> > (according to "hg out") and could be dropped. I don't know yet where to
>> > host them though.
>>
>> I think it is sufficient if we host a (frozen) version of the main
>> repository (probably simply at tuxfamily). I think many forks don't have
>> changes, because they actually got merged.
>> And I don't think we need to host any of the forks, as long as we have
>> the changesets in the archived PRs.
>>
>
> I don't think all forks with changes have a related PRs, but forks
> exhibiting changes and that are associated to a close PR can probably be
> ignored too.
>
>
>>
>> > ** Pull-Requests **
>>
>> Does gitlab allow to map "[Bb]ug (\d+)" to (an archive of) our bugzilla
>> page and "\#(\d+)" to either the archived old PRs or new PRs/issues? (if
>> need be, we could manually create issues #1 to #7xx with just a link to
>> the archived PRs.
>>
>
> I haven't check that yet.
>
> Did we actually plan to migrate bugzilla to gitlab-issues as well?
>> Would we do this by just creating new issues with a link to the
>> bz-archive? (This would be only slightly inconvenient if discussions are
>> split, but that's ok, IMO)
>>
>
> See this first attempt:
> https://gitlab.inria.fr/guenneba/eigen-bzmigration-test1/issues
> Almost everything is preserved including the bug's ID. We can also
> automatically mark the bz bugs as "MOVED" with a link to the respective
> gitlab entry.
> I'll share the updated bz2gitlab migration script asap. My main concern
> about gitlab issues is that comments are not searchable, only the
> description is.
>
> gael
>
> > ** hg to git **
>> >
>> > However, updating the hashes within the commit messages will require to
>> > rewrite the whole history in a careful order. Does anyone here feels
>> brave
>> > enough to write such a script? If not, I guess we could live with an
>> online
>> > php script doing the hash conversion on demand. I don't think we'll
>> have to
>> > follow such hashes so frequently.
>>
>> I agree that it won't be required that often (most "grafted from"
>> references are very close to each other anyway). If we have some tool
>> which can look-up hashes I think we are fine. (I won't prevent anyone
>> from trying to translate the hashes inside the history, of course *g*)
>>
>>
>> Christoph
>>
>>
>>
>> >
>> > cheers,
>> > gael
>> >
>>
>> --
>>   Dr.-Ing. Christoph Hertzberg
>>
>>   Besuchsadresse der Nebengeschäftsstelle:
>>   DFKI GmbH
>>   Robotics Innovation Center
>>   Robert-Hooke-Straße 5
>>   28359 Bremen, Germany
>>
>>   Postadresse der Hauptgeschäftsstelle Standort Bremen:
>>   DFKI GmbH
>>   Robotics Innovation Center
>>   Robert-Hooke-Straße 1
>>   28359 Bremen, Germany
>>
>>   Tel.:     +49 421 178 45-4021
>>   Zentrale: +49 421 178 45-0
>>   E-Mail:   christoph.hertzb...@dfki.de
>>
>>   Weitere Informationen: http://www.dfki.de/robotik
>>    -------------------------------------------------------------
>>    Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
>>    Trippstadter Strasse 122, D-67663 Kaiserslautern, Germany
>>
>>    Geschäftsführung:
>>    Prof. Dr. Jana Koehler (Vorsitzende)
>>    Dr. Walter Olthoff
>>
>>    Vorsitzender des Aufsichtsrats:
>>    Prof. Dr. h.c. Hans A. Aukes
>>    Amtsgericht Kaiserslautern, HRB 2313
>>    -------------------------------------------------------------
>>
>>
>>
>>
>

Reply via email to