U-Boot custodian workflow

U-Boot custodian workflow

[Remy Bohmer]

Hi,

Regarding the Custodian workflow I have a general question: why do we
follow a rebase flow for the custodian trees? If custodians merge master
frequently into their own branches and merge that back on pull requests
would technically work too right?
But there are downsides to it why this is not done like that. Can you give
me a summary of the issues to be faced here?

Kind regards,

Remy

U-Boot custodian workflow

[Tom Rini]

On Fri, May 15, 2020 at 03:40:41PM +0200, Remy Bohmer wrote:

> Hi,
> 
> Regarding the Custodian workflow I have a general question: why do we
> follow a rebase flow for the custodian trees? If custodians merge master
> frequently into their own branches and merge that back on pull requests
> would technically work too right?
> But there are downsides to it why this is not done like that. Can you give
> me a summary of the issues to be faced here?

So, generally, no one should be using the custodian trees unless the
custodian is directing people to test something.  Historically this was
good as part of encouraging vendors to work to get changes in to
mainline.

It also means that when there's something wrong with the PR, those
changes can be fixed and I think that is more valuable than a broken
commit (and then range of bad commits) and then the fix.  Especially
since when this happens it's almost always a build-related issue and not
a run time problem. 

If someone wanted to handle their tree differently and it didn't impact
the rest of my workflow, I wouldn't notice and wouldn't complain.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200518/771eac17/attachment.sig>