On Tue, 18 Nov 2008, Jesse Keating wrote:


On Tue, 2008-11-18 at 17:04 -0500, Michael DeHaan wrote:

Couldn't both the above be solved by 'subscribing' to those sets of
packages via say PackageKit? That way when PackageKit goes to look for
updates, it only asks for updates for those particular packages. When
you update, if anything else is needed to satisfy newer builds of those
packages they can be pulled in.

Of course, what we'd likely see is a combo of "Give me all security
updates" and also "Give me updates only for these sets of packages".
The interesting question is how to design UI around the subscriptions.




I think I like this.

In the case of "I just want a newer OpenOffice" and don't touch
everything else, that's already covered by a yum install today -- but we
do need something for the update case(s).


The upside here is that it's purely client side code. We don't have to
change anything about how we prepare and publish updates.


Just to be clear I'm understanding:

we want to update openoffice and whatever it needs, but nothing else.


or you want to list a set of apps you want newer versions of and as little
else as possible?


is that correct?

so it would be like an alias that says:

yum update really means yum update openoffice* somestuff*
my_favorite_pkg*


?

-sv

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

On Tue, 2008-11-18 at 17:12 -0500, Seth Vidal wrote:
>
> so it would be like an alias that says:
>
> yum update really means yum update openoffice* somestuff*
> my_favorite_pkg*

Pretty much. I don't know how this would look/work at the yum level
where we can already just do what you said 'yum update foo* bar*', the
graphical level could just be some UI around this.

Essentially instead of subscribing to the firehose that is "update
everything possible from these repos" that is the default, to "only
consider these package sets as update targets, pull in whatever else you
need".

I personally don't see this as very useful, but then again I'm on a
decent internet connection, I have a fairly sparse install as it is, and
I want the firehose.

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

On Tue, 18 Nov 2008, Jesse Keating wrote:


On Tue, 2008-11-18 at 17:12 -0500, Seth Vidal wrote:


so it would be like an alias that says:

yum update really means yum update openoffice* somestuff*
my_favorite_pkg*


Pretty much. I don't know how this would look/work at the yum level
where we can already just do what you said 'yum update foo* bar*', the
graphical level could just be some UI around this.

Essentially instead of subscribing to the firehose that is "update
everything possible from these repos" that is the default, to "only
consider these package sets as update targets, pull in whatever else you
need".


Right - in some of these cases the last bit "pull in whatever else you
need" is the same as 'twist the firehose nozzle all the way as far as it
will go, hold tight!'




I personally don't see this as very useful, but then again I'm on a
decent internet connection, I have a fairly sparse install as it is, and





I want the firehose.


That's a Quote of the Day.

-sv



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

On Tue, 2008-11-18 at 17:42 -0500, Seth Vidal wrote:
>
> Right - in some of these cases the last bit "pull in whatever else you
> need" is the same as 'twist the firehose nozzle all the way as far as it
> will go, hold tight!'

Hardly. Much of the time updates are pretty self contained and
independent of other updates. Just because I want say pidgin updated
doesn't mean I have to get OpenOffice.org updated too, or just because I
want newer emacs doesn't mean I have to get newer eclipse+java, so on
and so forth. There really is a difference between targeted updates
+deps and the firehose.

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

On Tue, 18 Nov 2008, Jesse Keating wrote:


On Tue, 2008-11-18 at 17:42 -0500, Seth Vidal wrote:


Right - in some of these cases the last bit "pull in whatever else you
need" is the same as 'twist the firehose nozzle all the way as far as it
will go, hold tight!'


Hardly. Much of the time updates are pretty self contained and
independent of other updates. Just because I want say pidgin updated
doesn't mean I have to get OpenOffice.org updated too, or just because I
want newer emacs doesn't mean I have to get newer eclipse+java, so on
and so forth. There really is a difference between targeted updates
+deps and the firehose.



sure, that's why I said 'some'.

That's all.

-sv

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

Seth Vidal wrote:



In the case of "I just want a newer OpenOffice" and don't touch
everything else, that's already covered by a yum install today -- but we
do need something for the update case(s).


The upside here is that it's purely client side code. We don't have to
change anything about how we prepare and publish updates.


Just to be clear I'm understanding:

we want to update openoffice and whatever it needs, but nothing else.


or you want to list a set of apps you want newer versions of and as
little else as possible?


is that correct?

so it would be like an alias that says:

yum update really means yum update openoffice* somestuff*
my_favorite_pkg*



