fedup f20->f21 kde broken deps

[Adam Williamson]

On Thu, 2014-12-04 at 15:28 +0100, Michael Schwendt wrote:

> If it happens _before_ release of F21, it leads to bad experience from
> people who want to evaluate F21 early and find that a fresh install is
> the only option whereas an upgrade of a older dist runs into broken deps.

It seems like you're expecting a post-release quality experience for
people testing pre-releases. That's just not practical, or we'd be a
rolling distro. Building a distro isn't easy, there are all sorts of
different scenarios and competing interests to satisfy. To be honest
this feels like an over-simplified over-reaction to a niche case to me:
we don't have to go nuts just because someone saw a dep issue when
trying to run fedup pre-release.

I'd be more convinced by a proposal which had clearly considered the
effects of any policy changes from *all* sides, for all cases, not just
'ahhh someone saw broken deps we need to FIXIT RIGHTNOW', which is what
this feels like.

> > And then Branched goes into milestone
> > freezes. F21 has been frozen for Final since 2014-11-18; are maintainers
> > supposed to not push anything stable in F20 for that whole time even if
> > they have a matching/newer build for F21 which is just waiting on the
> > freeze to be lifted? What if it's a security fix? A showstopper crasher
> > fix? Why punish F20 users?
> 
> Drama time. I already pointed out that security fixes may need special
> treatment. But a "showstopper" so late for F20? Come on! What has gone
> wrong there? Has it crashed since F20 release or because of a poorly
> tested "stable" update? Not mentioning the %{?dist}.N versioning guidelines
> here for old-release bug-fixes. ;-)

It happens. Building software is hard.

> > > Avoid the assumption that an update is "good" for all releases just
> > > because 1-3 people have given an early +1 via bodhi for an older dist
> > > release only.
> > 
> > Um. What assumption is that?
> 
> What kind of question is that?
> Have you not observed any packagers in bodhi, who push to stable
> manually with "0 karma" and >=0 karma for older dist releases?

The updates policy places a degree of trust in maintainers to know what
an appropriate update policy for their packages is. I think that's a
sensible choice for a project like Fedora; I don't trust a body like
FESCo to be able to set a policy nuanced enough to avoid the need for
thought on the part of package maintainers.

We have a page of guidance for packagers submitting updates:

https://fedoraproject.org/wiki/Package_update_HOWTO

that already provides some guidance on the use of karma:

"You may set a karma (feedback) level at which the update will
automatically be submitted to stable. This is optional. If you choose to
use it, please carefully consider an appropriate feedback level. For a
relatively obscure package which is quite stable, 1 or 2 may be an
appropriate value. For a popular, sensitive and complex package such as
Package-x-generic-16.pngfirefox or the Package-x-generic-16.pngkernel,
the default of 3 may be insufficient and a choice of 5 or even 10 may be
appropriate."

if you think there are appropriate adjustments or enhancements to that
page, then go ahead. But Bodhi is essentially a framework that allows
feedback to be gathered. It provides the ability for the project to set
some bare *minimum* requirements, but I don't think from the start we've
worked on the basis that FESCo can write a foolproof updates policy
which avoids the need for maintainers to have a brain and act
appropriately.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net