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 12-10-2008, 06:21 PM
Seth Vidal
 
Default Making updates-testing more useful

On Wed, 10 Dec 2008, Josh Boyer wrote:


I think the idea is good. I don't think it helps us to store more
information in PK, though.


Agreed.


If we're going to be storing where a package is installed from. It should
probably be in rpm.


We can't easily do that though, can we? Given that the same binary RPMs
that are in updates-testing today will be in updates tomorrow without
changing...


which is, of course, the problem.

-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-10-2008, 06:44 PM
Les Mikesell
 
Default Making updates-testing more useful

Seth Vidal wrote:




I think the idea is good. I don't think it helps us to store more
information in PK, though.


Agreed.

If we're going to be storing where a package is installed from. It
should

probably be in rpm.


We can't easily do that though, can we? Given that the same binary RPMs
that are in updates-testing today will be in updates tomorrow without
changing...


which is, of course, the problem.


So what is the solution in terms of possibilities for yum? Personally,
I'd like to see a sane way to manage repeatable updates at any level to
at least give an end user a chance to test on a spare machine or VM
exactly what will be propagated in an update to a more critical box. But
even that might not be the right solution where an emergency fix needs
to get pushed immediately.


There has to be some clever way to let the repos change at their own
speed but give the end user control over what updates are installed on
any particular machine by adjusting some sort of 'risk' factor.


--
Les Mikesell
lesmikesell@gmail.com



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-10-2008, 06:45 PM
"Nathanael D. Noblet"
 
Default Making updates-testing more useful

Without being able to know how to solve this problem, let me say as a
enduser with only a small handful of bugs posted. I would more than
likely setup all the machines I administer (~10) to do this if there
seemed to be a quick and easy way to report breakage - and revert it.


I also know a handful of other linux users who have wondered how they
could give back, without getting so immersed in stuff they don't
understand... I told them about karma in bodhi or koji not knowing
exactly where it was, and stated basically: 'I mean you may not know
everything and may not be spending days and days helping, but every
little bit you can give back makes a difference' This would definitely
be an area where I could see more help coming from 'average' users.


--
Nathanael d. Noblet
Gnat Solutions, Inc
T: 403.875.4613

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-10-2008, 06:50 PM
Stefan Held
 
Default Making updates-testing more useful

Am Mittwoch, den 10.12.2008, 12:54 -0600 schrieb Les Mikesell:

> Could there be a way to throw everything in the same repo and give
> the
> user/installer a choice of how 'well-tested' something should be
> before
> installing it? Preferably with a sliding scale instead of just 2
> choices. Normally on new installs and machines used explicitly for
> testing I'd expect people to want the latest changes but become more
> conservative on machines that are working well and used for important
> work. The 'well-tested' concept might have factors for age,
> feedback,
> emergency overrides, etc.
>
> --
> Les Mikesell
> lesmikesell@gmail.com

+1

--

Stefan Held VI has only 2 Modes:
obi unixkiste org The first one is for beeping all the time,
FreeNode: foo_bar the second destroys the text.
---------------------------------------------------------------------------
Fedora Ambassador: http://fedoraproject.org/wiki/StefanHeld
---------------------------------------------------------------------------
perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/'
---------------------------------------------------------------------------


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-10-2008, 07:03 PM
Jesse Keating
 
Default Making updates-testing more useful

On Wed, 2008-12-10 at 12:35 -0500, Matthias Clasen wrote:
> What do you think ?

I could have sworn the bodhi userland client had a report-testable like
function that would tell you all the things on your system that came
from updates-testing. Probably just simply uses a comparison of what's
in your rpmdb vs what's available from updates-testing (maybe even
looking at gpg key?). Luke?

--
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 12-10-2008, 07:08 PM
Jesse Keating
 
Default Making updates-testing more useful

On Wed, 2008-12-10 at 12:54 -0600, Les Mikesell wrote:
>
> Could there be a way to throw everything in the same repo and give the
> user/installer a choice of how 'well-tested' something should be before
> installing it? Preferably with a sliding scale instead of just 2
> choices. Normally on new installs and machines used explicitly for
> testing I'd expect people to want the latest changes but become more
> conservative on machines that are working well and used for important
> work. The 'well-tested' concept might have factors for age, feedback,
> emergency overrides, etc.

Take your sliding scale and multiply the various configurations that
have to be generated/tested by each stop on the scale.

Lets say for instance that we want to do a new xulrunner, very raw.
Every xulrunner dependent app will have to be built for that version and
included. Then what if we want to do a new yelp that is pretty well
tested, but not perfect. Now we have to build one for the well tested
scale stop, and keep the other one (what nvrs to use now?!) at the
untested slot. Oh for fun, lets throw in something else that yelp
depends on, but is not in the xulrunner set, that is very well tested
and stable. Now you've got a yelp for the very well tested stop, a yelp
for the medium stop, a yelp with tons of other stuff at the raw stop for
xulrunner. What NVRs to apply to these, how many different ways can we
assemble packages to test for cohesive deps and upgrade paths, and how
to create a updates system that takes all this into consideration when
poor fred just wants to update his package?

--
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 12-10-2008, 07:23 PM
Robert Locke
 
Default Making updates-testing more useful

On Wed, 2008-12-10 at 12:03 -0800, Jesse Keating wrote:
> On Wed, 2008-12-10 at 12:35 -0500, Matthias Clasen wrote:
> > What do you think ?
>
> I could have sworn the bodhi userland client had a report-testable like
> function that would tell you all the things on your system that came
> from updates-testing. Probably just simply uses a comparison of what's
> in your rpmdb vs what's available from updates-testing (maybe even
> looking at gpg key?). Luke?

