master branch and stabilisation

master branch and stabilisation

[Richard Purdie]

We're trying to focus on getting a good 2.5 release. We've had around
80 upgrades to recipes on the list after the freeze and basically the
maintainers like Ross and myself are damned if we do and damned if we
don't.

I usually try and ignore them at this point in a release. This then
upsets people as they don't get feedback and makes my life horrible
when I eventually try and round them up.

Instead I've tried pulling them into master-next. So far so good but I
thought I'd better see how much of a mess the branch is in. Conclusion
is at least 3 different failures, some of which I can't even easily
figure out the patch causing it.

So I now get to spend my time trying to figure out which patch broke
what so I can report back on it and make the branch build again by
dropping the broken patches.

This means I'm trying to do full on day to day development as usual as
well as trying to sort release issues like the imminent fedora28 issue
I should be paying attention to instead.

So, a question, what do people want me to do?

Cheers,

Richard

Re: master branch and stabilisation

[Alexander Kanavin]

On 04/05/2018 08:05 PM, Richard Purdie wrote:
> So I now get to spend my time trying to figure out which patch broke
> what so I can report back on it and make the branch build again by
> dropping the broken patches.
> 
> This means I'm trying to do full on day to day development as usual as
> well as trying to sort release issues like the imminent fedora28 issue
> I should be paying attention to instead.
> 
> So, a question, what do people want me to do?

You can file bugs with master-next failures and assign them to me, 
without looking at the failed logs at all. Multitasking is stressful for 
the brain, much better to do things one after the other than switch 
context. And I'm not particularly time crunched now.

We should probably more strictly enforce the freeze - just reject the 
patches and ask to rebase and re-send after a specific date.

Alex

Re: master branch and stabilisation

[akuster808]

On 04/05/2018 10:05 AM, Richard Purdie wrote:
> We're trying to focus on getting a good 2.5 release. We've had around
> 80 upgrades to recipes on the list after the freeze and basically the
> maintainers like Ross and myself are damned if we do and damned if we
> don't.
>
> I usually try and ignore them at this point in a release. This then
> upsets people as they don't get feedback and makes my life horrible
> when I eventually try and round them up.
>
> Instead I've tried pulling them into master-next. So far so good but I
> thought I'd better see how much of a mess the branch is in. Conclusion
> is at least 3 different failures, some of which I can't even easily
> figure out the patch causing it.
>
> So I now get to spend my time trying to figure out which patch broke
> what so I can report back on it and make the branch build again by
> dropping the broken patches.
I will take a look as I have a large set in there.

>
> This means I'm trying to do full on day to day development as usual as
> well as trying to sort release issues like the imminent fedora28 issue
> I should be paying attention to instead.
>
> So, a question, what do people want me to do?
I would rather see you focus on the release.

- Armin
>
> Cheers,
>
> Richard
>

Re: master branch and stabilisation

[Joshua Watt]

On Thu, 2018-04-05 at 18:05 +0100, Richard Purdie wrote:
> We're trying to focus on getting a good 2.5 release. We've had around
> 80 upgrades to recipes on the list after the freeze and basically the
> maintainers like Ross and myself are damned if we do and damned if we
> don't.
> 
> I usually try and ignore them at this point in a release. This then
> upsets people as they don't get feedback and makes my life horrible
> when I eventually try and round them up.
> 
> Instead I've tried pulling them into master-next. So far so good but
> I
> thought I'd better see how much of a mess the branch is in.
> Conclusion
> is at least 3 different failures, some of which I can't even easily
> figure out the patch causing it.
> 
> So I now get to spend my time trying to figure out which patch broke
> what so I can report back on it and make the branch build again by
> dropping the broken patches.
> 
> This means I'm trying to do full on day to day development as usual
> as
> well as trying to sort release issues like the imminent fedora28
> issue
> I should be paying attention to instead.

I've got a build running on in a Ubuntu 16.04 container to try and
reproduce the bug you were seeing with the new uninative. I'll see if I
can get anywhere on that. If nothing else, it will get more data points
and extra testing on the change

> 
> So, a question, what do people want me to do?
> 
> Cheers,
> 
> Richard
>