[OE-core] Yocto Project 1.2 Release Status

[Chris Larson]

On Wed, Apr 18, 2012 at 10:02 AM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Wed, 2012-04-18 at 09:22 -0700, Chris Larson wrote:
>> On Wed, Apr 18, 2012 at 8:20 AM, Richard Purdie
>> <richard.purdie at linuxfoundation.org> wrote:
>> > On Wed, 2012-04-18 at 16:53 +0200, Martin Jansa wrote:
>> >> On Wed, Apr 18, 2012 at 03:47:47PM +0100, Richard Purdie wrote:
>> >> > I thought I'd update everyone with the current 1.2 status.
>> >> >
>> >> > I'm going to branch master for release at this point. We've fixed a lot
>> >> > of issues, I'm hoping the -rc4 build will be a good one. There are signs
>> >> > there are some more minor issues around and bugs do keep getting opened.
>> >> > These are still being investigated so we'll continue to let that happen.
>> >> > Once we have a QA report for -rc4, we'll be in a better position to make
>> >> > a call on how things are looking.
>> >>
>> >> Does it mean that after creating branch, master will be open for
>> >> postponed patches from ML and master-next or do you want to keep master
>> >> as close to release branch as possible for some time (e.g. for those
>> >> 1.2.1 fixes)?
>> >
>> > I have hoped people would work more on the stabilisation and testing but
>> > I don't think I'll be able to hold off the pressure to start master
>> > rolling again at some point relatively soon.
>>
>> Just because people have things to push or are pushing things which
>> aren't bugfixes doesn't mean their time is being taken up by anything
>> but stabilization right now. Your statement implies that everything
>> being pushed is being currently worked on, which is incorrect. I'm
>> sure Mentor isn't the only company with a backlog of already complete
>> local changes to get upstream..
>
> So you're saying Mentor has been working on stabilization and has a
> queue of bugfixes which they've not shared?

No, I never said they were just bugfixes. If they were low impact
bugfixes, they'd have a shot at making it into the release, especially
if they're critical, no?

> This doesn't help us much with the quality of this release :/ At least
> the next one might benefit I guess assuming you can resolve that backlog
> problem...

Imagining that every company is going to never have changes that are
not yet upstream is a pipe dream. There's often a delay due to time
constraints and scheduling. Welcome to the real world.
-- 
Christopher Larson