Proposal for OpenBMC releases

Proposal for OpenBMC releases

[krtaylor]

In order for us to facilitate all member companies in the OpenBMC work 
planning process, I believe it is important for the project to adopt a 
formal release schedule. Release cycles allow member companies to plan 
on content being delivered, get a read on project priorities, and 
exchange design ideas on the best implementation. As with other 
projects, release dates would be fixed in time. If a feature didn't make 
the release cutoff, then it ships in the next release. This really helps 
drive prioritization of new functionality.

As Brad commented in the community call today, let's start off the 
proposal with aligning with the Yocto project releases plus some time 
for project testing/hardening. Yocto releases are every 6 months, around 
May-October[1], so if we allow for a month of freeze and testing, that 
would be OpenBMC releases every June-November. Since June is next month, 
I'd propose that we start planning now for the November release.

OpenBMC release ? November 2018

Questions:
How do we number releases? do we want to code name them?
Do we want a stable branch/working branch organization?
How long does the project maintain a stable branch? n-1? n-2?
Do we want project milestones for content proposal, code freeze and release?

[1] https://wiki.yoctoproject.org/wiki/Releases

Kurt Taylor (krtaylor)

Re: Proposal for OpenBMC releases

[Brad Bishop]

> On May 21, 2018, at 1:07 PM, krtaylor <kurt.r.taylor@gmail.com> wrote:
> 
> In order for us to facilitate all member companies in the OpenBMC work planning process, I believe it is important for the project to adopt a formal release schedule. Release cycles allow member companies to plan on content being delivered, get a read on project priorities, and exchange design ideas on the best implementation. As with other projects, release dates would be fixed in time. If a feature didn't make the release cutoff, then it ships in the next release. This really helps drive prioritization of new functionality.
> 
> As Brad commented in the community call today, let's start off the proposal with aligning with the Yocto project releases plus some time for project testing/hardening. Yocto releases are every 6 months, around May-October[1], so if we allow for a month of freeze and testing, that would be OpenBMC releases every June-November. Since June is next month, I'd propose that we start planning now for the November release.
> 
> OpenBMC release ? November 2018
> 
> Questions:
> How do we number releases? do we want to code name them?

I would suggest/vote-for adopting Yocto/Poky/OE conventions here…
so 2.3 -> pyro, 2.4 -> rocko, etc.

> Do we want a stable branch/working branch organization?

I would think so.  Again I'd suggest/propose something similar to
Yocto/Poky/OE:

master
master-next
rocko
rocko-next
pyro
pyro-next

Perhaps we could skip the -next branches.

> How long does the project maintain a stable branch? n-1? n-2?

I’m not sure.  My gut reaction was, as many as the community is willing
to write patches against, test, and maintain.

Do you consider N to be master (dev branch) or the most recent release?
If the latter…I’d be happy to start with supporting just N.  We can
see about N-1, N-2 once we get a taste of supporting something other
than just master.

> Do we want project milestones for content proposal, code freeze and release?

Most definitely, IMO.

> 
> [1] https://wiki.yoctoproject.org/wiki/Releases
> 
> Kurt Taylor (krtaylor)

Re: Proposal for OpenBMC releases

[James Mihm]

Releases every six months are a good cadence, and I'm in favor of
starting in November.

I like the idea of naming release such as Yocto. I find that names are
an easier mental map to projects and version.

I don't see the need for the *-next branches, but I'll defer to the
maintainers.

Project support for N (master) and N-1 is a good goal. Anything more
than N-1 should be a downstream product support responsibility.
Anything beyond N-1 will be a challenge for maintainers as time passes.

Milestones are a definite requirement. Having a setup time of 1-month
is a good target, but it should be flexible depending on the
situation.
Where security fixes should be a priority.


On Wed, May 23, 2018 at 4:22 PM, Brad Bishop
<bradleyb@fuzziesquirrel.com> wrote:
>
>> On May 21, 2018, at 1:07 PM, krtaylor <kurt.r.taylor@gmail.com> wrote:
>>
>> In order for us to facilitate all member companies in the OpenBMC work planning process, I believe it is important for the project to adopt a formal release schedule. Release cycles allow member companies to plan on content being delivered, get a read on project priorities, and exchange design ideas on the best implementation. As with other projects, release dates would be fixed in time. If a feature didn't make the release cutoff, then it ships in the next release. This really helps drive prioritization of new functionality.
>>
>> As Brad commented in the community call today, let's start off the proposal with aligning with the Yocto project releases plus some time for project testing/hardening. Yocto releases are every 6 months, around May-October[1], so if we allow for a month of freeze and testing, that would be OpenBMC releases every June-November. Since June is next month, I'd propose that we start planning now for the November release.
>>
>> OpenBMC release ? November 2018
>>
>> Questions:
>> How do we number releases? do we want to code name them?
>
> I would suggest/vote-for adopting Yocto/Poky/OE conventions here…
> so 2.3 -> pyro, 2.4 -> rocko, etc.
>
>> Do we want a stable branch/working branch organization?
>
> I would think so.  Again I'd suggest/propose something similar to
> Yocto/Poky/OE:
>
> master
> master-next
> rocko
> rocko-next
> pyro
> pyro-next
>
> Perhaps we could skip the -next branches.
>
>> How long does the project maintain a stable branch? n-1? n-2?
>
> I’m not sure.  My gut reaction was, as many as the community is willing
> to write patches against, test, and maintain.
>
> Do you consider N to be master (dev branch) or the most recent release?
> If the latter…I’d be happy to start with supporting just N.  We can
> see about N-1, N-2 once we get a taste of supporting something other
> than just master.
>
>> Do we want project milestones for content proposal, code freeze and release?
>
> Most definitely, IMO.
>
>>
>> [1] https://wiki.yoctoproject.org/wiki/Releases
>>
>> Kurt Taylor (krtaylor)