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
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
