Hi,

> > ** Forks **
> > 
> > You can see the summary of the fork script there:
> > http://manao.inria.fr/eigen_tmp/archive_forks_log.html 
> > <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.

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. 

> 
> > ** 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.

Another topic: How about creating a gitlab.com <http://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?

    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 <mailto: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 
> > <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 
> <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 <mailto:christoph.hertzb...@dfki.de>
> 
>   Weitere Informationen: http://www.dfki.de/robotik 
> <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