[OpenPower-Firmware] moving op-build dev from master-next to master

[Stewart Smith]

Patrick Williams <patrick at stwcx.xyz> writes:
> On Wed, Jan 11, 2017 at 05:03:15PM +1100, Stewart Smith wrote:
>> Hi all,
>> 
>> Currently, all new development work goes into op-build master-next
>> branch before moving to master close to the time where we tag a release.
>> 
>> This is rather different to literally every other project that uses git.
>
> 'man gitworkflows' says:
>
>        * next is intended as a testing branch for topics being tested
>          for stability for master.
>
> The sounds to me pretty similar to what we are doing, except maybe the
> longevity of master vs master-next might be longer in our case.

and also that every change goes into master-next, rather than only
things which may cause instability.

>> It's time we change.
>
> What are we accomplishing with this change?  Is the problem simply a
> matter of names?
>
>> After 1.14 (due Jan 18th), unless there's any strong objections, we'll
>> enact the following:
>> 
>> - pull requests start going to master: it's where development happens.
>> - master-next branch is deleted
>
> We lose out on having a temporary place for stability fixes to be placed
> just before tagging while testing is done.  I hope you are not
> suggesting that we just stop merging code for a week while we sort this
> out.

It's not the worst idea... it does tend to force some concentration as
to what needs to be done before making a release....

but reality gets in the way, so a process that keeps master open and
branches for release probably fits in a bit better with what people
expect.

> Do we simply need to change 'master' to 'release' and 'master-next' to
> 'master' to make you happy?  There is value in having 'master' and
> 'master-next' be fairly similar.  Usually after tagging, I'll merge any
> 'master' stability fixes into 'master-next' so that git-describe on
> 'master-next' is still of a form representing the most recent tag.

That would solve the biggest issue.

It would also open the namespace of 'next' up to a branch that is a lot
more experimental - bringing top of tree linux, buildroot, skiboot into
something that could be built+testing to find problems much more in
advance than when we currently do.

>> - a vendor doing a release should branch off the most recent tagged
>>   release.
>
> How is this different from what is being done today?

Some *may* be just checking out master rather than looking for a tag. Of
course, that could currently be broken and they could grab something
only *nearly* ready for release.

>> - stable branches, like v1.10.y will continue as-is
>
> Have we observed any uptake of these?  Is the real value in doing this
> or is it just needless work?  I know we've only been doing them for a
> short time.

We've been using them for our service packs for some IBM machines, and
it's been working well. There hasn't really been an opportunity to get
other vendors to use it, simply due to schedules and what features they
were shipping with.

> There are also tools we need to get changed over.  I do not think tying
> to a particular release is required other than maybe it gives you a nice
> place to announce it.  I suspect, with the Power9 bring up activities
> going on, it may be difficult to get the tools moved over in time for
> v1.14.

Yeah, I was being optimistic with 1.14... but we have a 1.15, and that
could be the target - I'm not tooo concerned about the absolute release
where things are done, but in Q1 this year would be good, all ready for
p9 process.

-- 
Stewart Smith
OPAL Architect, IBM.