FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 08-04-2011, 01:53 AM
Kevin Kofler
 
Default RPM version goes backward in Rawhide

Kalev Lember wrote:
> Bumping epoch in rpm would have made it harder for all other packages to
> depend on a particular rpm version. Instead of having e.g.
> Requires: rpm >= 4.9.1, they would now also have to remember the put the
> correct epoch in there.

Indeed, Epoch should be used only as a last resort, it's silly to force its
usage this way!

I think we should go back to requiring monotonically increasing EVRs only
for released versions, not Rawhide.

> I think it's reasonable to have a broken package pulled from rawhide for
> a little while, if it's going to be properly fixed up in a few days.
> Yes, we should try to avoid such things, but having a hard rule here
> would be counter-productive.

+1

At the very least, let's not be anal about enforcing that rule, if we want
it at all!

> Also, we have a much worse case of versions going backwards. After each
> Alpha release, lots of people are going to install Branched pre-releases
> and they automatically get enabled updates-testing repos. And in that
> updates-testing repo, packages are often pulled out and versions go
> backwards. Why is such practice allowed in Branched, but not in rawhide?

Enabling updates-testing by default for Branched was a very stupid decision.
This should be reverted. updates-testing should NEVER be enabled by default.

We should instead focus on getting stuff out to stable faster. In
particular, why not allow direct stable pushes (without any karma) for
branched-but-unreleased versions?

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 08-04-2011, 02:12 AM
Simo Sorce
 
Default RPM version goes backward in Rawhide

On Thu, 2011-08-04 at 03:53 +0200, Kevin Kofler wrote:
> Enabling updates-testing by default for Branched was a very stupid
> decision.
> This should be reverted. updates-testing should NEVER be enabled by
> default.
>
> We should instead focus on getting stuff out to stable faster. In
> particular, why not allow direct stable pushes (without any karma)
> for
> branched-but-unreleased versions?

+1

Simo.

--
Simo Sorce * Red Hat, Inc * New York

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 08-04-2011, 02:14 AM
Adam Williamson
 
Default RPM version goes backward in Rawhide

On Thu, 2011-08-04 at 03:53 +0200, Kevin Kofler wrote:

> > Also, we have a much worse case of versions going backwards. After each
> > Alpha release, lots of people are going to install Branched pre-releases
> > and they automatically get enabled updates-testing repos. And in that
> > updates-testing repo, packages are often pulled out and versions go
> > backwards. Why is such practice allowed in Branched, but not in rawhide?
>
> Enabling updates-testing by default for Branched was a very stupid decision.
> This should be reverted. updates-testing should NEVER be enabled by default.

You don't make any attempt to engage with the reason for it: to ensure
that updates get sufficient testing. I'm surprised you don't like this
decision, since you're forever complaining about updates not getting
karma fast enough. updates-testing is enabled for branched releases
precisely to help updates get tested. If you want the policy to be
changed, you should at least engage with why it is the way it is, and
explain why you think the benefits of not enabling updates-testing by
default in Branched releases (which, to me, seem marginal: it saves
people who run pre-releases and then update to final a bit of trouble)
outweigh the drawbacks (which, in the shape of reduced feedback on
testing updates for Branched releases, could be significant).

> We should instead focus on getting stuff out to stable faster. In
> particular, why not allow direct stable pushes (without any karma) for
> branched-but-unreleased versions?

Could you please stop getting up on this horse at every opportunity,
even in extremely tangentially-related threads? Everyone's aware that
you think this is what should happen. I don't see that you're getting
anywhere just by bringing it up at every possible opportunity.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 08-04-2011, 08:08 AM
Tomas Mraz
 
Default RPM version goes backward in Rawhide

On Wed, 2011-08-03 at 22:12 -0400, Simo Sorce wrote:
> On Thu, 2011-08-04 at 03:53 +0200, Kevin Kofler wrote:
> > Enabling updates-testing by default for Branched was a very stupid
> > decision.
> > This should be reverted. updates-testing should NEVER be enabled by
> > default.
> >
> > We should instead focus on getting stuff out to stable faster. In
> > particular, why not allow direct stable pushes (without any karma)
> > for
> > branched-but-unreleased versions?
>
> +1

+1 from me as well at least up to the beta release. Between beta to pre
release I'd require just 1 karma from non-proventester for critical
path.

--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 08-04-2011, 08:01 PM
Przemek Klosowski
 
Default RPM version goes backward in Rawhide

On 08/03/2011 10:14 PM, Adam Williamson wrote:
> On Thu, 2011-08-04 at 03:53 +0200, Kevin Kofler wrote:

