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 at fuzziesquirrel.com> wrote:
>
>> On May 21, 2018, at 1:07 PM, krtaylor <kurt.r.taylor at 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)