I think what people really want is 'updates that fix the things that are
already broken' but not 'updates that break something new'. Can you
come up with a way to 'crowdsource' this statistic? Perhaps an optional
poll where people could rate the health of their system and individual
apps, preferably tied somehow to the smolt hardware reports so someone
could see how the current updates run on hardware like their own or
which update triggered a flurry of problems. Or maybe this could be
automated - but the absence of problem reports for an update could mean
that no machines survived to send them...


--
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 Tue, 2008-11-18 at 17:16 -0600, Les Mikesell wrote:
> I think what people really want is 'updates that fix the things that are
> already broken' but not 'updates that break something new'. Can you
> come up with a way to 'crowdsource' this statistic? Perhaps an optional
> poll where people could rate the health of their system and individual
> apps, preferably tied somehow to the smolt hardware reports so someone
> could see how the current updates run on hardware like their own or
> which update triggered a flurry of problems. Or maybe this could be
> automated - but the absence of problem reports for an update could mean
> that no machines survived to send them...

This is the role that bodhi karma is trying to play.

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

On Tue, Nov 18, 2008 at 2:16 PM, Les Mikesell <lesmikesell@gmail.com> wrote:
> I think what people really want is 'updates that fix the things that are
> already broken' but not 'updates that break something new'. Can you come up
> with a way to 'crowdsource' this statistic? Perhaps an optional poll where
> people could rate the health of their system and individual apps, preferably
> tied somehow to the smolt hardware reports so someone could see how the
> current updates run on hardware like their own or which update triggered a
> flurry of problems. Or maybe this could be automated - but the absence of
> problem reports for an update could mean that no machines survived to send
> them...

Uhm.... in order to get "crowdsource" stats.. which will help you
prevent the releasing of updates to the crowd...there has to be a
crowd of people using the updates. How do yuou get feedback from the
crowd without exposing the crowd to the updates?

-jef

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

Jeff Spaleta wrote:

On Tue, Nov 18, 2008 at 2:16 PM, Les Mikesell <lesmikesell@gmail.com> wrote:

I think what people really want is 'updates that fix the things that are
already broken' but not 'updates that break something new'. Can you come up
with a way to 'crowdsource' this statistic? Perhaps an optional poll where
people could rate the health of their system and individual apps, preferably
tied somehow to the smolt hardware reports so someone could see how the
current updates run on hardware like their own or which update triggered a
flurry of problems. Or maybe this could be automated - but the absence of
problem reports for an update could mean that no machines survived to send
them...


Uhm.... in order to get "crowdsource" stats.. which will help you
prevent the releasing of updates to the crowd...there has to be a
crowd of people using the updates. How do yuou get feedback from the
crowd without exposing the crowd to the updates?


Every time anyone mentions slowing down the feature changes in favor of
fixing the brokenness there are a flurry of postings from people saying
they want all the new features they can get. There has to be a way to
take advantage of these willing guinea pigs (or is it canaries in a mine
shaft?) and let their experience determine when it is safe for everyone
else to follow. But, you either need an intermediate repository with
things moved on to the safer one at some point, or a client-driven
mechanism that knows how to request the degree of vetting desired along
with some way to accumulate the statistics. I'd personally be much more
interested in keeping an up to date test box running if I knew that
experiencing problems on it would have any eventual benefits.


--
Les Mikesell
lesmikesell@gmail.com

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

I am not sure if this exists with yum now or not.
My experience has been if something has been around for a while it usually
doesn't break things. Or maybe the correct thing to say is that if it does
break things then there is a newer version fairly soon.
So is there a way to say that I only want updates that are 2 weeks old?

Jerry Williams

> -----Original Message-----
> From: fedora-devel-list-bounces@redhat.com [mailto:fedora-devel-list-
> bounces@redhat.com] On Behalf Of Jesse Keating
> Sent: Tuesday, November 18, 2008 3:50 PM
> To: fedora-devel-list@redhat.com
> Subject: Re: F11 Proposal: Stabilization
>
> On Tue, 2008-11-18 at 17:42 -0500, Seth Vidal wrote:
> >
> > Right - in some of these cases the last bit "pull in whatever else you
> > need" is the same as 'twist the firehose nozzle all the way as far as it
> > will go, hold tight!'
>
> Hardly. Much of the time updates are pretty self contained and
> independent of other updates. Just because I want say pidgin updated
> doesn't mean I have to get OpenOffice.org updated too, or just because I
> want newer emacs doesn't mean I have to get newer eclipse+java, so on
> and so forth. There really is a difference between targeted updates
> +deps and the firehose.
>
> --
> 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