>> We should instead focus on getting stuff out to stable faster. In
>> particular, why not allow direct stable pushes (without any karma) for
>> branched-but-unreleased versions?
>
> Could you please stop getting up on this horse at every opportunity,
> even in extremely tangentially-related threads? Everyone's aware that
> you think this is what should happen. I don't see that you're getting
> anywhere just by bringing it up at every possible opportunity.

He's just doing a Cato: "Ceterum censeo pulsae stabile permitteret sine
karma"
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 08-05-2011, 03:10 AM
Kevin Kofler
 
Default RPM version goes backward in Rawhide

Adam Williamson wrote:
> You don't make any attempt to engage with the reason for it: to ensure
> that updates get sufficient testing.

I kinda did, with the next paragraph (which you are quick to dismiss as off
topic). :-)

People will test the stuff when it's marked stable, and that way they
actually test what will be in the release (or the Alpha or Beta).

> changed, you should at least engage with why it is the way it is, and
> explain why you think the benefits of not enabling updates-testing by
> default in Branched releases (which, to me, seem marginal: it saves
> people who run pre-releases and then update to final a bit of trouble)
> outweigh the drawbacks (which, in the shape of reduced feedback on
> testing updates for Branched releases, could be significant).

1. I don't consider the upgrade path issue "marginal" at all. If people
install our prereleases, they expect to be able to upgrade to the final
release seamlessly. At each release, we get bug reports about "broken
upgrade paths" from Beta to Final which are actually just a result of
updates-testing getting magically disabled (and keeping it enabled wouldn't
be that great a solution either).
2. Updates-testing tends to contain very broken stuff, for which the
maintainer knows it needs more testing before being proven usable (or not).
Enabling it by default makes Branched more unstable than it could be (and in
some cases, even more unstable than Rawhide, as the EVR monotonicity issue
which is the subject of this thread shows).
3. People testing with updates-testing enabled aren't testing what will
actually end up in the releases (Alpha, Beta, Final), which use only
packages marked stable.
4. Updates-testing being enabled by default means that people installing an
Alpha or Beta immediately get fed tons of 0-day (actually negative-day)
updates, because the Alpha or Beta does not include those testing updates by
design. It makes it look quite pointless to work on stabilizing the Beta
when people who installed the Alpha and ran "yum update" are already using
newer packages than those the Beta will ship before the Beta is even being
prepared.
5. People who want to use updates-testing will opt in to it explicitly.
Opting in is easier than opting out because it means upgrading packages
rather than downgrading them.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 08-05-2011, 05:17 AM
Adam Williamson
 
Default RPM version goes backward in Rawhide

On Fri, 2011-08-05 at 05:10 +0200, Kevin Kofler wrote:
> Adam Williamson wrote:
> > You don't make any attempt to engage with the reason for it: to ensure
> > that updates get sufficient testing.
>
> I kinda did, with the next paragraph (which you are quick to dismiss as off
> topic). :-)
>
> People will test the stuff when it's marked stable, and that way they
> actually test what will be in the release (or the Alpha or Beta).

That's ass backwards, though. We need the testing _to determine if the
things should be in the release_. Really, I think if you look at the
quality of the releases that have happened since this policy was
changed, it's pretty clear that it helps. It makes pulling together the
pre-releases a lot less chaotic.

> > changed, you should at least engage with why it is the way it is, and
> > explain why you think the benefits of not enabling updates-testing by
> > default in Branched releases (which, to me, seem marginal: it saves
> > people who run pre-releases and then update to final a bit of trouble)
> > outweigh the drawbacks (which, in the shape of reduced feedback on
> > testing updates for Branched releases, could be significant).
>
> 1. I don't consider the upgrade path issue "marginal" at all. If people
> install our prereleases, they expect to be able to upgrade to the final
> release seamlessly.

We're very clear about what you get to expect with pre-releases, and
being able to upgrade to the final release seamlessly certainly isn't
one of those things.

> At each release, we get bug reports about "broken
> upgrade paths" from Beta to Final which are actually just a result of
> updates-testing getting magically disabled (and keeping it enabled wouldn't
> be that great a solution either).

Sure. I don't see that as a huge issue. We explain why it happens and
provide the solution - distro-sync - and people are generally fine with
that. I haven't seen anyone who thought it was a terrible idea yet.

> 2. Updates-testing tends to contain very broken stuff, for which the
> maintainer knows it needs more testing before being proven usable (or not).

