kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #42207
Re: GitLab migration
Please note I don't think this will be a problem for macOS packaging
at all, but we do it differently than other folks.
On Wed, Oct 9, 2019 at 1:45 PM Steven A. Falco <stevenfalco@xxxxxxxxx> wrote:
>
> On 10/9/19 12:36 PM, Wayne Stambaugh wrote:
> > The lead development team has been discussing migrating the KiCad
> > project to GitLab[1].
>
> For packagers, I'm curious as to how creating an archive from a tag would work. Currently, to grab the source from launchpad, we use a URL like:
>
> https://launchpad.net/kicad/5.0/%{version}/+download/kicad-%{version}.tar.xz
>
> where %{version} is a Fedora macro that expands to the desired version. This apparently works because Wayne explicitly uploads the tarball to launchpad.
>
> For github, we use:
>
> https://github.com/KiCad/kicad-doc/archive/%{version}.tar.gz
>
> This works because github has an API that creates the tarball on-demand.
>
> I found some references regarding how this works in GitLab. For example, please see Issue 38830:
>
> https://gitlab.com/gitlab-org/gitlab-foss/issues/38830
>
> According to that issue, you can request a tarball from GitLab, similarly to what you would do with GitHub. However, when you request a tarball of a tag, the SHA will be part of the filename. Worse, the top level directory will also contain the SHA.
>
> This will complicate packaging, because we'll need to know the expected SHAs for each of the 7 repos, and rename the directories as the tarballs are unpacked. Or I suppose we could use wildcards to achieve the same thing. It is certainly doable, but it is a bit ugly.
>
> Steve
>
> > Given the issues with Launchpad, I think this is
> > a good move. I've applied for an open source GitLab license. Assuming
> > we get accepted, I would like to start this process after the 5.1.5
> > release. Here is a short list of action items that need to be done for
> > the source repo transition:
> >
> > * Freeze the Launchpad source repo.
> > * Push the frozen repo to GitLab.
> > * Disable the Launcpad bug tracker.
> > * Add a note and link to the Launcpad project page that the project is
> > now hosted on GitLab.
> > * Create blog announcement once the transition is complete.
> >
> > There are a few unknowns:
> >
> > Would it be possible to migrate open bug reports to GitLab? I suspect
> > we could come up with a script like we did when we migrated from
> > SourceForge.
> >
> > What to do about the mailing list? GitLab doesn't support mailing lists
> > yet so I'm thinking we leave the mailing list on Launchpad for the short
> > term. We can always migrate the mailing list at a later date or use
> > some other communication tool such as discourse.
> >
> > Further down the road, I would like to see all of the KiCad source repos
> > including the library, documentation, website, and translation repos
> > migrated to GitLab as well. It would make my life a lot easier from a
> > project management perspective if they were all in the same place. I
> > expect there to be some resistance to using a source code version tool
> > but I'm hoping folks will see this as a beneficial move. I'm not
> > terribly familiar with GitLab but I suspect it's not that much different
> > than GitHub as a hosting platform so I don't expect there to be a very
> > steep learning curve. If you have any concerns, now is the time to
> > speak up or forever hold your peace.
> >
> > Cheers,
> >
> > Wayne
> >
> > [1]: https://gitlab.com/
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help : https://help.launchpad.net/ListHelp
> >
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
Follow ups
References