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

[Patrick Williams]

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
-------------- 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/20200828/90d9ccb4/attachment.sig>