One, that's certainly not how updates-testing is supposed to work, and
two, I dispute that it's the case in practice. Could you point to an
example?

> Enabling it by default makes Branched more unstable than it could be (and in
> some cases, even more unstable than Rawhide, as the EVR monotonicity issue
> which is the subject of this thread shows).

Erm, the update in this thread happened in Rawhide; F16 was not branched
at the time. If F16 had been branched, the update would never have made
it out of updates-testing, hence much less of a problem. Making it less
likely that we'll have to do reversions / epoch bumps is one of the
*strengths* of the updates-testing system.

> 3. People testing with updates-testing enabled aren't testing what will
> actually end up in the releases (Alpha, Beta, Final), which use only
> packages marked stable.

Sure. But their testing enables us to make good decisions about what
*should* go into the release. I don't see where this is a problem.

> 4. Updates-testing being enabled by default means that people installing an
> Alpha or Beta immediately get fed tons of 0-day (actually negative-day)
> updates, because the Alpha or Beta does not include those testing updates by
> design. It makes it look quite pointless to work on stabilizing the Beta
> when people who installed the Alpha and ran "yum update" are already using
> newer packages than those the Beta will ship before the Beta is even being
> prepared.

It's not at all pointless, because the point of the Alpha / Beta images
is to provide a known-good base. If the Alpha / Beta are broken, you're
pretty screwed. If an update is broken, just re-install from the
known-good base and skip the update.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 08-05-2011, 05:20 AM
Adam Williamson
 
Default RPM version goes backward in Rawhide

On Thu, 2011-08-04 at 22:17 -0700, Adam Williamson wrote:

> > 4. Updates-testing being enabled by default means that people installing an
> > Alpha or Beta immediately get fed tons of 0-day (actually negative-day)
> > updates, because the Alpha or Beta does not include those testing updates by
> > design. It makes it look quite pointless to work on stabilizing the Beta
> > when people who installed the Alpha and ran "yum update" are already using
> > newer packages than those the Beta will ship before the Beta is even being
> > prepared.
>
> It's not at all pointless, because the point of the Alpha / Beta images
> is to provide a known-good base. If the Alpha / Beta are broken, you're
> pretty screwed. If an update is broken, just re-install from the
> known-good base and skip the update.

Oh, and this wouldn't be any different if we changed the policy anyway,
because we'd still need to freeze to have any chance of building a
usable Alpha or Beta release. So either no-one would get to do any work
during the freeze unless it fixed a blocker/NTH issue, or we'd build the
Alpha / Beta from the 'release' repo and not include packages in the
'update' repo, which would lead to exactly the same thing: after
installing Alpha you'd have a ton of 0-day packages in updates which
wouldn't have been tested as part of Alpha validation.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 08-20-2011, 03:41 AM
Kevin Kofler
 
Default RPM version goes backward in Rawhide

Looks like I forgot to reply to this:

Adam Williamson wrote:
> That's ass backwards, though. We need the testing _to determine if the
> things should be in the release_. Really, I think if you look at the
> quality of the releases that have happened since this policy was
> changed, it's pretty clear that it helps. It makes pulling together the
> pre-releases a lot less chaotic.

I'm not convinced… Our previous releases were quite good too!

> We're very clear about what you get to expect with pre-releases, and
> being able to upgrade to the final release seamlessly certainly isn't
> one of those things.

And I think this is both extremely unhelpful and a total disconnect from
user expectations.

> Sure. I don't see that as a huge issue. We explain why it happens and
> provide the solution - distro-sync - and people are generally fine with
> that. I haven't seen anyone who thought it was a terrible idea yet.

Well, now you've seen one. :-)

(And the solution I actually give is: "Try 'yum distro-sync' this time, and
next time you install a prerelease, you'll probably want to make sure you
disable updates-testing before doing anything else, in particular before
installing ANY update…")

> > 2. Updates-testing tends to contain very broken stuff, for which the
> > maintainer knows it needs more testing before being proven usable (or
> > not).
>
> One, that's certainly not how updates-testing is supposed to work, and

What is it for then, if not for testing things to see whether they work or
not? That really SHOULD be how updates-testing SHOULD work. If the
maintainer knows that an update works, it should be in stable, not testing
(which also means the maintainer should be the one making that decision, not
some arbitrary policy…).

> two, I dispute that it's the case in practice. Could you point to an
> example?

For how updates-testing works out in practice, just look at any package with
negative karma. Now, there's some probability that it's one of those
packages where the karma system just didn't work (you cannot just sum all +1
and -1 comments and expect it to sum to something meaningful, building
automatically enforced policies out of this totally arbitrary number just
makes no sense), but still, in many cases, the negative karma is there for a
good reason.