We should also probably stop "asking" a user for feedback for a package
which has already moved from updates-testing to updates (in the
intervening days) and that comparison (if not already written) would
help to "drop" the "asking"....

--Rob

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-10-2008, 08:03 PM
Les Mikesell
 
Default Making updates-testing more useful

Jesse Keating wrote:

On Wed, 2008-12-10 at 12:54 -0600, Les Mikesell wrote:
Could there be a way to throw everything in the same repo and give the
user/installer a choice of how 'well-tested' something should be before
installing it? Preferably with a sliding scale instead of just 2
choices. Normally on new installs and machines used explicitly for
testing I'd expect people to want the latest changes but become more
conservative on machines that are working well and used for important
work. The 'well-tested' concept might have factors for age, feedback,
emergency overrides, etc.


Take your sliding scale and multiply the various configurations that
have to be generated/tested by each stop on the scale.


I was hoping this could work independently and unless something is
replaced with an expedited fix, packages would just age into view.



Lets say for instance that we want to do a new xulrunner, very raw.
Every xulrunner dependent app will have to be built for that version and
included. Then what if we want to do a new yelp that is pretty well
tested, but not perfect. Now we have to build one for the well tested
scale stop, and keep the other one (what nvrs to use now?!) at the
untested slot. Oh for fun, lets throw in something else that yelp
depends on, but is not in the xulrunner set, that is very well tested
and stable. Now you've got a yelp for the very well tested stop, a yelp
for the medium stop, a yelp with tons of other stuff at the raw stop for
xulrunner. What NVRs to apply to these, how many different ways can we
assemble packages to test for cohesive deps and upgrade paths, and how
to create a updates system that takes all this into consideration when
poor fred just wants to update his package?


Perhaps I haven't thought it all the way through, but I'd expect most of
this to take care of itself via the age factor with the updater ignoring
anything that doesn't meet the selection criteria on a package or any
dependencies. As long as everything works, you'd just be able to get
the same update the bleeding-edge machines got 2 weeks (or...?) ago. The
only tricky part would be how to push expedited fixes ahead of the clock
because they might drag along massive dependencies, but that should only
be done in rare carefully-consdered cases anyway. Negative feedback
could just slow the clock down.


But, feel free to start from scratch on a working design that gives
control to the end user. I can't help thinking that a
version-controlled (git/subversion) package list with tags to give
snapshots-in-time would be the ultimate way to do it. That could
divorce the tool making the 'risk-factor' decisions from yum itself.
You might build a new set of tags daily, recomputing the package lists
that should appear in each level of risk and yum would work with the
list instead of the repo contents. That would introduce a new workload
for the mirrors, though.


One other consideration a new package management scheme needs to turn
this into reproducible updates is to remember the repo where each
package lives (and understand that you don't know them all ahead of
time...).



--
Les Mikesell
lesmikesell@gmail.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-10-2008, 08:11 PM
Jesse Keating
 
Default Making updates-testing more useful

On Wed, 2008-12-10 at 15:03 -0600, Les Mikesell wrote:
> Perhaps I haven't thought it all the way through, but I'd expect most of
> this to take care of itself via the age factor with the updater ignoring
> anything that doesn't meet the selection criteria on a package or any
> dependencies. As long as everything works, you'd just be able to get
> the same update the bleeding-edge machines got 2 weeks (or...?) ago. The
> only tricky part would be how to push expedited fixes ahead of the clock
> because they might drag along massive dependencies, but that should only
> be done in rare carefully-consdered cases anyway. Negative feedback
> could just slow the clock down.
>
> But, feel free to start from scratch on a working design that gives
> control to the end user. I can't help thinking that a
> version-controlled (git/subversion) package list with tags to give
> snapshots-in-time would be the ultimate way to do it. That could
> divorce the tool making the 'risk-factor' decisions from yum itself.
> You might build a new set of tags daily, recomputing the package lists
> that should appear in each level of risk and yum would work with the
> list instead of the repo contents. That would introduce a new workload
> for the mirrors, though.
>
> One other consideration a new package management scheme needs to turn
> this into reproducible updates is to remember the repo where each
> package lives (and understand that you don't know them all ahead of
> time...).
>

The problem here is that these are descreet commits that one can pull or
cherry pick at will and integrate them into whatever current repo view
you have. It's far more complicated than that with interdependencies
and upgrade paths to consider.

Please re-read my scenarios and try to come up with any possible way to
make it work.

--
Jesse Keating RHCE (http://jkeating.livejournal.com)
Fedora Project (http://fedoraproject.org/wiki/JesseKeating)
GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
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 12-10-2008, 10:00 PM
Till Maas
 
Default Making updates-testing more useful

On Wed December 10 2008, Jesse Keating wrote:
> On Wed, 2008-12-10 at 12:35 -0500, Matthias Clasen wrote:
> > What do you think ?
>
> I could have sworn the bodhi userland client had a report-testable like
> function that would tell you all the things on your system that came
> from updates-testing. Probably just simply uses a comparison of what's
> in your rpmdb vs what's available from updates-testing (maybe even
> looking at gpg key?). Luke?

bodhi --help on F10 reports this:
| -T, --testable Display a list of installed updates that you could
| test and provide feedback for

Here it requires all the fedora certificates to work. On the machine I have
this setup, I currently have no testing updates, which it correctly reports.

Regards,
Till
--
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 08:31 PM.

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