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: [email protected] <[email protected]> im Auftrag von Adrian Bunk <[email protected]> Gesendet: Mittwoch, 6. November 2019 22:41 An: paul barker <[email protected]> Cc: yocto discussion list <[email protected]>; oe architecture <[email protected]>; oe devel <[email protected]> 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 [email protected] 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
_______________________________________________ Openembedded-architecture mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