>> Enabling it by default makes Branched more unstable than it could be (and
>> in some cases, even more unstable than Rawhide, as the EVR monotonicity
>> issue which is the subject of this thread shows).
>
> Erm, the update in this thread happened in Rawhide; F16 was not branched
> at the time. If F16 had been branched, the update would never have made
> it out of updates-testing, hence much less of a problem.

Except that updates-testing is enabled by default! Which, incidentally, is
exactly what I'm complaining about.

I think you're missing my point:

> Making it less likely that we'll have to do reversions / epoch bumps is
> one of the *strengths* of the updates-testing system.

Only for those users NOT using updates-testing.

Updates can be pulled out of updates-testing at any moment, which makes a
lot of sense, but which means that users with updates-testing enabled will
end up with the EVR going backwards, something that's not even allowed in
Rawhide.

Enabling updates-testing by default means forcing EVR downgrades on users of
Branched by default, making the policy banning them in Rawhide totally
pointless.

>> 3. People testing with updates-testing enabled aren't testing what will
>> actually end up in the releases (Alpha, Beta, Final), which use only
>> packages marked stable.
>
> Sure. But their testing enables us to make good decisions about what
> *should* go into the release. I don't see where this is a problem.

The problem is that basically nobody is testing the actual release package
set, considering that it's much less straightforward to opt out of updates-
testing than to opt in, and that probably only few people are doing it (and
those who do bother to explicitly opt out of updates-testing are the ones
who just need early access to the releases for whatever reason, e.g. because
they need a newer version of some package, and don't actually want to do any
testing whatsoever, just to seamlessly move on to the release when it's out
officially).

> It's not at all pointless, because the point of the Alpha / Beta images
> is to provide a known-good base. If the Alpha / Beta are broken, you're
> pretty screwed. If an update is broken, just re-install from the
> known-good base and skip the update.

LOL, good luck finding the offending update among the dozens of packages
which will get upgraded in your first update after installing the Alpha or
Beta.

> Oh, and this wouldn't be any different if we changed the policy anyway,

Not true:

Consider the following sets of updates:
* Set A of updates goes stable before the freeze.
* Set B of updates goes to testing before the freeze, gets queued for stable
during the freeze and pushed right after the unfreeze.
* Set C of updates goes to testing during the freeze, gets queued for stable
during the freeze and pushed right after the unfreeze.
* Set D of updates goes to testing during the freeze (or right after the
unfreeze, in the same push where sets B and C go stable) and gets queued for
and pushed to stable only well after the unfreeze.
* Set E of updates goes to testing well after the unfreeze.

The compose obviously includes only update set A.

Assume we are right after the unfreeze:
* Update sets A, B and C are stable.
* Update set D is in updates-testing.
* Update set E is not queued anywhere yet (probably not even built yet).

Current: The user will get offered update sets B, C and D as updates.
Proposed: The user will get offered only update sets B and C as updates.

This would reduce the number of 0-day updates for Alpha/Beta releases
significantly.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 08-20-2011, 06:15 AM
Garrett Holmstrom
 
Default RPM version goes backward in Rawhide

On 2011-08-19 20:41, Kevin Kofler wrote:
> Updates can be pulled out of updates-testing at any moment, which makes a
> lot of sense, but which means that users with updates-testing enabled will
> end up with the EVR going backwards, something that's not even allowed in
> Rawhide.
>
> Enabling updates-testing by default means forcing EVR downgrades on users of
> Branched by default, making the policy banning them in Rawhide totally
> pointless.

> The problem is that basically nobody is testing the actual release package
> set, considering that it's much less straightforward to opt out of updates-
> testing than to opt in, and that probably only few people are doing it (and
> those who do bother to explicitly opt out of updates-testing are the ones
> who just need early access to the releases for whatever reason, e.g. because
> they need a newer version of some package, and don't actually want to do any
> testing whatsoever, just to seamlessly move on to the release when it's out
> officially).

FESCo discussed both of these issues before the release of the Fedora 15
Alpha at its meetings on 16 Feb 2011 and 2 Mar 2011. The current
recommendation [1] is to run ``yum distro-sync' after upgrading from
pre-releases to the final release.

[1]
https://fedoraproject.org/wiki/Upgrading_from_pre-release_to_final#After_updating_to_final.2C_why_do es_yum_complain_about_mismatched_package_versions_ even_though_my_rawhide_repo_is_disabled.3F
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 01:18 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org