Is there any reason or practical value of staying with https://github.com/openbmc/openbmc/tree/2.8.0

[Bruce Mitchell]

Thank you Patrick!

> -----Original Message-----
> From: Patrick Williams [mailto:patrick at stwcx.xyz]
> Sent: Friday, August 28, 2020 05:36
> To: Bruce Mitchell
> Cc: OpenBMC Maillist
> Subject: Re: Is there any reason or practical value of staying with
> https://github.com/openbmc/openbmc/tree/2.8.0
> 
> On Thu, Aug 27, 2020 at 07:27:43PM +0000, Bruce Mitchell wrote:
> > Is there any reason or practical value of staying with
> > https://github.com/openbmc/openbmc/tree/2.8.0
> > vs just using https://github.com/openbmc/openbmc ?
> 
> Hi Bruce,
> 
> I think the answer of if you should use a tag or master entirely depends
> on what you're trying to accomplish.
> 
> If you are developing a new machine, you should do all your
> development work off master.  Working off a tag is only going to cause
> yourself more work because all of your work will have to be rebased in
> order to get merged.
> 
> If you are releasing an image to production or customers, you need to
> decide what your release process looks like and in that case a tag
> _might_ align well with it.
> 
> At Facebook, we strive for CI/CD in all of our codebases.  In general that
> means we "live at HEAD" and try to deploy directly from there.  We do
> not have a need for any long-term maintanence on any particular release
> because we are always releasing a new version anyhow and continuously
> deploying to our fleet.  Therefore, it is very reasonable for us to work off
> master in all cases.
> 
> Previously I worked for a "commercial server" vendor, and fix-releases
> were very important for their customers.  There was an expectation that
> a major release version would get security and other critical fixes for
> years.  In a situation like that, I would certainly recommend starting with
> an OpenBMC tag as the underlying base for your own release.
> 
> In any case of a release, I would expect that your company is taking some
> point-in-time from OpenBMC (master or tag) and then doing some
> qualification on it.  All software has bugs, so you're likely going to find a
> few, and you'll want to backport the fixes into your own 'release branch'.
> Right now, there is not a strong process for qualifying an OpenBMC tag
> and/or backporting fixes onto it (for example to make 2.8.1), so as a
> vendor you are left to do this on your own.  I suspect that this is an area
> where the "commercial vendors" could work together to create a
> stronger release qualification process and it would benefit the
> community as a whole.
> 
> My understanding is that IBM's own release tags are available at [1], so
> maybe someone there can chime in on how they manage these and what
> collaboration they might like.
> 
> You really could start at any random 'master' commit as the underlying
> base for your own release process and with today's process it is probably
> just as bug-full as the current tags.  I would still recommend starting with
> a tag because even today we align those tags with an underlying Yocto
> tag.  The Yocto community has a more well-defined long term support
> process on their tags, so you'll be able to get security fixes in all the
> underlying Yocto packages straight from there.  If you take a random
> commit, you're going to end up being responsible for all of the work with
> Yocto backports.
> 
> Hopefully this helps.
> 
> 1. https://github.com/ibm-openbmc/openbmc/tags
> 
> --
> Patrick Williams