On Thu, 04 Dec 2014 10:18:39 -0800, Adam Williamson wrote:
> It seems like you're expecting a post-release quality experience for
> people testing pre-releases.
Nah, just the possibility to _upgrade_ to F21 pre-release with less risk
of running into broken deps or a clearly violated upgrade path.
> 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.
Upgrade attempts like that have failed for me several times before, too.
And yes, even without updates-testing.
I've returned to waiting for pre-release images for doing fresh installs.
Community support on the mailing-lists isn't as good anymore, so there
wouldn't be any useful interest in collecting data and trying to figure
out what has gone wrong with an upgrade and why the machine doesn't boot.
Same for upgrades to Rawhide, btw. There are some people, who want to make
Rawhide break less often, and there are others, who prefer treating it
like a dumping ground (or who ignore it temporarily, so even Rawhide
is not ahead of the other dist releases always). Of course, there will be
various excuses for that, too, such as wrong expectations about quality
of Rawhide. ;)
> 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.
It's nothing like that, since I'm known as one who doesn't like broken
deps and violated upgrade paths (and the flood of updates, btw, and the
almost daily changes to repo metadata files, which are considered an
annoyance by users - and metadata checksum errors on many mirrors with
Yum desparately trying to find a working mirror). That's not a good
environment for a planned upgrade.
> > > 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.
That's all you add here? Seriously? What happens is that one month later
perhaps the same dist is declared as unsupported and EOL'd. Or what
happens is that developers focus on F21 already and neglect problem
reports about F20 in bugzilla.
> The updates policy places a degree of trust in maintainers to know what
> an appropriate update policy for their packages is.
For mass-updates to multiple dist releases, you need help from an updates
system and an enforced upgradepath check. Or else you could never enable
karma based automatic pushes.
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
