From: Adrian Bunk <bunk@stusta.de>
To: Paul Barker <paul@betafive.co.uk>
Cc: Yocto discussion list <yocto@yoctoproject.org>,
OE Architecture
<openembedded-architecture@lists.openembedded.org>,
OE Devel <openembedded-devel@lists.openembedded.org>
Subject: Re: [yocto] Using GitLab for OE/Yocto layers
Date: Wed, 6 Nov 2019 23:41:08 +0200 [thread overview]
Message-ID: <20191106214108.GC14721@localhost> (raw)
In-Reply-To: <ab96ec4a-5dcb-4d01-8519-13c00094a44c@www.fastmail.com>
On Wed, Nov 06, 2019 at 04:01:03PM +0000, Paul Barker wrote:
>...
> At the risk of bikeshedding I'd like to get some feedback on these ideas at this stage. Have I missed any advantages/disadvantages?
>...
Three comments from me:
1. Patch review
Merge requests work well when there is one maintainer who reviews
everything. For not regressing on the current level of review before
something hits master, merging a merge request into master-next
should then result in patch review emails sent to a list.
Or a setup where creation of a merge request automatically generates
review emails.
This is similar to all patches for stable branches now being sent for
review to the mailing list a few days before they get merged into the
stable branch, which has caught problematic patches due to more people
reviewing them.
2. Maintaining an own GitLab instance
This was mentioned as an option. Expect upgrades to new GitLab releases
once per month, which is work and as with all software never without
regression risk.
Not a dealbreaker, but has to be resourced.
3. Long-term suistainability
Whatever the past track record of GitLab is, chances are the company
behind it will sooner or later be bought by another company - and then
anything can happen.
The code behind SourceForge was also at some point made available under
an open source licence, and forks being used in instances like Debian
Alioth ended up being unmaintainable dead ends long-term.
Berkeley DB would be an example where the company behind the software
was bought by another company, and now there are plenty of CVEs that
are unfixable due to changed licencing.
Is there anyone capable and willing to continue open source maintainance
of the GitLab open source sources if the company behind it would stop
the open source releases tomorrow?
With projects like GNOME using GitLab the answer might be "yes",
but this should be evaluated before moving infrastructure to GitLab.
> Paul Barker
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
WARNING: multiple messages have this Message-ID (diff)
From: Adrian Bunk <bunk@stusta.de>
To: Paul Barker <paul@betafive.co.uk>
Cc: Yocto discussion list <yocto@yoctoproject.org>,
OE Architecture
<openembedded-architecture@lists.openembedded.org>,
OE Devel <openembedded-devel@lists.openembedded.org>
Subject: Re: Using GitLab for OE/Yocto layers
Date: Wed, 6 Nov 2019 23:41:08 +0200 [thread overview]
Message-ID: <20191106214108.GC14721@localhost> (raw)
In-Reply-To: <ab96ec4a-5dcb-4d01-8519-13c00094a44c@www.fastmail.com>
On Wed, Nov 06, 2019 at 04:01:03PM +0000, Paul Barker wrote:
>...
> At the risk of bikeshedding I'd like to get some feedback on these ideas at this stage. Have I missed any advantages/disadvantages?
>...
Three comments from me:
1. Patch review
Merge requests work well when there is one maintainer who reviews
everything. For not regressing on the current level of review before
something hits master, merging a merge request into master-next
should then result in patch review emails sent to a list.
Or a setup where creation of a merge request automatically generates
review emails.
This is similar to all patches for stable branches now being sent for
review to the mailing list a few days before they get merged into the
stable branch, which has caught problematic patches due to more people
reviewing them.
2. Maintaining an own GitLab instance
This was mentioned as an option. Expect upgrades to new GitLab releases
once per month, which is work and as with all software never without
regression risk.
Not a dealbreaker, but has to be resourced.
3. Long-term suistainability
Whatever the past track record of GitLab is, chances are the company
behind it will sooner or later be bought by another company - and then
anything can happen.
The code behind SourceForge was also at some point made available under
an open source licence, and forks being used in instances like Debian
Alioth ended up being unmaintainable dead ends long-term.
Berkeley DB would be an example where the company behind the software
was bought by another company, and now there are plenty of CVEs that
are unfixable due to changed licencing.
Is there anyone capable and willing to continue open source maintainance
of the GitLab open source sources if the company behind it would stop
the open source releases tomorrow?
With projects like GNOME using GitLab the answer might be "yes",
but this should be evaluated before moving infrastructure to GitLab.
> Paul Barker
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
next prev parent reply other threads:[~2019-11-06 21:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-06 16:01 Using GitLab for OE/Yocto layers Paul Barker
2019-11-06 21:41 ` Adrian Bunk [this message]
2019-11-06 21:41 ` Adrian Bunk
2019-11-07 9:15 ` Ross Burton
2019-11-22 21:29 ` [yocto] " Paul Barker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191106214108.GC14721@localhost \
--to=bunk@stusta.de \
--cc=openembedded-architecture@lists.openembedded.org \
--cc=openembedded-devel@lists.openembedded.org \
--cc=paul@betafive.co.uk \
--cc=yocto@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.