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 <[email protected]> wrote: > > > > On Wed, Sep 11, 2019 at 6:50 PM Christoph Hertzberg > <[email protected] <mailto:[email protected]>> 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: [email protected] <mailto:[email protected]> > > 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 > ------------------------------------------------------------- > > >
