[Openembedded-architecture] [yocto] Using GitLab for OE/Yoctolayers
Konrad Weihmann
kweihmann at phoenixcontact.com
Thu Nov 7 06:58:35 UTC 2019
Some remarks from my side as well.
The maintenance part of GitLab shouldn't be underestimated here.
When using the community edition (as I guess that would be the idea here), we are having round about 2 update cycles each month, just with the GitLab-server itself.
Also the monitoring of the underlying OS is something that is worth mentioning - I don't know if you have some automated monitoring of the OS like Icinga for the other server you're maintaining throughout the project, but this is something I would heavily recommend here, as especially a low disk space scenario could potentially turn into a real show stopper.
Nevertheless, I fully support the idea of this "experiment".
Especially using pull requests and a more or less intuitive review process for the designated target branch, should be worth the risk
________________________________
Von: openembedded-architecture-bounces at lists.openembedded.org <openembedded-architecture-bounces at lists.openembedded.org> im Auftrag von Adrian Bunk <bunk at stusta.de>
Gesendet: Mittwoch, 6. November 2019 22:41
An: paul barker <paul at betafive.co.uk>
Cc: yocto discussion list <yocto at yoctoproject.org>; oe architecture <openembedded-architecture at lists.openembedded.org>; oe devel <openembedded-devel at lists.openembedded.org>
Betreff: Re: [Openembedded-architecture] [yocto] Using GitLab for OE/Yocto layers
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
_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture at lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
.......................................................................................
PHOENIX CONTACT Cyber Security GmbH
Richard-Willstätter-Straße 6
D-12489 Berlin
Register Court: AG Charlottenburg, HR B 202908
Geschäftsführer/General Manager: Kilian Golm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-architecture/attachments/20191107/6e32328d/attachment-0001.html>
More information about the Openembedded-architecture
mailing list