<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Some remarks from my side as well.</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
The maintenance part of GitLab shouldn't be underestimated here.</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
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.</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
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.</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Nevertheless, I fully support the idea of this "experiment".</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Especially using pull requests and a more or less intuitive review process for the designated target branch, should be worth the risk<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Von:</b> openembedded-architecture-bounces@lists.openembedded.org <openembedded-architecture-bounces@lists.openembedded.org> im Auftrag von Adrian Bunk
<bunk@stusta.de><br>
<b>Gesendet:</b> Mittwoch, 6. November 2019 22:41<br>
<b>An:</b> paul barker <paul@betafive.co.uk><br>
<b>Cc:</b> yocto discussion list <yocto@yoctoproject.org>; oe architecture <openembedded-architecture@lists.openembedded.org>; oe devel <openembedded-devel@lists.openembedded.org><br>
<b>Betreff:</b> Re: [Openembedded-architecture] [yocto] Using GitLab for OE/Yocto layers</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">On Wed, Nov 06, 2019 at 04:01:03PM +0000, Paul Barker wrote:<br>
>...<br>
> At the risk of bikeshedding I'd like to get some feedback on these ideas at this stage. Have I missed any advantages/disadvantages?<br>
>...<br>
<br>
Three comments from me:<br>
<br>
<br>
1. Patch review<br>
<br>
Merge requests work well when there is one maintainer who reviews <br>
everything. For not regressing on the current level of review before<br>
something hits master, merging a merge request into master-next<br>
should then result in patch review emails sent to a list.<br>
Or a setup where creation of a merge request automatically generates<br>
review emails.<br>
<br>
This is similar to all patches for stable branches now being sent for <br>
review to the mailing list a few days before they get merged into the <br>
stable branch, which has caught problematic patches due to more people <br>
reviewing them.<br>
<br>
<br>
2. Maintaining an own GitLab instance<br>
<br>
This was mentioned as an option. Expect upgrades to new GitLab releases <br>
once per month, which is work and as with all software never without <br>
regression risk.<br>
<br>
Not a dealbreaker, but has to be resourced.<br>
<br>
<br>
3. Long-term suistainability<br>
<br>
Whatever the past track record of GitLab is, chances are the company <br>
behind it will sooner or later be bought by another company - and then <br>
anything can happen.<br>
<br>
The code behind SourceForge was also at some point made available under<br>
an open source licence, and forks being used in instances like Debian<br>
Alioth ended up being unmaintainable dead ends long-term.<br>
<br>
Berkeley DB would be an example where the company behind the software <br>
was bought by another company, and now there are plenty of CVEs that<br>
are unfixable due to changed licencing.<br>
<br>
Is there anyone capable and willing to continue open source maintainance <br>
of the GitLab open source sources if the company behind it would stop <br>
the open source releases tomorrow?<br>
<br>
With projects like GNOME using GitLab the answer might be "yes",<br>
but this should be evaluated before moving infrastructure to GitLab.<br>
<br>
<br>
> Paul Barker<br>
<br>
cu<br>
Adrian<br>
<br>
-- <br>
<br>
"Is there not promise of rain?" Ling Tan asked suddenly out<br>
of the darkness. There had been need of rain for many days.<br>
"Only a promise," Lao Er said.<br>
Pearl S. Buck - Dragon Seed<br>
<br>
_______________________________________________<br>
Openembedded-architecture mailing list<br>
Openembedded-architecture@lists.openembedded.org<br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-architecture">http://lists.openembedded.org/mailman/listinfo/openembedded-architecture</a><br>
</div>
</span></font></div>
<FONT face="Calibri"><FONT face="Calibri">
<P dir="ltr">.......................................................................................</P>
<P dir="ltr">PHOENIX CONTACT Cyber Security GmbH </P>
<P dir="ltr">Richard-Willstätter-Straße 6 </P>
<P dir="ltr">D-12489 Berlin </P>
<P dir="ltr"> </P>
<P dir="ltr">Register Court: AG Charlottenburg, HR B 202908 </P>
<P>Geschäftsführer/General Manager: Kilian Golm</P></FONT></FONT><I><FONT face="Calibri"></I></FONT></body>
</html>