Re: [yocto] Using GitLab for OE/Yocto layers

2019-11-07 Thread Ross Burton 

On 06/11/2019 21:41, Adrian Bunk wrote:

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.


I've had discussions about this in the past too.  With merge requests it 
seems reasonable to automatically tag in relevant maintainers when the 
request is created to request review.  For example if oe-core was on 
GitLab then a MR touching GCC would automatically assign to Khem.


I agree that drive-by review is an important part for a core layer such 
as oe-core where a single maintainer can't know all of the details, so 
the ability to post at least new merge requests - and ideally all 
traffic - to a list for this is essential.


Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Using GitLab for OE/Yocto layers

2019-11-06 Thread Adrian Bunk 
On Wed, Nov 06, 2019 at 04:01:03PM +, 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

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto