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 11-18-2008, 08:22 PM
Luke Macken
 
Default Proposal - "Slow updates" repo

On Tue, Nov 18, 2008 at 01:53:37PM -0500, Casey Dahlin wrote:
> There's been a lot of talk about a stable release lately. Most agree
> that its not what Fedora does best and not something that would be
> natural for us to do. I have a sort of middle-ground proposal that might
> be easy enough to implement that we could try it out.
>
> Currently, when a packager has an update, he runs "make update," and
> bodhi goes and grabs the package out of koji and places it in the next
> mash of the updates-testing repo (Luke, please shout when I start
> getting this wrong). Then, bold subscribers to updates-testing install
> it, check it out, and if two people report in that it didn't eat their
> brane, it goes into the regular updates repo. That slim sanity check
> prevents a whole helluva lot of breakage, but isn't a very broad testing
> of the package.

Nope, the karma thresholds are completely configurable, and it defaults
to 3. Yes, I agree that this is not a sufficient enough metric to
ensure that a package will not break anything.

> What I propose is having another repo called updates-slow. Like updates
> testing this repo ships with Fedora but is disabled and hidden by
> default. Interested parties would have to manually enable it, and
> disable the regular updates repo. updates-slow would relate to updates
> in a similar way that updates relates to updates-testing: packages would
> go into it after people getting the general Fedora updates seem to be
> ok. The criteria here would have to be much harder than the two karma
> points it takes to move out of testing, I would suggest the people
> interested in this feature form a group that decides what the entry
> policy should be.
>
> The advantage is that this is fairly cheap to set up. Bodhi would need
> some level of changes (Luke, what do you think?) but there's no
> branching. We're basically just taking the ability which already exists
> in yum to selectively take updates and providing a system to
> collaboratively exploit this mechanism.

>From a bodhi perspective, I think it would be a minimally invasive
procedure. It is currently written so that every release has a
Release.dist_tag + '-updates-testing' repo as well. So, aside from a new koji
tag and mash config, and whatever interface changes the slowrepo policy
requires, it doesn't sound very difficult to implement.

However, all of this hinges on a policy that has yet to be created. I
agree with you that we need an improved updates testing policy. I don't
think we need a new SIG to provide it, as it sounds like a job for the
QA team.

> Not branching, however, also creates a disadvantage: with no ability to
> create new packages, the slow repo can't take newer fixes without taking
> an entire update. The slow repo must consume updates from Fedora in
> whole packages; they don't have patch-level control over incoming
> changes. Also, the slow repo has to synchronize at release time; you
> can't have a late-F9-with-bits-of-F10 offering (hopefully though the
> base set is the peak of mainline Fedora's QA).
>
> If the people interested in a stability feature are willing to help
> govern and maintain this repo, and help with the bug load (we can't just
> dump bugs against backdated versions directly on the maintainers), then
> it could go a long way to meeting their needs.
>
> Thoughts?

I'm not quite sure that yet-another-repo will solve the actual problem at
hand, which is: we constantly break things in our stable releases.

Bodhi's karma system provides a very basic community-driven workflow for
"testing" updates. The problem is that this "testing" is ambiguous,
unpredictable, and not documented.

Ok, so lets step back and figure out how we are actually breaking stuff.

- Packaging issues. Broken deps, %post, etc.
- Bugs from new code in 'enhancement' updates.
- Infrastructure->client-tool breakage
Bugs in infrastructure causing issues in the repos that the clients
consume, causing bugs in their tools. (Bug #471873 is a good example)
- ...

So, how do we minimize that breakage?

- Automated package sanity-checking.
http://fedoraproject.org/wiki/QA/Beaker looks like it was the
closest to solving that problem, but that initiative looks like it
has since fizzled out.
- Ensure that new features are tested, by humans and ideally a test suite.
- Infrastructure bugs tend to decrease over time by nature, so we
just need more developers to help out.
- Having all upstream projects maintain a stable bugfix-only release
would be great, but it's not going to happen. Thus, we need to do
the dirty work.

Once those issues are addressed, then it's a matter of letting our users
choose if they want 'incremental features' or 'a rock-solid slow
moving system'. If we wanted to granularize our update repositories
even more, we could potentially make our 'stable' repository bug & security
fix only, and have a separate repo for new packages and enhancements....

luke

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-19-2008, 08:08 AM
Kevin Kofler
 
Default Proposal - "Slow updates" repo

Seth Vidal wrote:
> you mean like the already existing yum security plugin and the update info
> that bodhi generates?

Except it just doesn't work... 2 big problems there:
1. Security updates can be obsoleted by non-security updates. So if you
didn't install the security update in time, you'll never get it.
2. Sometimes security updates cause regressions. Usually these are fixed
very quickly... in a regular bugfix update. With the result that users of
yum-security will be stuck with the regression (or if they didn't update in
time, with situation 1., i.e. without the security update).

To solve 2., fixes for regressions from security updates would have to be
marked security as well, or (probably better) use a new category ("bugfix
for security update") which is also pulled in by yum-security.

To solve 1., the metadata would have to carry the information for the
security update even after it is obsoleted, and yum-security would have to
understand that if foo-1.2.3 is a security update, the currently installed
package is foo-1.2.2 and the current version in the repo is the bugfix
update foo-1.2.4, it should install foo-1.2.4. Or alternatively, the latest
security (or "bugfix for security", see above) update would have to be
carried in the repos in addition to the latest overall.

In its current state, yum-security is very unreliable and outright
dangerous.

An additional issue is that updates are rarely tested in isolation. Usually,
packagers and testers are up to date with all their packages. And it
happens quite a few times that an update to one package uncovers a bug in
another package, which is then (or ideally, at the same time, using a
grouped update) fixed by an update to that other package. (For example, K3b
crashed after a KDE 3.4->3.5 upgrade and needed to be updated, likewise for
KTorrent and KDE 4.0->4.1. KDE upgrades are normally backwards-compatible
(and thus the soname mechanism won't drag in application updates), but
sometimes they trigger bugs in individual applications. But there are many
examples of this problem outside of KDE as well.) This is why all RHL
updates used to carry the following notice:
> Before applying this update, make sure all previously released errata
> relevant to your system have been applied.
which is still sound advice.

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-19-2008, 09:20 AM
"Mat Booth"
 
Default Proposal - "Slow updates" repo

On Tue, Nov 18, 2008 at 9:22 PM, Luke Macken <lmacken@redhat.com> wrote:
> So, how do we minimize that breakage?
>
> - Ensure that new features are tested, by humans and ideally a test suite.

I have a brief test plan for some of my packages on my wiki page:
https://fedoraproject.org/wiki/User:Mbooth#Package_Maintenance

Although it's more of a personal /aide memoire/ rather than actual
test procedure, I'm sure it would also be useful to others who are
interested in testing my packages. It only takes a few minutes to go
through and if any of the things on that list do not work, I consider
it a bug. :-)

Would it be useful to mandate that maintainers provide a similar test
plan for all packages going through updates-testing in order to make
sure all the features are covered?

--
Mat Booth
www.matbooth.co.uk

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-19-2008, 02:08 PM
James Antill
 
Default Proposal - "Slow updates" repo

On Wed, 2008-11-19 at 10:08 +0100, Kevin Kofler wrote:
> Seth Vidal wrote:
> > you mean like the already existing yum security plugin and the update info
> > that bodhi generates?
>
> Except it just doesn't work... 2 big problems there:
> 1. Security updates can be obsoleted by non-security updates. So if you
> didn't install the security update in time, you'll never get it.
> 2. Sometimes security updates cause regressions. Usually these are fixed
> very quickly... in a regular bugfix update. With the result that users of
> yum-security will be stuck with the regression (or if they didn't update in
> time, with situation 1., i.e. without the security update).
>
> To solve 2., fixes for regressions from security updates would have to be
> marked security as well, or (probably better) use a new category ("bugfix
> for security update") which is also pulled in by yum-security.

This seems very dodgy to me, yes in Fedora you are likely to get a
security errata with extra changes ... and sometimes those extra changes
contain bugs. That doesn't mean the bugs are magically different from
normal bugs.
We already have bugfix and enhancement ... and we already have "yum
update --bz 1234", for specific problems. I don't think we need/want to
mangle what a security fix is for this.

> To solve 1., the metadata would have to carry the information for the
> security update even after it is obsoleted, and

Yes, at the minimum the updateinfo.xml would have to never remove
security data ... at best each package could also contain the latest
security update.

> yum-security would have to
> understand that if foo-1.2.3 is a security update, the currently installed
> package is foo-1.2.2 and the current version in the repo is the bugfix
> update foo-1.2.4, it should install foo-1.2.4. Or alternatively, the latest
> security (or "bugfix for security", see above) update would have to be
> carried in the repos in addition to the latest overall.

yum-security already does this, and adds a "yum update-minimal" command
so that if you have X-1 installed, X-2 as a security update and X-3 as
an enhancement update "yum update-minimal --security" will move you from
X-1 to X-2.

> In its current state, yum-security is very unreliable and outright
> dangerous.

You are free to hold this opinion, however I've had machines running
"yum --security update" in cron for a long time ... and it has worked
perfectly.

--
James Antill <james@fedoraproject.org>
Fedora

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-19-2008, 02:20 PM
Jesse Keating
 
Default Proposal - "Slow updates" repo

On Wed, 2008-11-19 at 10:08 +0100, Kevin Kofler wrote:
>
> To solve 1., the metadata would have to carry the information for the
> security update even after it is obsoleted, and yum-security would have to
> understand that if foo-1.2.3 is a security update, the currently installed
> package is foo-1.2.2 and the current version in the repo is the bugfix
> update foo-1.2.4, it should install foo-1.2.4. Or alternatively, the latest
> security (or "bugfix for security", see above) update would have to be
> carried in the repos in addition to the latest overall.

Another way to solve 1 is to assign unique IDs to security issues (I
think we do that already) and have a perpetual list per package of
security issues that the packages resolve, regardless of the current
update reason. This way the security plugin could check to see if the
version of the package they have already resolves the listed issues, and
if it doesn't, pull down whatever is there. If it does, ignore the
update.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-19-2008, 03:26 PM
Luke Macken
 
Default Proposal - "Slow updates" repo

On Wed, Nov 19, 2008 at 10:08:09AM -0500, James Antill wrote:
> On Wed, 2008-11-19 at 10:08 +0100, Kevin Kofler wrote:
> > Seth Vidal wrote:
> > > you mean like the already existing yum security plugin and the update info
> > > that bodhi generates?
> >
> > Except it just doesn't work... 2 big problems there:
> > 1. Security updates can be obsoleted by non-security updates. So if you
> > didn't install the security update in time, you'll never get it.
> > 2. Sometimes security updates cause regressions. Usually these are fixed
> > very quickly... in a regular bugfix update. With the result that users of
> > yum-security will be stuck with the regression (or if they didn't update in
> > time, with situation 1., i.e. without the security update).
> >
> > To solve 2., fixes for regressions from security updates would have to be
> > marked security as well, or (probably better) use a new category ("bugfix
> > for security update") which is also pulled in by yum-security.
>
> This seems very dodgy to me, yes in Fedora you are likely to get a
> security errata with extra changes ... and sometimes those extra changes
> contain bugs. That doesn't mean the bugs are magically different from
> normal bugs.
> We already have bugfix and enhancement ... and we already have "yum
> update --bz 1234", for specific problems. I don't think we need/want to
> mangle what a security fix is for this.
>
> > To solve 1., the metadata would have to carry the information for the
> > security update even after it is obsoleted, and
>
> Yes, at the minimum the updateinfo.xml would have to never remove
> security data ... at best each package could also contain the latest
> security update.

https://fedorahosted.org/bodhi/ticket/259


luke

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-19-2008, 03:40 PM
Luke Macken
 
Default Proposal - "Slow updates" repo

On Wed, Nov 19, 2008 at 10:20:12AM +0000, Mat Booth wrote:
> On Tue, Nov 18, 2008 at 9:22 PM, Luke Macken <lmacken@redhat.com> wrote:
> > So, how do we minimize that breakage?
> >
> > - Ensure that new features are tested, by humans and ideally a test suite.
>
> I have a brief test plan for some of my packages on my wiki page:
> https://fedoraproject.org/wiki/User:Mbooth#Package_Maintenance
>
> Although it's more of a personal /aide memoire/ rather than actual
> test procedure, I'm sure it would also be useful to others who are
> interested in testing my packages. It only takes a few minutes to go
> through and if any of the things on that list do not work, I consider
> it a bug. :-)
>
> Would it be useful to mandate that maintainers provide a similar test
> plan for all packages going through updates-testing in order to make
> sure all the features are covered?

I think it would be extremely useful. It looks like the QA team has
already started the initiative, but not many people have been helping.

https://fedoraproject.org/wiki/Category:Test_Cases
https://fedoraproject.org/wiki/QA/HowToTestTemplate

luke

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-19-2008, 04:05 PM
"Mat Booth"
 
Default Proposal - "Slow updates" repo

On Wed, Nov 19, 2008 at 4:40 PM, Luke Macken <lmacken@redhat.com> wrote:
> On Wed, Nov 19, 2008 at 10:20:12AM +0000, Mat Booth wrote:
>> I have a brief test plan for some of my packages on my wiki page:
>> https://fedoraproject.org/wiki/User:Mbooth#Package_Maintenance
>>
>> Although it's more of a personal /aide memoire/ rather than actual
>> test procedure, I'm sure it would also be useful to others who are
>> interested in testing my packages. It only takes a few minutes to go
>> through and if any of the things on that list do not work, I consider
>> it a bug. :-)
>>
>> Would it be useful to mandate that maintainers provide a similar test
>> plan for all packages going through updates-testing in order to make
>> sure all the features are covered?
>
> I think it would be extremely useful. It looks like the QA team has
> already started the initiative, but not many people have been helping.
>
> https://fedoraproject.org/wiki/Category:Test_Cases
> https://fedoraproject.org/wiki/QA/HowToTestTemplate
>
> luke
>
> --
> fedora-devel-list mailing list
> fedora-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

I wasn't aware, thanks for the links. I might as well convert my notes
into some proper Eclipse/Eclipse-Plugin test cases using their
templates when I get some time.

--
Mat Booth
www.matbooth.co.uk

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-20-2008, 10:34 AM
David Timms
 
Default Proposal - "Slow updates" repo

Douglas E. Warner wrote:
frequently. Perhaps this 3-repo structure would work well for both
groups ("testing", "normal", "stable").

'stable' -> 'glacial' ?

DaveT.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 07:06 PM.

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