[yocto] Supporting upcoming distribution releases

[Joshua Lock]

On Tue, 2011-07-12 at 12:01 -0700, Darren Hart wrote:
> 
> On 07/12/2011 11:51 AM, Joshua Lock wrote:
> > In our technical team call today we spent some time discussing how to
> > support distribution releases that are due to happen around the time of
> > Yocto 1.1.
> > 
> > Yocto 1.1 is scheduled for release on October 6th[1], the same month in
> > which both Ubuntu and Fedora have new releases planned[2,3].
> > OpenSUSE doesn't have a release scheduled until November 10th[4].
> > 
> > We should accommodate for these releases in our planning around 1.1 as
> > we need to ensure that Yocto 1.1 can be used on the new versions of the
> > chosen supported distros.
> > 
> > I had initially suggested we have people doing test and any relevant
> > development around the beta cycles of Ubuntu and Fedora:
> > 
> > Fedora Beta (2011-09-20)
> > Ubuntu (2011-09-01)
> > In this time frame OpenSUSE will be on Milestone 5 (2011-09-01) which
> > afaict (based on the 6th milestone being followed by an RC) should
> > roughly equate to a beta.
> > 
> > However this aligns with our RC period at which point we may not want to
> > accept large patches?
> > 
> > To meet our stabilise complete goal of August 29th we'd have to have
> > people testing with:
> > Fedora Alpha (2011-08-16)
> > Ubuntu Alpha 3 (2011-08-04)
> > OpenSUSE Milestone 4 (2011-08-11)
> > 
> > What are peoples thoughts on this?
> 
> At the very least a sanity test to know which sorts of issues we'll hit
> with these would be valuable. However, I believe our policy is N-1, and
> not N+1,N,N-1, so supporting not-yet released versions isn't something I
> think we should spend too much time on. Minor fixes to support these
> post release seem like good candidates for a point release.

I understand what you're saying but I think the stance bears further
consideration because our release is so close to that of the
distributions and because so many of our target users will upgrade on
release day (or sooner) I think it's in the interest of the project to
be aware of the issues before release and ideally to have fixed as many
of any issues as possible.

I don't think it likely we will spin a point release in time to have
something that works on the distro launch day if we take the approach
you're advocating.

If people think this isn't a big deal I can live with that, but
experience suggests we will field support enquiries about these things
and therefore to my mind it seems prudent to accommodate for that.

> > I think the onus for this testing
> > will fall on engineers as the project QA is already pretty stretched. I
> > have a tendency to update to early releases on at least one machine so
> > will no doubt do some testing on Fedora but it would be nice to have a
> > genuine strategy for this rather than relying on ad-hoc developer
> > upgrades.
> 
> 
> I personally do not upgrade my primary development machine to
> pre-release distributions because I don't want those issues to derail me
> from working on features. However, I could certainly kick off VMs
> running whatever and set them building on one of our larger servers.

Absolutely. I'm not meaning to suggest all our developers should run
unstable OS's.

Aside; the schedule has feature development long complete by this
point ;-)

> 
> > 
> > Final note: I'm left wondering if this emails contents also make sense
> > as a wiki page?
> 
> Some sort of distro links for schedule page would be great. If people
> want to share that they are testing the pre-release distros, that would
> be useful, but we need to find a way to keep it concise and not into a
> "getting it to work on XYZ" forum - although that would be useful a
> separate page per distro.

Or perhaps we should just integrate this information into our schedule?

Cheers,
Joshua
-- 
Joshua Lock
        Yocto Project "Johannes factotum"
        Intel Open Source Technology Centre