2 patch dependency

Patrick Williams patrick at stwcx.xyz
Wed Nov 20 03:54:40 AEDT 2019


On Tue, Nov 19, 2019 at 09:45:34AM -0600, Andrew Geissler wrote:
> 
> I know in general we really try to encourage people to not cause
> co-req issues across repositories. Making this easier for people
> may cause more of it to happen.

I understand and agree.  I don't know how often this kind of breaking
behavior has happened, like these IPMI related changes, it was just
coincidentally at the top of my email queue as I've started digging
through.

> Also, I believe we’re going back to just having everything in
> openbmc/openbmc so that should alleviate a lot of our meta-*
> co-req issues since they can all go in together again. Brad was
> working on getting the gerrit plugin running that allows people
> to maintain sub-directories in a repository. This will allow multiple
> maintainers of openbmc/openbmc for their specific areas.

Ooh.  Was this talked about on the mailing list somewhere?  I've gone
back through at least August and haven't come across it.  Was there
an exploration of moving to `repo` instead?

> So to answer your question, I’m not sure. I think it could still
> be useful to have between code repos and openbmc/openbmc
> at times but I’d rather people just do the extra work to avoid
> dependencies all together.

Another "first step" might be to get a Jenkins job for code repositories
that builds the full openbmc/openbmc stack with the code change, so that
we can identify breaking changes like this before they are merged.
AFAIK, the code repo Jenkins jobs are still independent from the Yocto
recipes, correct?

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20191119/ce155135/attachment.sig>


More information about the openbmc mailing list