On Wed December 10 2008, Jesse Keating wrote:

> 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?

/usr/lib/python2.5/site-packages/fedora/client/bodhi.py contains a testable
method that gets a list of testing updates from koji and checks for each,
whether it is installed afaics.

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

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.

This is horribly overengineered and just can't work (for the reasons Jesse
Keating already pointed out, so I won't repeat them).

I think the added complexity would also confuse end users, but we don't even
have to get that far with the discussion because it is impossible to
implement anyway.

Kevin Kofler

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

Kevin Kofler wrote:

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.


This is horribly overengineered and just can't work (for the reasons Jesse
Keating already pointed out, so I won't repeat them).


I still don't follow the reason it can't work - unless you remove or
rename packages within the window covered, it should be possible to
pretend newer packages don't exist and get the exactly same package set
that an earlier updater taking everything would have.



I think the added complexity would also confuse end users, but we don't even
have to get that far with the discussion because it is impossible to
implement anyway.


How about brute force with only 2 choices then? For every visible state
of the repository that syncs to the mirrors, make a snapshot copy that
normally ages a month and then appears as a 'safer' repository. In the
abnormal case you could have a procedure to 'fix' things that turned out
to be mistakes, or just skip letting certain instances appear at all. I
think there should be some simpler way to get this effect by
manipulating lists of package names, or using heuristics to ignore some
from a repository contain the full set, but brute force could certainly
work.


--
Les Mikesell
lesmikesell@gmail.com

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

On Wed, 2008-12-10 at 17:43 +0000, Richard Hughes wrote:
> Also, this would imply automatically turning on updates-testing,
> downloading metadata, and disabling updates-testing all behind the
> users back. A few people might get upset by this.

I've been prototyping something like this, but it doesn't seem to work:

repos = self.yumbase.repos.repos.values()
repos_enabled = []
repos_disabled = []

pkgs = []
yb._up = None
ygl = yb.doPackageLists(pkgnarrow='updates')
pkgs.extend(ygl.updates)
ygl = yb.doPackageLists(pkgnarrow='obsoletes')
pkgs.extend(ygl.obsoletes)

print pkgs

for repo in repos:
if repo.id.endswith('testing'):
if not repo.isEnabled():
repo.enablePersistent()
repos_enabled.append(repo)
else:
if repo.isEnabled():
repo.disablePersistent()
repos_disabled.append(repo)

pkgs = []
yb._up = None
ygl = yb.doPackageLists(pkgnarrow='updates')
pkgs.extend(ygl.updates)
ygl = yb.doPackageLists(pkgnarrow='obsoletes')
pkgs.extend(ygl.obsoletes)

print pkgs

for repo in repos_enabled:
repo.disablePersistent()
for repo in repos_disabled:
repo.enablePersistent()

I'm already clearing the update list by doing "yb._up = None", but I
can't seem to get the "testing" updates in the second pass. Any ideas?

Richard.


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

On Thu, 11 Dec 2008, Richard Hughes wrote:


On Wed, 2008-12-10 at 17:43 +0000, Richard Hughes wrote:

Also, this would imply automatically turning on updates-testing,
downloading metadata, and disabling updates-testing all behind the
users back. A few people might get upset by this.


I've been prototyping something like this, but it doesn't seem to work:

repos = self.yumbase.repos.repos.values()
repos_enabled = []
repos_disabled = []

pkgs = []
yb._up = None
ygl = yb.doPackageLists(pkgnarrow='updates')
pkgs.extend(ygl.updates)
ygl = yb.doPackageLists(pkgnarrow='obsoletes')
pkgs.extend(ygl.obsoletes)

print pkgs

for repo in repos:
if repo.id.endswith('testing'):
if not repo.isEnabled():
repo.enablePersistent()
repos_enabled.append(repo)
else:
if repo.isEnabled():
repo.disablePersistent()
repos_disabled.append(repo)

pkgs = []
yb._up = None
ygl = yb.doPackageLists(pkgnarrow='updates')
pkgs.extend(ygl.updates)
ygl = yb.doPackageLists(pkgnarrow='obsoletes')
pkgs.extend(ygl.obsoletes)

print pkgs

for repo in repos_enabled:
repo.disablePersistent()
for repo in repos_disabled:
repo.enablePersistent()

I'm already clearing the update list by doing "yb._up = None", but I
can't seem to get the "testing" updates in the second pass. Any ideas?


two things:
1. yb.up has a property() setter so you can do yb.up = None
2. you need to do the doRepoSetup(thisrepo=repo) for the repo to get
picked up.


-sv

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

On Thu, 2008-12-11 at 09:27 -0500, Seth Vidal wrote:
> two things:
> 1. yb.up has a property() setter so you can do yb.up = None

Ahh, changed, thanks.

> 2. you need to do the doRepoSetup(thisrepo=repo) for the repo to get
> picked up.

Tried that, and also tried
self.yumbase.repos.doSetup(thisrepo=repo.id) but neither forced a
reload. I had to do "yb.pkgSack = None" to get the new updates.

Richard.


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

On Wed, 2008-12-10 at 12:23 -0600, Mike Chambers wrote:
> And I guess (not to get too detailed into something not created yet)
> those updates would stay polluted in the GUI until you make a comment
> or remove it yourself (this would help show what you have left to
> comment on so you can remember)?

What about the attached mockup? This would tell people there are updates
available, but not configured. Comments welcome.

Richard.

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

2008/12/11 Richard Hughes <hughsient@gmail.com>:
> What about the attached mockup? This would tell people there are updates
> available, but not configured. Comments welcome.

I think that's an interesting approach to communicating the existence
of testing.

I would appreciate some text which invited them to enable the
corresponding repository to help with testing and an Amazon patented
One-Click way of enabling testing if they so choose in that dialog. I
also want a pony if you weren't already aware.

-jef

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

On Thu, 2008-12-11 at 08:52 -0900, Jeff Spaleta wrote:
> I would appreciate some text which invited them to enable the
> corresponding repository to help with testing and an Amazon patented
> One-Click way of enabling testing if they so choose in that dialog. I
> also want a pony if you weren't already aware.

Yes, we can easily enable the testing repos with a small button and a
more info link. The real question is, will this clutter the UI and
confuse new users?

You're on your own for the pony.

Richard.


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