3:05 p.m.
Anybody else think we're issuing entirely /way/ too many updates? We've had
138 "stable" updates, and 177 current "testing" updates. If all those
were
to go stable, we're talking over 300 updates, in just over a week.
Seriously. We're drowning our users in updates. Are all of them really
necessary? I feel like we've got this culture of update whatever/whenever
coming from Extras where it was just fire and forget. While that might be
fun for the maintainer, is it fun for the user? Is it fun for the user with
a slow connection?
--
Jesse Keating
Release Engineer: Fedora
3:15 p.m.
On Sat, Jun 09, 2007 at 16:05:00 -0400,
Jesse Keating <jkeating(a)redhat.com> wrote:
Anybody else think we're issuing entirely /way/ too many updates?
We've had
138 "stable" updates, and 177 current "testing" updates. If all
those were
to go stable, we're talking over 300 updates, in just over a week.
Seriously. We're drowning our users in updates. Are all of them really
necessary? I feel like we've got this culture of update whatever/whenever
coming from Extras where it was just fire and forget. While that might be
fun for the maintainer, is it fun for the user? Is it fun for the user with
a slow connection?
I'd rather have the updates available as rpm's than have to switch to building
a package from source, if there is an update I want.
Is it possible to provide meta data to yum with some sort of indication
of what the update does. Maybe a choice from Security, Critical (e.g.
data loss) bug, Bug fix, New features. Then you could tell yum to only grab
security and critical bug fixes if you didn't want to download lots of
updates.
3:28 p.m.
Bruno Wolff III wrote:
I'd rather have the updates available as rpm's than have to
switch to building
a package from source, if there is an update I want.
Very true...
Is it possible to provide meta data to yum with some sort of
indication
of what the update does. Maybe a choice from Security, Critical (e.g.
data loss) bug, Bug fix, New features. Then you could tell yum to only grab
security and critical bug fixes if you didn't want to download lots of
updates.
You want something like the "urgency" attribute of debian packages.
In my opinion, it belongs to RPM and not yum, but I'd second the
idea in general.
--
// Bernardo Innocenti
\X/ http://www.codewiz.org/
7:19 p.m.
On Saturday 09 June 2007 16:15:15 Bruno Wolff III wrote:
Is it possible to provide meta data to yum with some sort of
indication
of what the update does. Maybe a choice from Security, Critical (e.g.
data loss) bug, Bug fix, New features. Then you could tell yum to only grab
security and critical bug fixes if you didn't want to download lots of
updates.
Actually we're going to re-implement that. We had it for the Core updater
tool, Luke will hook us up with it for bodhi soon. It'll contain the
contents of the "notes" you put into bodhi so that when you look at a list of
updates in pup you can see what the update is for. However when you're
staring down 60+ updates (or 90 or 120 depending on when you look) how many
people are actually going to look through or are they going to just apply and
hope for the best?
I don't know if this is a real problem or not, just an observation on the
weekend (:
--
Jesse Keating
Release Engineer: Fedora
8:21 p.m.
Jesse Keating wrote:
On Saturday 09 June 2007 16:15:15 Bruno Wolff III wrote:
> Is it possible to provide meta data to yum with some sort of indication
> of what the update does. Maybe a choice from Security, Critical (e.g.
> data loss) bug, Bug fix, New features. Then you could tell yum to only grab
> security and critical bug fixes if you didn't want to download lots of
> updates.
Actually we're going to re-implement that. We had it for the Core updater
tool, Luke will hook us up with it for bodhi soon. It'll contain the
contents of the "notes" you put into bodhi so that when you look at a list of
updates in pup you can see what the update is for. However when you're
staring down 60+ updates (or 90 or 120 depending on when you look) how many
people are actually going to look through or are they going to just apply and
hope for the best?
I don't know if this is a real problem or not, just an observation on the
weekend (:
If the classification of updates get exposed through Pup with a easy way
to set preferences then it will get used much more.
Rahul
1:48 a.m.
Jesse Keating wrote:
On Saturday 09 June 2007 16:15:15 Bruno Wolff III wrote:
> Is it possible to provide meta data to yum with some sort of indication
> of what the update does. Maybe a choice from Security, Critical (e.g.
> data loss) bug, Bug fix, New features. Then you could tell yum to only grab
> security and critical bug fixes if you didn't want to download lots of
> updates.
Actually we're going to re-implement that. We had it for the Core updater
tool, Luke will hook us up with it for bodhi soon. It'll contain the
contents of the "notes" you put into bodhi so that when you look at a list of
updates in pup you can see what the update is for. However when you're
staring down 60+ updates (or 90 or 120 depending on when you look) how many
people are actually going to look through or are they going to just apply and
hope for the best?
I don't know if this is a real problem or not, just an observation on the
weekend (:
Do keep in mind when assessing wether this is a real problem or not, that many
people will not have all updated packages installed, in the case of formaer
extras packages many people will actually not have them installed, and thus
they won't notice a thing about them being updated.
Regards,
Hans
6:49 a.m.
On Sunday 10 June 2007 02:48:58 Hans de Goede wrote:
Do keep in mind when assessing wether this is a real problem or not,
that
many people will not have all updated packages installed, in the case of
formaer extras packages many people will actually not have them installed,
and thus they won't notice a thing about them being updated.
Well there is lots of masochists that yell and scream every release for the
Everything option again... (:
--
Jesse Keating
Release Engineer: Fedora
3:23 p.m.
On Sa Juni 9 2007, Jesse Keating wrote:
coming from Extras where it was just fire and forget. While that
might be
fun for the maintainer, is it fun for the user? Is it fun for the user
with a slow connection?
A slow connection is never fun ;-). But seriously, nobody is forced to update
and thanks to bodhi and iirc the yum-security plugin[1] it is even possible
to install only security updates. Also I guess there are many updates from
Extras Packages, that are released now because of the Freeze, so the amount
of updates will be less the next weeks. And the user in me likes up to date
software very much. And to make it more fun for users with a slow connection,
yum-presto will help a lot more. But maybe there should be also delta-xml
files for the repository metadata, because it takes very long to download
these, too, with a slow connection.
Regards,
Till
[1] But I don't know, whether or not it is already in Fedora 7
4:54 a.m.
yum-presto will help a lot more. But maybe there should be also
delta-xml
files for the repository metadata, because it takes very long to download
these, too, with a slow connection.
Regards,
Till
Right, this is a very serious point. Right now, the meta data in my
/var/cache/yum/development amounts to about 65 MB which alone would take 5 hours to
download via a standard analog modem connection!
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
5:25 a.m.
On Sun, 2007-06-10 at 11:54 +0200, Joachim Frieben wrote:
> yum-presto will help a lot more. But maybe there should be also
delta-xml
> files for the repository metadata, because it takes very long to download
> these, too, with a slow connection.
>
> Regards,
> Till
Right, this is a very serious point. Right now, the meta data in my
/var/cache/yum/development amounts to about 65 MB which alone would take 5 hours to
download via a standard analog modem connection!
I'm looking into generating deltas for the xml, but there are a few
other things on my plate at the moment. The real issue is that it's not
always xml files that we download...sometimes we get sqlite files.
What we need is to have a program that uses the modified bsdiff
algorithm in deltarpm to generate differences between regular files, not
just deltarpms.
Jonathan
5:39 a.m.
On So Juni 10 2007, Jonathan Dieter wrote:
I'm looking into generating deltas for the xml, but there are a
few
other things on my plate at the moment. The real issue is that it's not
always xml files that we download...sometimes we get sqlite files.
Is the information in the xml and sqlite files different? Afaik the sqlite
files only increase the speed of yum, so when downloading the sqlite files
needs more time than processing the xml files, it is better to skip them.
Regards,
Till
9:23 a.m.
On Sun, 2007-06-10 at 12:39 +0200, Till Maas wrote:
Is the information in the xml and sqlite files different? Afaik the
sqlite
files only increase the speed of yum, so when downloading the sqlite files
needs more time than processing the xml files, it is better to skip them.
It's not so much that the data is different as it is the fact that
making an efficient diff of two xml files is easy, but making an
effecient diff of two sqlite files is a bit more difficult.
Jonathan
12:59 p.m.
On Sun, 2007-06-10 at 13:25 +0300, Jonathan Dieter wrote:
On Sun, 2007-06-10 at 11:54 +0200, Joachim Frieben wrote:
> > yum-presto will help a lot more. But maybe there should be also delta-xml
> > files for the repository metadata, because it takes very long to download
> > these, too, with a slow connection.
> >
> > Regards,
> > Till
>
> Right, this is a very serious point. Right now, the meta data in my
/var/cache/yum/development amounts to about 65 MB which alone would take 5 hours to
download via a standard analog modem connection!
I'm looking into generating deltas for the xml, but there are a few
other things on my plate at the moment. The real issue is that it's not
always xml files that we download...sometimes we get sqlite files.
What we need is to have a program that uses the modified bsdiff
algorithm in deltarpm to generate differences between regular files, not
just deltarpms.
What's been discussed on yum-devel is generating a textual diff from
old-repodata to new-repodata so we can produce a comparable sqlite w/o
downloading as much.
-sv
4:31 a.m.
On Sun, 2007-06-10 at 13:59 -0400, seth vidal wrote:
What's been discussed on yum-devel is generating a textual diff
from
old-repodata to new-repodata so we can produce a comparable sqlite w/o
downloading as much.
Makes sense. Are you planning on implementing that as part of yum or do
you want me to implement it as part of yum-presto?
Jonathan
5:27 a.m.
On Mon, 2007-06-11 at 12:31 +0300, Jonathan Dieter wrote:
On Sun, 2007-06-10 at 13:59 -0400, seth vidal wrote:
> What's been discussed on yum-devel is generating a textual diff from
> old-repodata to new-repodata so we can produce a comparable sqlite w/o
> downloading as much.
>
Makes sense. Are you planning on implementing that as part of yum or do
you want me to implement it as part of yum-presto?
It probably makes sense in base yum and in createrepo since the
repository side would need this information, too.
-sv
12:21 p.m.
On Sun, 2007-06-10 at 11:54 +0200, Joachim Frieben wrote:
> yum-presto will help a lot more. But maybe there should be also
delta-xml
> files for the repository metadata, because it takes very long to download
> these, too, with a slow connection.
>
> Regards,
> Till
Right, this is a very serious point. Right now, the meta data in my
/var/cache/yum/development amounts to about 65 MB which alone would take 5 hours to
download via a standard analog modem connection!
which metadata? Can you list the files?
thanks,
-sv
12:41 p.m.
[big metadata]
On So Juni 10 2007, seth vidal wrote:
which metadata? Can you list the files?
With Fedora 6 I have similiar results:
$ LANG=C du -hcs /var/cache/yum/{extras,core,updates}/*xml*
4.5M /var/cache/yum/extras/filelists.xml.gz
23M /var/cache/yum/extras/filelists.xml.gz.sqlite
1.6M /var/cache/yum/extras/primary.xml.gz
13M /var/cache/yum/extras/primary.xml.gz.sqlite
8.0K /var/cache/yum/extras/repomd.xml
2.5M /var/cache/yum/core/filelists.xml.gz
12M /var/cache/yum/core/filelists.xml.gz.sqlite
836K /var/cache/yum/core/primary.xml.gz
4.6M /var/cache/yum/core/primary.xml.gz.sqlite
8.0K /var/cache/yum/core/repomd.xml
2.8M /var/cache/yum/updates/filelists.xml.gz
16M /var/cache/yum/updates/filelists.xml.gz.sqlite
476K /var/cache/yum/updates/primary.xml.gz
3.5M /var/cache/yum/updates/primary.xml.gz.sqlite
8.0K /var/cache/yum/updates/repomd.xml
83M total
Regards,
Till
12:44 p.m.
On Sun, 2007-06-10 at 19:41 +0200, Till Maas wrote:
[big metadata]
On So Juni 10 2007, seth vidal wrote:
> which metadata? Can you list the files?
With Fedora 6 I have similiar results:
$ LANG=C du -hcs /var/cache/yum/{extras,core,updates}/*xml*
4.5M /var/cache/yum/extras/filelists.xml.gz
23M /var/cache/yum/extras/filelists.xml.gz.sqlite
1.6M /var/cache/yum/extras/primary.xml.gz
13M /var/cache/yum/extras/primary.xml.gz.sqlite
8.0K /var/cache/yum/extras/repomd.xml
2.5M /var/cache/yum/core/filelists.xml.gz
12M /var/cache/yum/core/filelists.xml.gz.sqlite
836K /var/cache/yum/core/primary.xml.gz
4.6M /var/cache/yum/core/primary.xml.gz.sqlite
8.0K /var/cache/yum/core/repomd.xml
2.8M /var/cache/yum/updates/filelists.xml.gz
16M /var/cache/yum/updates/filelists.xml.gz.sqlite
476K /var/cache/yum/updates/primary.xml.gz
3.5M /var/cache/yum/updates/primary.xml.gz.sqlite
8.0K /var/cache/yum/updates/repomd.xml
83M total
some of these are downloaded, some are generated.
the xml.gz files are used to make the xml.gz.sqlite files. So you
downloaded .gz files only.
in fedora 7 you should only have *.sqlite files - no .gz files at all.
-sv
2:31 p.m.
On Sat, Jun 09, 2007 at 10:23:10PM +0200, Till Maas wrote:
On Sa Juni 9 2007, Jesse Keating wrote:
> coming from Extras where it was just fire and forget. While that might be
> fun for the maintainer, is it fun for the user? Is it fun for the user
> with a slow connection?
A slow connection is never fun ;-). But seriously, nobody is forced to update
and thanks to bodhi and iirc the yum-security plugin[1] it is even possible
to install only security updates. Also I guess there are many updates from
Extras Packages, that are released now because of the Freeze, so the amount
of updates will be less the next weeks. And the user in me likes up to date
software very much. And to make it more fun for users with a slow connection,
yum-presto will help a lot more. But maybe there should be also delta-xml
files for the repository metadata, because it takes very long to download
these, too, with a slow connection.
Regards,
Till
[1] But I don't know, whether or not it is already in Fedora 7
yum-security is in Fedora 7 repos, but will not yet work properly with
Fedora 7 updates at the moment, as bodhi does not currently insert the
updateinfo.xml into the repository yet. We recently changed how we create
our update repositories, so I need tweak bodhi to have it insert this
updateinfo post-mashing. Give me a day or so and I'll have it in there.
luke
3:32 p.m.
On Sat, 2007-06-09 at 16:05 -0400, Jesse Keating wrote:
Seriously. We're drowning our users in updates. Are all of them
really
necessary? I feel like we've got this culture of update
whatever/whenever
coming from Extras where it was just fire and forget. While that
might be
fun for the maintainer, is it fun for the user? Is it fun for the
user with
a slow connection?
Are people complaining? Are we actually breaking stuff in the process?
Are you upset with the amount of bandwith we're eating or just based on
principal?
We're not RHEL. If an update is a good one I would rather have it go
out than not. Also encouraging a re-spin of the CDs/DVDs in a couple of
weeks might be a good idea ala unity. Don't know how much human
bandwith we have for such a thing, though.
--Chris
3:41 p.m.
Christopher Blizzard wrote:
Are people complaining?
I don't complain when it happens with my own computer that's
being updated daily... but it's painful when you update a
dozen of desktops in the office to F7 and all them want to
download 500MB worth of updates the first time they boot.
Yes, I could use a local Fedora mirror. And, in fact,
I do. But then I'd have to customize the yum config on
all clients to go look there.
--
// Bernardo Innocenti
\X/ http://www.codewiz.org/
4:36 p.m.
On 6/9/07, Bernardo Innocenti <bernie(a)codewiz.org> wrote:
Yes, I could use a local Fedora mirror. And, in fact,
I do. But then I'd have to customize the yum config on
all clients to go look there.
Guru Labs have a nice howto for solving that problem (/me bookmarking it...)
http://www.gurulabs.com/goodies/YUM_automatic_local_mirror.php
12:05 a.m.
Gianluca Sforna (giallu(a)gmail.com) said:
On 6/9/07, Bernardo Innocenti <bernie(a)codewiz.org> wrote:
>Yes, I could use a local Fedora mirror. And, in fact,
>I do. But then I'd have to customize the yum config on
>all clients to go look there.
>
Guru Labs have a nice howto for solving that problem (/me bookmarking it...)
http://www.gurulabs.com/goodies/YUM_automatic_local_mirror.php
Why not just use:
https://lists.dulug.duke.edu/pipermail/yum-devel/2007-May/003654.html
?
Bill
9:51 p.m.
On Mon, 2007-06-11 at 01:05 -0400, Bill Nottingham wrote:
Gianluca Sforna (giallu(a)gmail.com) said:
> On 6/9/07, Bernardo Innocenti <bernie(a)codewiz.org> wrote:
> >Yes, I could use a local Fedora mirror. And, in fact,
> >I do. But then I'd have to customize the yum config on
> >all clients to go look there.
> >
>
> Guru Labs have a nice howto for solving that problem (/me bookmarking it...)
>
> http://www.gurulabs.com/goodies/YUM_automatic_local_mirror.php
Why not just use:
https://lists.dulug.duke.edu/pipermail/yum-devel/2007-May/003654.html
?
The Guru Labs local mirror howto method doesn't require *any* changes to
the clients. That was the whole point. :)
If the yum-avahi plugin ever gets installed and enabled by default, then
it would address that concern too.
I have my own question about the yum-avahi. What does it take it get it
to work (if it can) across multiple subnets within an organization?
Dax Kelson
Guru Labs
8:31 p.m.
On Sat, Jun 09, 2007 at 04:41:12PM -0400, Bernardo Innocenti wrote:
Christopher Blizzard wrote:
>Are people complaining?
I don't complain when it happens with my own computer that's
being updated daily... but it's painful when you update a
dozen of desktops in the office to F7 and all them want to
download 500MB worth of updates the first time they boot.
Yes, I could use a local Fedora mirror. And, in fact,
I do. But then I'd have to customize the yum config on
all clients to go look there.
You can add your local private mirror to mirrormanager, add a netblock
that covers your address space, and all your clients will then pull
from your local mirror rather than public mirrors, with no change on
the clients.
https://admin.fedoraproject.org/mirrormanager
http://fedoraproject.org/wiki/Infrastructure/Mirroring
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
9:25 p.m.
Matt Domsch wrote:
On Sat, Jun 09, 2007 at 04:41:12PM -0400, Bernardo Innocenti wrote:
> Christopher Blizzard wrote:
>
>> Are people complaining?
> I don't complain when it happens with my own computer that's
> being updated daily... but it's painful when you update a
> dozen of desktops in the office to F7 and all them want to
> download 500MB worth of updates the first time they boot.
>
> Yes, I could use a local Fedora mirror. And, in fact,
> I do. But then I'd have to customize the yum config on
> all clients to go look there.
You can add your local private mirror to mirrormanager, add a netblock
that covers your address space, and all your clients will then pull
from your local mirror rather than public mirrors, with no change on
the clients.
https://admin.fedoraproject.org/mirrormanager
http://fedoraproject.org/wiki/Infrastructure/Mirroring
Matt, would you be interested in writing a updated mirror guide? The one
at http://docs.fedoraproject.org is pretty outdated and we need to cover
all the new configurations and features in the new mirror manager.
Rahul
9:52 p.m.
On Sun, Jun 10, 2007 at 07:55:11AM +0530, Rahul Sundaram wrote:
Matt Domsch wrote:
>On Sat, Jun 09, 2007 at 04:41:12PM -0400, Bernardo Innocenti wrote:
>>Christopher Blizzard wrote:
>>
>>>Are people complaining?
>>I don't complain when it happens with my own computer that's
>>being updated daily... but it's painful when you update a
>>dozen of desktops in the office to F7 and all them want to
>>download 500MB worth of updates the first time they boot.
>>
>>Yes, I could use a local Fedora mirror. And, in fact,
>>I do. But then I'd have to customize the yum config on
>>all clients to go look there.
>
>You can add your local private mirror to mirrormanager, add a netblock
>that covers your address space, and all your clients will then pull
>from your local mirror rather than public mirrors, with no change on
>the clients.
>
>https://admin.fedoraproject.org/mirrormanager
>http://fedoraproject.org/wiki/Infrastructure/Mirroring
Matt, would you be interested in writing a updated mirror guide? The one
at http://docs.fedoraproject.org is pretty outdated and we need to cover
all the new configurations and features in the new mirror manager.
Yeah, somehow I found that link the other day, and thought it needed
to be reworked somewhat. That doc is nice in that works regardless of
any new features Fedora Infrastructure provides (like mirrormanager),
and is good for anyone anywhere that has a copy of the packages,
either from media or downloaded. But it could certainly be enhanced
to describe using the publicly available mirrors to keep your own tree
up-to-date, as well as pointers to perhaps another doc describing how
to use MirrorManager.
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
9:34 p.m.
On Sat, 2007-06-09 at 21:52 -0500, Matt Domsch wrote:
On Sun, Jun 10, 2007 at 07:55:11AM +0530, Rahul Sundaram wrote:
> Matt Domsch wrote:
> >On Sat, Jun 09, 2007 at 04:41:12PM -0400, Bernardo Innocenti wrote:
> >>Christopher Blizzard wrote:
> >>
> >>>Are people complaining?
> >>I don't complain when it happens with my own computer that's
> >>being updated daily... but it's painful when you update a
> >>dozen of desktops in the office to F7 and all them want to
> >>download 500MB worth of updates the first time they boot.
> >>
> >>Yes, I could use a local Fedora mirror. And, in fact,
> >>I do. But then I'd have to customize the yum config on
> >>all clients to go look there.
> >
> >You can add your local private mirror to mirrormanager, add a netblock
> >that covers your address space, and all your clients will then pull
> >from your local mirror rather than public mirrors, with no change on
> >the clients.
> >
> >https://admin.fedoraproject.org/mirrormanager
> >http://fedoraproject.org/wiki/Infrastructure/Mirroring
>
> Matt, would you be interested in writing a updated mirror guide? The one
> at http://docs.fedoraproject.org is pretty outdated and we need to cover
> all the new configurations and features in the new mirror manager.
Yeah, somehow I found that link the other day, and thought it needed
to be reworked somewhat. That doc is nice in that works regardless of
any new features Fedora Infrastructure provides (like mirrormanager),
and is good for anyone anywhere that has a copy of the packages,
either from media or downloaded. But it could certainly be enhanced
to describe using the publicly available mirrors to keep your own tree
up-to-date, as well as pointers to perhaps another doc describing how
to use MirrorManager.
I'd love to see some changes to this document. I wrote that *way* back
in the FC2 time frame and the Docs Project was still testing out its
wings back then, so much so that it took until FC3 got out for the
document to be published. Wasn't long before it was behind, as my time
got eaten up by toolchain and other work. ;-)
Matt, if you're interested in updating it, I'm happy to help by giving
you any needed info on the tools and other niceties for FDP, as well as
helping edit of course.
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Project: http://fedoraproject.org/wiki/PaulWFrields
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
4:30 a.m.
Le samedi 09 juin 2007 à 20:31 -0500, Matt Domsch a écrit :
You can add your local private mirror to mirrormanager, add a
netblock
that covers your address space, and all your clients will then pull
from your local mirror rather than public mirrors, with no change on
the clients.
That's nice but if the infrastructure was friendlier to proxies most big
entities wouldn't have to setup any mirror but could just rely on their
existing proxy infrastructure
- mirrormanager should return data with high expire values and/or detect
squid/mod_proxy whatever and direct it to a static mirror
- yum should generate proxy-friendly metadata
--
Nicolas Mailhot
8:06 a.m.
On Sun, Jun 10, 2007 at 11:30:47AM +0200, Nicolas Mailhot wrote:
Le samedi 09 juin 2007 ?? 20:31 -0500, Matt Domsch a ??crit :
> You can add your local private mirror to mirrormanager, add a netblock
> that covers your address space, and all your clients will then pull
> from your local mirror rather than public mirrors, with no change on
> the clients.
That's nice but if the infrastructure was friendlier to proxies most big
entities wouldn't have to setup any mirror but could just rely on their
existing proxy infrastructure
- mirrormanager should return data with high expire values and/or detect
squid/mod_proxy whatever and direct it to a static mirror
Mirrormanager just returns a yum mirrorlist, which is updated hourly,
and is very fast to return (under 0.5s almost all the time). Not sure
how caching will help this.
We don't presently do what openSUSE does, which is handle all the
mirror redirection on the back-end. In their case, their yum
mirrorlist-like thing only ever returns one answer:
download.opensuse.org/path/to/repo/, and then they take the request
for download.opensuse.org/path/to/repo/file.rpm and do a temporary HTTP
redirect to the actual site they want to refer that particular user
to. This gives them the ability to see every RPM download request
(for statistical purposes), and presumably the user-side proxies might
cache the downloaded RPM (not sure how that would work with the
redirect though). As it stands, user-side proxies can't really cache
effectively, because they may get told to use a different mirror for
every yum invocation.
- yum should generate proxy-friendly metadata
It's static files from yum, yes? What's not proxy-friendly about
that?
I'm open to all suggestions, and patches are welcome!
-Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
8:34 a.m.
Le Lun 11 juin 2007 15:06, Matt Domsch a écrit :
Mirrormanager just returns a yum mirrorlist, which is updated
hourly,
and is very fast to return (under 0.5s almost all the time).
And this kills proxies as the systems behind a proxy will switch from
a mirror already cached by the proxy to another one potentially every
hour. Proxies want a static mirrorlist or a mirrorlist they can cache.
(using a mirrorlist URL with parameters is probably sufficient to make
it uncacheable, better static URLs with mod_rewrite or something
similar behind to translate them in hidden requests)
> - yum should generate proxy-friendly metadata
It's static files from yum, yes? What's not proxy-friendly about
that?
The static files do not use a mimetype that allows embedding
expiration period, so unless the mirror admins configure their http
server to add correct expire info for those specific files in the HTTP
response (no one will bother) proxies will fall back to a default
retention policy.
Usually that means "keep the files x hours/days, and only check later
if they've been updated". Every yum behind the proxy will then use a
cached metadata version that does not correspond to the actual mirror
content and will trigger problems. (typically yum asks for a package
which exists in the cached metadata but is no longuer on the mirror
and has not been cached in the proxy when it did exist -> boom)
If you are behind a non-mandatory proxy you can configure yum to
ignore the proxy for metadata (lots of hassle when you have to change
the default config of many systems. Also this option only exists
because the current system does not work with proxies)
If you're not you're out of luck.
A proxy-friendly metadata would probably be an xhtml index file (with
correct HTML expire metadata) pointing to xml.gz files that change
name every time they're regenarated. Other people may have better
suggestions.
--
Nicolas Mailhot
4:19 p.m.
At 3:34 PM +0200 6/11/07, Nicolas Mailhot wrote:
Le Lun 11 juin 2007 15:06, Matt Domsch a écrit :
> Mirrormanager just returns a yum mirrorlist, which is updated hourly,
> and is very fast to return (under 0.5s almost all the time).
And this kills proxies as the systems behind a proxy will switch from
a mirror already cached by the proxy to another one potentially every
hour. Proxies want a static mirrorlist or a mirrorlist they can cache.
(using a mirrorlist URL with parameters is probably sufficient to make
it uncacheable, better static URLs with mod_rewrite or something
similar behind to translate them in hidden requests)
...
Would my StableMirror yum plugin help? It uses the same mirror each time
as long as that mirror was offered (and it does other things too). It's
main idea could certainly be added to yum. StableMirror isn't updated for
F7 yet (I assume it will need an update).
<http://georgeaneldon.com/stablemirror.htm>
--
____________________________________________________________________
TonyN.:' <mailto:tonynelson@georgeanelson.com>
' <http://www.georgeanelson.com/>
12:40 a.m.
Le lundi 11 juin 2007 à 17:19 -0400, Tony Nelson a écrit :
Would my StableMirror yum plugin help? It uses the same mirror each
time
as long as that mirror was offered (and it does other things too). It's
main idea could certainly be added to yum. StableMirror isn't updated for
F7 yet (I assume it will need an update).
<http://georgeaneldon.com/stablemirror.htm>
Can't really say, never used it and the URL you gave is dead.
However from your description it isn't going to fix the metadata
problem, nor ensure every box behind the proxy uses the same mirror
--
Nicolas Mailhot
1:18 p.m.
At 7:40 AM +0200 6/12/07, Nicolas Mailhot wrote:
Le lundi 11 juin 2007 à 17:19 -0400, Tony Nelson a écrit :
> Would my StableMirror yum plugin help? It uses the same mirror each time
> as long as that mirror was offered (and it does other things too). It's
> main idea could certainly be added to yum. StableMirror isn't updated for
> F7 yet (I assume it will need an update).
> <http://georgeaneldon.com/stablemirror.htm>
Can't really say, never used it and the URL you gave is dead.
Oops, typo.
<http://georgeanelson.com/stablemirror.htm>
However from your description it isn't going to fix the metadata
problem, nor ensure every box behind the proxy uses the same mirror
Well, yes, it can be used to ensure that every box uses the same mirror, if
it is available, by pushing the same stablemirrors file to each machine.
--
____________________________________________________________________
TonyN.:' <mailto:tonynelson@georgeanelson.com>
' <http://www.georgeanelson.com/>
5:23 a.m.
New subject: apt-proxy for yum? (Re: The updates firehose)
On 10.06.2007 03:31, Matt Domsch wrote:
On Sat, Jun 09, 2007 at 04:41:12PM -0400, Bernardo Innocenti wrote:
> Christopher Blizzard wrote:
>
>> Are people complaining?
> I don't complain when it happens with my own computer that's
> being updated daily... but it's painful when you update a
> dozen of desktops in the office to F7 and all them want to
> download 500MB worth of updates the first time they boot.
>
> Yes, I could use a local Fedora mirror. And, in fact,
> I do. But then I'd have to customize the yum config on
> all clients to go look there.
You can add your local private mirror to mirrormanager, add a netblock
that covers your address space, and all your clients will then pull
from your local mirror rather than public mirrors, with no change on
the clients.
https://admin.fedoraproject.org/mirrormanager
http://fedoraproject.org/wiki/Infrastructure/Mirroring
Nice solution.
But as a side note to that: I in fact had a local update mirror for Core
in the past, but with the Core and Extras merge I don't have one, as the
space and download requirements drastically increased. So much that
having a local mirror is not worth the trouble if you don't have more
then 10 (?) machines with Fedora afaics. So in this regard the merge
made things worse for me.
What I'd like to have these days is a kind transparent apt-proxy (
http://apt-proxy.sourceforge.net/ ) for yum, that keeps packages in a cache.
Sure, squid can help with that, but a more intelligent solution (package
still in the repo? only one ppc machine in the network, so don't cache
ppc download, ...; package part of standard-install, so keep in in the
cache if possible) could do a whole lot better.
CU
thl
1:04 p.m.
New subject: apt-proxy for yum? (Re: The updates firehose)
On Sun, 2007-06-10 at 12:23 +0200, Thorsten Leemhuis wrote:
Nice solution.
But as a side note to that: I in fact had a local update mirror for Core
in the past, but with the Core and Extras merge I don't have one, as the
space and download requirements drastically increased. So much that
having a local mirror is not worth the trouble if you don't have more
then 10 (?) machines with Fedora afaics. So in this regard the merge
made things worse for me.
What I'd like to have these days is a kind transparent apt-proxy (
http://apt-proxy.sourceforge.net/ ) for yum, that keeps packages in a cache.
repotrack.
it'll download the packages you want and all of the dependencies for
those packages (recursively) to a local cache.
or reposync which is like rsync for yum repos.
Sure, squid can help with that, but a more intelligent solution
(package
still in the repo? only one ppc machine in the network, so don't cache
ppc download, ...; package part of standard-install, so keep in in the
cache if possible) could do a whole lot better.
that intelligence is in the form of scripting, at some point there is a
diminishing return on the scripting versus just downloading everything
in a single swath.
-sv
12:06 a.m.
New subject: The updates firehose - automatic local mirrors
On Sat, 9 Jun 2007, Matt Domsch wrote:
On Sat, Jun 09, 2007 at 04:41:12PM -0400, Bernardo Innocenti wrote:
> Christopher Blizzard wrote:
>
>> Are people complaining?
>
> I don't complain when it happens with my own computer that's
> being updated daily... but it's painful when you update a
> dozen of desktops in the office to F7 and all them want to
> download 500MB worth of updates the first time they boot.
>
> Yes, I could use a local Fedora mirror. And, in fact,
> I do. But then I'd have to customize the yum config on
> all clients to go look there.
You can add your local private mirror to mirrormanager, add a netblock
that covers your address space, and all your clients will then pull
from your local mirror rather than public mirrors, with no change on
the clients.
https://admin.fedoraproject.org/mirrormanager
http://fedoraproject.org/wiki/Infrastructure/Mirroring
(My definition of 'local' = in the same country or region of
countries. As shown in later messages, others want to create custom
repositories for organization's internal use, but that requires
different tools.)
Even better would be that only local mirrors would be shown
automatically. Nowadays, countries with less than 3 mirrors don't get
this optimization.
This would require rather simple updates to the
http://mirrors.fedoraproject.org/mirrorlist script.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
8:08 a.m.
New subject: The updates firehose - automatic local mirrors
On Mon, Jun 11, 2007 at 08:06:39AM +0300, Pekka Savola wrote:
On Sat, 9 Jun 2007, Matt Domsch wrote:
>On Sat, Jun 09, 2007 at 04:41:12PM -0400, Bernardo Innocenti wrote:
>>Christopher Blizzard wrote:
>>
>>>Are people complaining?
>>
>>I don't complain when it happens with my own computer that's
>>being updated daily... but it's painful when you update a
>>dozen of desktops in the office to F7 and all them want to
>>download 500MB worth of updates the first time they boot.
>>
>>Yes, I could use a local Fedora mirror. And, in fact,
>>I do. But then I'd have to customize the yum config on
>>all clients to go look there.
>
>You can add your local private mirror to mirrormanager, add a netblock
>that covers your address space, and all your clients will then pull
>from your local mirror rather than public mirrors, with no change on
>the clients.
>
>https://admin.fedoraproject.org/mirrormanager
>http://fedoraproject.org/wiki/Infrastructure/Mirroring
(My definition of 'local' = in the same country or region of
countries. As shown in later messages, others want to create custom
repositories for organization's internal use, but that requires
different tools.)
Even better would be that only local mirrors would be shown
automatically. Nowadays, countries with less than 3 mirrors don't get
this optimization.
This would require rather simple updates to the
http://mirrors.fedoraproject.org/mirrorlist script.
I really don't want to trust that the only mirror in a given country
is active and fully up-to-date, and send everyone from that country to
that single mirror. The thresshold is 3 per country to provide some
reasonable guarantee that at least one of those 3 is active and
up-to-date at any given instance.
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
8:21 a.m.
New subject: The updates firehose - automatic local mirrors
On Mon, Jun 11, 2007 at 08:08:30AM -0500, Matt Domsch wrote:
> This would require rather simple updates to the
> http://mirrors.fedoraproject.org/mirrorlist script.
I really don't want to trust that the only mirror in a given country
is active and fully up-to-date, and send everyone from that country to
that single mirror. The thresshold is 3 per country to provide some
reasonable guarantee that at least one of those 3 is active and
up-to-date at any given instance.
Isn't that reasonable guarantee already the report_mirror data or
crawler acquired data?
Looking at current http://mirrors.fedoraproject.org/publiclist/Fedora/7/
there are only very few countries for which non-global list is used
(unlike FC6 times):
Canada, Germany, Spain, France, Greece, Japan, Netherlands, Romania, USA
E.g. Czech Rep. used to be listed, but supposedly two of the mirrors
were kicked out for not being 100% up2date by the crawler and now we
have just 2 mirrors, both stable though.
Jakub
8:43 a.m.
New subject: The updates firehose - automatic local mirrors
On Mon, Jun 11, 2007 at 09:21:00AM -0400, Jakub Jelinek wrote:
On Mon, Jun 11, 2007 at 08:08:30AM -0500, Matt Domsch wrote:
> > This would require rather simple updates to the
> > http://mirrors.fedoraproject.org/mirrorlist script.
>
> I really don't want to trust that the only mirror in a given country
> is active and fully up-to-date, and send everyone from that country to
> that single mirror. The thresshold is 3 per country to provide some
> reasonable guarantee that at least one of those 3 is active and
> up-to-date at any given instance.
Isn't that reasonable guarantee already the report_mirror data or
crawler acquired data?
Looking at current http://mirrors.fedoraproject.org/publiclist/Fedora/7/
there are only very few countries for which non-global list is used
(unlike FC6 times):
Canada, Germany, Spain, France, Greece, Japan, Netherlands, Romania, USA
E.g. Czech Rep. used to be listed, but supposedly two of the mirrors
were kicked out for not being 100% up2date by the crawler and now we
have just 2 mirrors, both stable though.
For my systems I use something like country=GB,FR to avoid getting the
global list. How hard will it be instead of returning the global list
to check if there are enough near by countries (same continent for
example) to satisfy the thresshold and only return those?
Kostas
8:59 a.m.
New subject: The updates firehose - automatic local mirrors
On Mon, Jun 11, 2007 at 02:43:18PM +0100, Kostas Georgiou wrote:
For my systems I use something like country=GB,FR to avoid getting
the
global list. How hard will it be instead of returning the global list
to check if there are enough near by countries (same continent for
example) to satisfy the thresshold and only return those?
See my last note I just sent - if someone helps with the python-GeoIP
code, I can make mirrormanager handle the same-continent thing quite
easily.
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
8:58 a.m.
New subject: The updates firehose - automatic local mirrors
On Mon, Jun 11, 2007 at 09:21:00AM -0400, Jakub Jelinek wrote:
On Mon, Jun 11, 2007 at 08:08:30AM -0500, Matt Domsch wrote:
> > This would require rather simple updates to the
> > http://mirrors.fedoraproject.org/mirrorlist script.
>
> I really don't want to trust that the only mirror in a given country
> is active and fully up-to-date, and send everyone from that country to
> that single mirror. The thresshold is 3 per country to provide some
> reasonable guarantee that at least one of those 3 is active and
> up-to-date at any given instance.
Isn't that reasonable guarantee already the report_mirror data or
crawler acquired data?
Looking at current http://mirrors.fedoraproject.org/publiclist/Fedora/7/
there are only very few countries for which non-global list is used
(unlike FC6 times):
Canada, Germany, Spain, France, Greece, Japan, Netherlands, Romania, USA
E.g. Czech Rep. used to be listed, but supposedly two of the mirrors
were kicked out for not being 100% up2date by the crawler and now we
have just 2 mirrors, both stable though.
It's a lot better, yes, but it's not guaranteed. The crawler takes
nearly 12 hours to get through all the mirror hosts.
Tell you what. I need three changes, and we can make this a lot
better.
1) python-GeoIP needs to export the countrycode->continent mapping
table, so we can list other mirrors on the same continent at least
if the country has <3 hosts. The code is in GeoIP, it's just not
exported via python-GeoIP, and my Python C-binding foo is weak.
I'd like the countrycode->countryname (e.g. FI -> 'Finland')
mapping exported as well, so I can display the country names rather
than just the country codes.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243696
filed to track this.
2) mirrormanager mirrorlist algorithm adds an extra step. If there
are 3 or more mirrors in a country, return all those. If not, add
in mirrors on the same continent. If still <3, add in the global
list.
In addition, mirrormanager then returns the mirrorlist in priority
order, so the country-specific mirrors appear first, then the
same-continent, then global if necessary. For each geographic
circle, randomize that sub-list so we get the same behavior as yum
failovermethod=roundrobin, but we don't rely on yum for help.
3) Jesse releases a new fedora-release RPM that adds
failovermethod=priority
to each of the [repository] sections.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243698
filed to track this.
So, if someone can help with 1) above, the other two should be easy.
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
11:01 p.m.
Bernardo Innocenti <bernie <at> codewiz.org> writes:
I don't complain when it happens with my own computer that's
being updated daily... but it's painful when you update a
dozen of desktops in the office to F7 and all them want to
download 500MB worth of updates the first time they boot.
Or, Fedora could do a gold release (i.e. released on the release day) and then
have "unofficial" weekly install snapshots, done automatically and not passed
through any sort of testing, based on current RPMS, so that all you need to do
is download that current install ISO and you're off. If it works, OK, if it
doesn't, you can always go to the gold release that's been tested and then apply
updates.
--
Bojan
6:51 a.m.
On Sunday 10 June 2007 00:01:57 Bojan Smojver wrote:
Or, Fedora could do a gold release (i.e. released on the release day)
and
then have "unofficial" weekly install snapshots, done automatically and not
passed through any sort of testing, based on current RPMS, so that all you
need to do is download that current install ISO and you're off. If it
works, OK, if it doesn't, you can always go to the gold release that's been
tested and then apply updates.
Except people aren't going to understand that it's a fire and forget iso set,
and thus our bug spam and bad press is going to sky rocket because the
release didn't work.
--
Jesse Keating
Release Engineer: Fedora
11:27 p.m.
Christopher Blizzard wrote:
> Are people complaining?
I don't complain when it happens with my own computer that's
being updated daily... but it's painful when you update a
dozen of desktops in the office to F7 and all them want to
download 500MB worth of updates the first time they boot.
Yes, I could use a local Fedora mirror. And, in fact,
I do. But then I'd have to customize the yum config on
all clients to go look there.
Add the updates repo at upgrade/install time.
- Orion
5:15 a.m.
orion(a)cora.nwra.com wrote:
> Christopher Blizzard wrote:
>
>> Are people complaining?
> I don't complain when it happens with my own computer that's
> being updated daily... but it's painful when you update a
> dozen of desktops in the office to F7 and all them want to
> download 500MB worth of updates the first time they boot.
>
> Yes, I could use a local Fedora mirror. And, in fact,
> I do. But then I'd have to customize the yum config on
> all clients to go look there.
>
Add the updates repo at upgrade/install time.
Is this currently possible? I've just upgraded a load of servers from
FC6 to F7 and saw no option to add in extra repositories. This was a
text based nfs upgrade.
I remember hearing that including extra repository support in anaconda
was slated for F7, but is this installs only?
Simon.
11:16 a.m.
Simon Andrews wrote:
orion(a)cora.nwra.com wrote:
>
> Add the updates repo at upgrade/install time.
Is this currently possible? I've just upgraded a load of servers from
FC6 to F7 and saw no option to add in extra repositories. This was a
text based nfs upgrade.
Support was added in FC6. Looks like from Jesse's email you need to be
doing a network install. Also, there is a bug when doing nfs installs
that requires *lots* of memory to do an install. I've switched to http
as a result.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
3:49 p.m.
On 6/9/07, Christopher Blizzard <blizzard(a)redhat.com> wrote:
We're not RHEL. If an update is a good one I would rather have
it go
out than not.
As a maintainer, I'd appreciate some reasonable best practices to
consider when pushing an update however. Guidance easily found to read
over when interacting with bodhi. If I've got a bug report for a
missing dep at the packaging level for example, is it worth pushing?
Are all patchable non-crasher non-security application bugs worth
pushing as individual updates or is it better to sit on some of them,
do a build in koji and let the original reporter eat the koji package
if possible?
On a less personal perspective.. i wonder about unity re-spins. Would
re-spins be easier or harder for unity to do if we attempted to stage
updates in periodically produced lumps (in a consensus sort of
gentlemanly, we'll try real hard but we aren't going to hold anyone's
feet to the fire sort of way.)
-jef"Do we have stats on relative number of updates compared to the
number of new components entering the tree"spaleta
4:27 p.m.
On Sa Juni 9 2007, Jeff Spaleta wrote:
do a build in koji and let the original reporter eat the koji
package
if possible?
Before recommending this procecure, imho koji packages should be signed or at
least be available over https for people without a Fedora account.
Regards,
Till
7:28 p.m.
Jeff Spaleta wrote:
On 6/9/07, Christopher Blizzard <blizzard(a)redhat.com> wrote:
> We're not RHEL. If an update is a good one I would rather have it go
> out than not.
As a maintainer, I'd appreciate some reasonable best practices to
consider when pushing an update however. Guidance easily found to read
over when interacting with bodhi. If I've got a bug report for a
missing dep at the packaging level for example, is it worth pushing?
Are all patchable non-crasher non-security application bugs worth
pushing as individual updates or is it better to sit on some of them,
do a build in koji and let the original reporter eat the koji package
if possible?
I agree with this. I also think the packager should take into account
the size of the package. It doesn't bother me too much if some 100K
package is updated every week, but it seemed to me like openoffice.org
was updated 5-10 times during FC-6. I've got a high bandwidth
connection, and it was still annoying enough to make me start looking at
changelogs before I updated.
Quentin
7:56 p.m.
>>>> "QS" == Quentin Spencer
<qspencer(a)ieee.org> writes:
QS> It doesn't bother me too much if some 100K package is updated
QS> every week, but it seemed to me like openoffice.org was updated
QS> 5-10 times during FC-6.
But also consider that openoffice.org is one of our high-profile
applications, and that bugs in it affect a significant portion of the
user base.
I think that most of the updates we're seeing are:
1) New packages. We're burning through the review queue but we still
have hundreds backlogged. All of the packages that are built for
F-7 will generate an update announcement.
2) Updates to packages that, frankly, almost nobody has installed.
Yes, there are a ton of updates, but we have thousands upon
thousands of maintained packages. Most users who run the regular
update tools simply won't see the vast majority of these updates.
(People who install everything, however, get what they
deserve/explicitly requested.) It just looks like a massive amount
on the mailing list.
One useful bit might be to use a different notice for new packages.
That way you can look for "security" first, "new package" to see if
it's something that interests you and ignore everything else. We
might also elect to give people a list that just gets security update
notices.
- J<
8:10 p.m.
Jason L Tibbitts III <tibbs <at> math.uh.edu> writes:
One useful bit might be to use a different notice for new packages.
That way you can look for "security" first, "new package" to see if
it's something that interests you and ignore everything else. We
might also elect to give people a list that just gets security update
notices.
That's something which can be done in the updater. For security vs.
non-security, that's what the updates metadata which the old Core updates tool
had and which is being implemented in Bodhi too is for. New packages can be
detected automatically, in fact Synaptic already does this: each time you
update your metadata (apt separates updating metadata from upgrading packages),
you get a list of packages which are new in your repositories. (This also
catches bugs like debuginfo packages suddenly showing up in the regular updates
repository, by the way. :-) This has been fixed now.)
Kevin Kofler
10:08 p.m.
>>>> "KK" == Kevin Kofler
<kevin.kofler(a)chello.at> writes:
KK> That's something which can be done in the updater.
Well, not really. Consider that I administer some hundreds of
desktops, and none of them runs the updater. I have to stage packages
in a local repository and push them to my clients.
But hey, I know how to filter things, so I'm not the primary use case.
- J<
10:34 p.m.
On 09 Jun 2007 19:56:53 -0500, Jason L Tibbitts III <tibbs(a)math.uh.edu> wrote:
1) New packages.
2) Updates to packages that, frankly, almost nobody has installed.
I wish we had quantifiable numbers to go along with this to aid
discussion. If a large majority of the updates really are new
packages or niche package updates then i doubt there's much of a
concern from a userbase pov. But we don't have hard numbers for either
1 or 2.
-jef"If wishes were horses we'd all be eating steak--name the tv show
this quote is from"spaleta
10:45 p.m.
Jeff Spaleta wrote:
On 09 Jun 2007 19:56:53 -0500, Jason L Tibbitts III
<tibbs(a)math.uh.edu>
wrote:
> 1) New packages.
http://cvs.fedora.redhat.com/viewcvs/owners/owners.list?r1=1.2922&r2=...
Should be a decent indication
> 2) Updates to packages that, frankly, almost nobody has
installed.
I wish we had quantifiable numbers to go along with this to aid
discussion. If a large majority of the updates really are new
packages or niche package updates then i doubt there's much of a
concern from a userbase pov. But we don't have hard numbers for either
1 or 2.
-jef"If wishes were horses we'd all be eating steak--name the tv show
this quote is from"spaleta
Firefly?
N.J.
12:08 a.m.
Jeff Spaleta (jspaleta(a)gmail.com) said:
I wish we had quantifiable numbers to go along with this to aid
discussion. If a large majority of the updates really are new
packages or niche package updates then i doubt there's much of a
concern from a userbase pov. But we don't have hard numbers for either
1 or 2.
So, this is something I'd *love* to have - some sort of stats on
how many people have installed package X; useful for doing checks
to see what should or shouldn't be on the DVDs, and so on. I know
the mugshot stats exist, but that's not the same.
Bill
7:31 a.m.
On Monday 11 June 2007 01:08:40 Bill Nottingham wrote:
So, this is something I'd *love* to have - some sort of stats on
how many people have installed package X; useful for doing checks
to see what should or shouldn't be on the DVDs, and so on. I know
the mugshot stats exist, but that's not the same.
And how thrown off is this data by people who install Everything, or all in a
group but never use the data? More important than 'how many people installed
package X' is perhaps "how many people installed package X that wasn't on the
media" and even more importantly "how many people launched package X and what
was X's deps?".
--
Jesse Keating
Release Engineer: Fedora
10:18 a.m.
Jesse Keating (jkeating(a)redhat.com) said:
> So, this is something I'd *love* to have - some sort of
stats on
> how many people have installed package X; useful for doing checks
> to see what should or shouldn't be on the DVDs, and so on. I know
> the mugshot stats exist, but that's not the same.
And how thrown off is this data by people who install Everything
The number of people who do 'yum install *'....
or all in a group but never use the data?
... or actively check every box in comps is almost certainly too small
to affect things.
More important than 'how many people installed
package X' is perhaps "how many people installed package X that wasn't on
the
media"
Right, which is done by gathering how many people installed X, and seeing
if it wasn't on the media. :)
Bill
11:14 a.m.
On Mon, 2007-06-11 at 08:31 -0400, Jesse Keating wrote:
On Monday 11 June 2007 01:08:40 Bill Nottingham wrote:
> So, this is something I'd *love* to have - some sort of stats on
> how many people have installed package X; useful for doing checks
> to see what should or shouldn't be on the DVDs, and so on. I know
> the mugshot stats exist, but that's not the same.
And how thrown off is this data by people who install Everything, or all in a
group but never use the data? More important than 'how many people installed
package X' is perhaps "how many people installed package X that wasn't on
the
media" and even more importantly "how many people launched package X and what
was X's deps?".
Debian's popcon[0] utility does almost exactly that. This would
make a nice counterpart to smolt - where smolt tracks what hardware
people are using, popcon tracks what *software* they're using. It's all
proven, open-source stuff - adding this as a feature for F8 wouldn't be
hard.
On the other hand, I don't want to duplicate code. Since we're already
talking about more Mugshot-y stuff in F8[1], maybe it makes sense to
extend the Mugshot application info-gathering backend to work more like
popcon. Perhaps it would need to be split out from Mugshot so people who
don't care about Mugshot can still opt to collect and submit stats.
Thoughts?
-w
[0] http://popcon.debian.org/
[1] http://fedoraproject.org/wiki/Releases/FeatureBigboard
12:13 p.m.
On Mon, 2007-06-11 at 12:14 -0400, Will Woods wrote:
On Mon, 2007-06-11 at 08:31 -0400, Jesse Keating wrote:
> On Monday 11 June 2007 01:08:40 Bill Nottingham wrote:
> > So, this is something I'd *love* to have - some sort of stats on
> > how many people have installed package X; useful for doing checks
> > to see what should or shouldn't be on the DVDs, and so on. I know
> > the mugshot stats exist, but that's not the same.
>
> And how thrown off is this data by people who install Everything, or all in a
> group but never use the data? More important than 'how many people installed
> package X' is perhaps "how many people installed package X that wasn't
on the
> media" and even more importantly "how many people launched package X and
what
> was X's deps?".
Debian's popcon[0] utility does almost exactly that. This would
make a nice counterpart to smolt - where smolt tracks what hardware
people are using, popcon tracks what *software* they're using. It's all
proven, open-source stuff - adding this as a feature for F8 wouldn't be
hard.
On the other hand, I don't want to duplicate code. Since we're already
talking about more Mugshot-y stuff in F8[1], maybe it makes sense to
extend the Mugshot application info-gathering backend to work more like
popcon. Perhaps it would need to be split out from Mugshot so people who
don't care about Mugshot can still opt to collect and submit stats.
Thoughts?
Linux is gradually approaching 1984.
1:55 p.m.
Ralf Corsepius wrote:
Linux is gradually approaching 1984.
*Asking* users for feedback is not at all similar to 1984's
governmental abuses of liberty. No need for paranoid worries. :)
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I have an existential map; it has 'you are here' written all over it.
-- Steven Wright
2:32 a.m.
Will Woods wrote:
Debian's popcon[0] utility does almost exactly that. This would
make a nice counterpart to smolt - where smolt tracks what hardware
people are using, popcon tracks what *software* they're using. It's all
proven, open-source stuff - adding this as a feature for F8 wouldn't be
hard.
I haven't looked at how popcon works. If you can port it easily that
would be fine. Otherwise adding a optional package listing in Smolt
(changing it from a hardware to system profiler) might also be good.
On the other hand, I don't want to duplicate code. Since
we're already
talking about more Mugshot-y stuff in F8[1], maybe it makes sense to
extend the Mugshot application info-gathering backend to work more like
popcon. Perhaps it would need to be split out from Mugshot so people who
don't care about Mugshot can still opt to collect and submit stats.
Thoughts?
Mugshot folks don't seem to be interested in splitting out code when I
asked in fedora-desktop list. From the description it appears that the
code is not going to useful outside of mugshot. Talk to them again anyway.
Rahul
3:47 p.m.
On Tue, 2007-06-12 at 13:02 +0530, Rahul Sundaram wrote:
Mugshot folks don't seem to be interested in splitting out code
when I
asked in fedora-desktop list. From the description it appears that the
code is not going to useful outside of mugshot. Talk to them again anyway.
I can't think of much from the Mugshot code that would be directly
reusable for package installation stats. Desktop applications people
are interested in (what Mugshot tracks) and RPM packages installed on a
computer are only distantly related.
At least on the client side I'm not sure how much more complicated it
would get than a POST of the output of rpm -qa to a fedora server (i.e.
a few lines of Python) in /etc/cron.whatever.
On the server side I'd just reuse the smolt code.
3:47 p.m.
On Tuesday 12 June 2007 16:47:19 Colin Walters wrote:
I can't think of much from the Mugshot code that would be
directly
reusable for package installation stats. Desktop applications people
are interested in (what Mugshot tracks) and RPM packages installed on a
computer are only distantly related.
At least on the client side I'm not sure how much more complicated it
would get than a POST of the output of rpm -qa to a fedora server (i.e.
a few lines of Python) in /etc/cron.whatever.
It's not about what is installed, but rather what is used. So just getting a
list of packages installed is not helpful (much).
--
Jesse Keating
Release Engineer: Fedora
4:08 p.m.
On Tue, 2007-06-12 at 16:47 -0400, Jesse Keating wrote:
It's not about what is installed, but rather what is used. So
just getting a
list of packages installed is not helpful (much).
I see 3 fairly distinct classes of RPM packages (as I mentioned in
earlier messages with thoughts about how these could be viewed
differently for installation).
* Desktop apps - Mugshot covers this, though of course it
is tied in with the rest of the Mugshot system (getting stacker
notifications, etc) that we could separate out a bit more.
* Developer tools - popcon's measure of atime is probably good enough
* Server software - used == running (service foo status), obviously
How to distinguish whether an RPM package is in one of these 3 cases
would require some heuristics right now I believe.
7:46 a.m.
On Sat, 2007-06-09 at 19:56 -0500, Jason L Tibbitts III wrote:
I think that most of the updates we're seeing are:
1) New packages. We're burning through the review queue but we still
have hundreds backlogged. All of the packages that are built for
F-7 will generate an update announcement.
2) Updates to packages that, frankly, almost nobody has installed.
Yes, there are a ton of updates, but we have thousands upon
thousands of maintained packages. Most users who run the regular
update tools simply won't see the vast majority of these updates.
(People who install everything, however, get what they
deserve/explicitly requested.) It just looks like a massive amount
on the mailing list.
Not knowing the build environment or seeing the insides or being a
packages/maintainer, I would agree with Jason on both accounts above as
the reason for updates.
And #2 is especially dead on. Yes your going to see lots more updates,
or at least the perception, but actually *look* at the updates and see
what they are. More than 25%, if not 50%, are not even the *core*
packages, just addons. Not everyone is updating to those, and I bet not
even 50% of the userbase is even using the addons part. So I wouldn't
worry so much about how many updates.
And besides, I see it all the time, someone reports that "upstream
released a new version, 1.2.3-5", can you please put out an update.
Anyway, just my $.02 (not that it counts or anything hehe)
--
Mike Chambers
Madisonville, KY
"Best little town on Earth!"
7:17 p.m.
On Saturday 09 June 2007 16:32:07 Christopher Blizzard wrote:
Are people complaining?
I don't know. I can't consume #fedora or fedora-list. I'm mostly seeking
opinions with my posting.
Are we actually breaking stuff in the process?
Well, we're still not checking for broken deps, so maybe. Things like
multilib make this somewhat difficult to detect and prevent pushing, or
detect and provide a way to deliver just the security ones, etc... I don't
really know though, I'm off in rawhide land, but the amount of churn on the
release makes it feel like rawhide too.
Are you upset with the amount of bandwith we're eating or just
based on
principal?
Somewhat on principal. The amount of churn in Extras went somewhat unnoticed
to me because there wasn't something like bodhi for them. Now that
everything goes through it it is very apparent that there is an enormous
amount of updates issued.
--
Jesse Keating
Release Engineer: Fedora
12:09 a.m.
Jesse Keating (jkeating(a)redhat.com) said:
> Are you upset with the amount of bandwith we're eating or
just based on
> principal?
Somewhat on principal. The amount of churn in Extras went somewhat unnoticed
to me because there wasn't something like bodhi for them. Now that
everything goes through it it is very apparent that there is an enormous
amount of updates issued.
So, let's just stop sending mail. Problem solved!
(Seriously, I'm thinking that e-mail with its complete lack of categorization
is the wrong method for package updates. Perhaps RSS?)
Bill
10:03 a.m.
Christopher Blizzard wrote:
Are people complaining? Are we actually breaking stuff in the
process?
Since you particularly asked, I will say that the volume of updates is a
problem for me. (Normally I don't believe in complaining about volunteer
efforts, so I would have kept quiet.)
You asked if you were breaking stuff in the process. This morning I was
hit by this problem, which appears to result from the PAM update:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244534
Although actually downgrading the PAM package is easy, it did take a
certain amount of time. I had to work out what was going on, check that
downgrading wouldn't leave my system vulnerable, and so on.
I also eventually gave up trying to use a Wacom tablet with Fedora. Most
times a kernel update came out, the tablet would fail, always in a
slightly different way. It could generally be made to work again, but
eventually I felt it was taking too much time, and went back to a normal
PS/2 mouse.
Are you upset with the amount of bandwith we're eating or just
based on
principal?
Actually the raw bandwidth isn't the important thing for me. The
frustration comes from updates that don't work properly, forcing me to
spend time debugging a system that was previously working.
The perfect solution, IMHO, would be two separate update streams. There
would be a "recommended updates" stream for security patches and fixes
for major bugs. Then there would be an "optional updates" stream for
minor bugs, new upstream versions, that sort of thing. Then I could
install all the recommended updates, but I could leave the optional
updates unless I particularly needed the improved functionality.
It might be that the "recommended updates" are almost identical to the
RHEL fixes, since they would have the same goal.
Pete
1:45 p.m.
Pete Chown wrote:
The perfect solution, IMHO, would be two separate update streams. There
would be a "recommended updates" stream for security patches and fixes
for major bugs. Then there would be an "optional updates" stream for
minor bugs, new upstream versions, that sort of thing. Then I could
install all the recommended updates, but I could leave the optional
updates unless I particularly needed the improved functionality.
Wouldn't the ability to filter updates based on classifications
(security, bug fixes, enhancements etc) provide what you want instead of
separate update streams? yum security plugin provides some of that
already and extending it is what is planned afaik.
Rahul
3:06 a.m.
Rahul Sundaram wrote:
Wouldn't the ability to filter updates based on classifications
(security, bug fixes, enhancements etc) provide what you want instead of
separate update streams?
That would probably be better than what I suggested, actually, as it
would allow for more detailed classification of updates.
Pete
9:19 a.m.
Pete Chown wrote:
Rahul Sundaram wrote:
> Wouldn't the ability to filter updates based on classifications
> (security, bug fixes, enhancements etc) provide what you want instead of
> separate update streams?
That would probably be better than what I suggested, actually, as it
would allow for more detailed classification of updates.
So then you problem is already getting solved sooner or later when the
update system gets the ability to push out the proper metadata. You
might also want to look at the yum-security package meanwhile.
Rahul
2:14 p.m.
Pete Chown <1(a)234.cx> wrote:
[...]
The perfect solution, IMHO, would be two separate update streams.
There
would be a "recommended updates" stream for security patches and fixes
for major bugs. Then there would be an "optional updates" stream for
minor bugs, new upstream versions, that sort of thing. Then I could
install all the recommended updates, but I could leave the optional
updates unless I particularly needed the improved functionality.
The resulting divergence will lead to *two* Fedoras, the "stable branch"
and the "aggressive updates branch". Most users will stay on the first one,
and complain that they don't get all the shiny, new toys that are in the
second one; most developers will track the second branch and let the first
one fall into disrepair. Been there, done that (look for the extensive
discussion and rationale for the "new kernel development model" if you want
to see this in action and the grief it gives). And allowing people to mix
and match gives an even worse quagmire of "Fedora X, with just /this/ mix
of stable/agressive".
Better (try to) make sure that procedures in place give no problems when
updating. We clearly aren't there yet.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
4:09 p.m.
On Sat, 2007-06-09 at 16:05 -0400, Jesse Keating wrote:
Anybody else think we're issuing entirely /way/ too many updates?
We've had
138 "stable" updates, and 177 current "testing" updates. If all
those were
to go stable, we're talking over 300 updates, in just over a week.
Seriously. We're drowning our users in updates. Are all of them really
necessary? I feel like we've got this culture of update whatever/whenever
coming from Extras where it was just fire and forget. While that might be
fun for the maintainer, is it fun for the user? Is it fun for the user with
a slow connection?
Make it easier for users to filter out the updates they don't want then.
4:39 p.m.
Jesse Keating wrote:
Anybody else think we're issuing entirely /way/ too many updates?
We've had
138 "stable" updates, and 177 current "testing" updates. If all
those were
to go stable, we're talking over 300 updates, in just over a week.
Seriously. We're drowning our users in updates. Are all of them really
necessary? I feel like we've got this culture of update whatever/whenever
coming from Extras where it was just fire and forget. While that might be
fun for the maintainer, is it fun for the user? Is it fun for the user with
a slow connection?
I agree that we should attempt to limit somewhat. But people always get
upset at me for not pushing things out. We need to determine a policy
here before you ask people to limit themselves.
7:19 a.m.
On 2007-06-09, 21:39 GMT, Christopher Aillon wrote:
> Seriously. We're drowning our users in updates. Are all of
> them really necessary? I feel like we've got this culture of
> update whatever/whenever coming from Extras where it was just
> fire and forget. While that might be fun for the maintainer,
> is it fun for the user? Is it fun for the user with a slow
> connection?
I agree that we should attempt to limit somewhat. But people
always get upset at me for not pushing things out. We need to
determine a policy here before you ask people to limit
themselves.
And the some idiots make 96 packages to get updated uselessly. Oh
well, I got those 66+MB of updates today as well.
Matej
5:01 p.m.
On Sat, Jun 09, 2007 at 04:05:00PM -0400, Jesse Keating wrote:
Anybody else think we're issuing entirely /way/ too many updates?
We've had
138 "stable" updates, and 177 current "testing" updates. If all
those were
to go stable, we're talking over 300 updates, in just over a week.
But is that different than at FC6 release time (I don't know, but I
assume it was similar if not even more)? We're not really doing
anything different that made updates increase, I would even think that
it is more difficult to pass updates since they have to be pushed
through bodhi.
You only feel like there are that many updates, because they are now
all using bodhi while before F7 only 1/4th (Core) would become visible
that way.
Seriously. We're drowning our users in updates. Are all of
them
really necessary? I feel like we've got this culture of update
whatever/whenever coming from Extras where it was just fire and
forget. While that might be fun for the maintainer, is it fun for
the user? Is it fun for the user with a slow connection?
I think Fedora's success is partly due to being updated that way.
--
Axel.Thimm at ATrpms.net
5:26 a.m.
On 10.06.2007 00:01, Axel Thimm wrote:
On Sat, Jun 09, 2007 at 04:05:00PM -0400, Jesse Keating wrote:
[...]
> Seriously. We're drowning our users in updates. Are all of them
> really necessary? I feel like we've got this culture of update
> whatever/whenever coming from Extras where it was just fire and
> forget. While that might be fun for the maintainer, is it fun for
> the user? Is it fun for the user with a slow connection?
I think Fedora's success is partly due to being updated that way.
<AOL me-too mode>
Strong +1 from me to this!
</AOL me-too mode>
CU
thl
10:08 a.m.
Axel Thimm wrote:
On Sat, Jun 09, 2007 at 04:05:00PM -0400, Jesse Keating wrote:
> Anybody else think we're issuing entirely /way/ too many updates? We've had
> 138 "stable" updates, and 177 current "testing" updates. If all
those were
> to go stable, we're talking over 300 updates, in just over a week.
But is that different than at FC6 release time (I don't know, but I
assume it was similar if not even more)? We're not really doing
anything different that made updates increase, I would even think that
it is more difficult to pass updates since they have to be pushed
through bodhi.
You only feel like there are that many updates, because they are now
all using bodhi while before F7 only 1/4th (Core) would become visible
that way.
> Seriously. We're drowning our users in updates. Are all of them
> really necessary? I feel like we've got this culture of update
> whatever/whenever coming from Extras where it was just fire and
> forget. While that might be fun for the maintainer, is it fun for
> the user? Is it fun for the user with a slow connection?
I think Fedora's success is partly due to being updated that way.
I think the ugpradeability is a factor, but I think you've got it wrong.
If every time someone built a change into rawhide, they also pushed a
fix to F-7 for example because there's a new version of <insert popular
app here>, then what's the point in upgrading to F-8 when that's ready?
Most extras packages have the same version across the board. I
understand the pros of doing that, but do we really want to turn each
Fedora release into the next RHL 7.3?
10:22 a.m.
Hi.
On Sun, 10 Jun 2007 11:08:35 -0400, Christopher Aillon wrote
I think the ugpradeability is a factor, but I think you've got
it
wrong. If every time someone built a change into rawhide, they also
pushed a fix to F-7 for example because there's a new version of
<insert popular app here>, then what's the point in upgrading to F-8
when that's ready?
Well... if the update is in the same branch, I push it to F<stable>, too
(after having had it in rawhide for some time). For example, 1.3.4->1.3.5
will get into F7.
Major version releases do usually not get into F<stable>, unless there
is a very convincing reason. For example, 1.3.5->1.4.0 would get into
rawhide, but probably not into F7.
That's just my style, however.
10:26 a.m.
On So Juni 10 2007, Christopher Aillon wrote:
I think the ugpradeability is a factor, but I think you've got it
wrong.
If every time someone built a change into rawhide, they also pushed a
fix to F-7 for example because there's a new version of <insert popular
app here>, then what's the point in upgrading to F-8 when that's ready?
Holding back updates only to make a new release interesting is not a good
reason imho. But there are sometimes technical reasons, why updates are done
from one release to another. The other way round, when bugs are not fixed
with a new update in a current release but left open until the release is end
of life is much more annoying imho and causes me more problems than often
updates.
Most extras packages have the same version across the board. I
understand the pros of doing that, but do we really want to turn each
Fedora release into the next RHL 7.3?
What was the property of RHL 7.3 you are refering to? I did not use Redhat
then, so I do not know.
Regards,
Till
11:08 a.m.
Till Maas wrote:
On So Juni 10 2007, Christopher Aillon wrote:
> I think the ugpradeability is a factor, but I think you've got it wrong.
> If every time someone built a change into rawhide, they also pushed a
> fix to F-7 for example because there's a new version of <insert popular
> app here>, then what's the point in upgrading to F-8 when that's ready?
Holding back updates only to make a new release interesting is not a good
reason imho. But there are sometimes technical reasons, why updates are done
from one release to another. The other way round, when bugs are not fixed
with a new update in a current release but left open until the release is end
of life is much more annoying imho and causes me more problems than often
updates.
But there are always bugs. Are we going to fix every one? We need to
fix the important ones. I don't think that pulling in every latest
version is important enough against a release.
11:16 a.m.
On Sun, 2007-06-10 at 12:08 -0400, Christopher Aillon wrote:
Till Maas wrote:
> On So Juni 10 2007, Christopher Aillon wrote:
>
>> I think the ugpradeability is a factor, but I think you've got it wrong.
>> If every time someone built a change into rawhide, they also pushed a
>> fix to F-7 for example because there's a new version of <insert popular
>> app here>, then what's the point in upgrading to F-8 when that's
ready?
>
> Holding back updates only to make a new release interesting is not a good
> reason imho. But there are sometimes technical reasons, why updates are done
> from one release to another. The other way round, when bugs are not fixed
> with a new update in a current release but left open until the release is end
> of life is much more annoying imho and causes me more problems than often
> updates.
But there are always bugs. Are we going to fix every one? We need to
fix the important ones. I don't think that pulling in every latest
version is important enough against a release.
+1.
/B
--
Brian Pepple <bpepple(a)fedoraproject.org>
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
12:10 p.m.
On So Juni 10 2007, Christopher Aillon wrote:
But there are always bugs. Are we going to fix every one? We need
to
fix the important ones. I don't think that pulling in every latest
version is important enough against a release.
When an update that fixes an not very important bug causes a lot of work, e.g.
a new python version, than imho it is worth waiting till the next release.
Also, when there are no bug reports from Fedora users, than imho it is also
ok to delay an update. What does a maintainer gain when he maintains an old
version of a package in one release and a newer one in another instead of
maintaining the same new version in both releases? Also there are cases, when
a user cannot easiely upgrade to a new release, e.g. all zope users cannot
use Fedora 7 afaik, because there is no Zope in Fedora 7 anymore. And last
but not least it is also depressing to fill bug reports, when they are
ignored.
Regards,
Till
5:23 p.m.
Till Maas wrote:
On So Juni 10 2007, Christopher Aillon wrote:
> But there are always bugs. Are we going to fix every one? We need to
> fix the important ones. I don't think that pulling in every latest
> version is important enough against a release.
When an update that fixes an not very important bug causes a lot of work, e.g.
a new python version, than imho it is worth waiting till the next release.
Also, when there are no bug reports from Fedora users, than imho it is also
ok to delay an update. What does a maintainer gain when he maintains an old
version of a package in one release and a newer one in another instead of
maintaining the same new version in both releases? Also there are cases, when
a user cannot easiely upgrade to a new release, e.g. all zope users cannot
use Fedora 7 afaik, because there is no Zope in Fedora 7 anymore. And last
but not least it is also depressing to fill bug reports, when they are
ignored.
I never said ignore them. Respond timely. Fix with discretion. Users
for the most part are willing to accept that not every bug is going to
be fixed in the current version.
10:24 p.m.
2007/6/12, Christopher Aillon <caillon(a)redhat.com>:
Till Maas wrote:
> On So Juni 10 2007, Christopher Aillon wrote:
>
>> But there are always bugs. Are we going to fix every one? We need to
>> fix the important ones. I don't think that pulling in every latest
>> version is important enough against a release.
>
> When an update that fixes an not very important bug causes a lot of work, e.g.
> a new python version, than imho it is worth waiting till the next release.
> Also, when there are no bug reports from Fedora users, than imho it is also
> ok to delay an update. What does a maintainer gain when he maintains an old
> version of a package in one release and a newer one in another instead of
> maintaining the same new version in both releases? Also there are cases, when
> a user cannot easiely upgrade to a new release, e.g. all zope users cannot
> use Fedora 7 afaik, because there is no Zope in Fedora 7 anymore. And last
> but not least it is also depressing to fill bug reports, when they are
> ignored.
I never said ignore them. Respond timely. Fix with discretion. Users
for the most part are willing to accept that not every bug is going to
be fixed in the current version.
Are you really sure on that? Its atleast not true for me.
Actually one of the reasons i sticked with fedora back then is to have
a recent system. if it again starts to stall it will result in me
replacing half the system again with my own selfbuilt packages which
is basically the state i had 5 years ago. It would also open a reason
to actually start a 3rd party repository again to get things fixed
that are just stalled.
Basically i think that fedora should really reflect the current state
and that we have systems like yum-presto in place that prevent users
from downloading that big amounts of updates which is relevant for low
bandwidth users.
Personally i still find a few things here or there that are stalled
and that didnt get any updates since a while (see xchat at
releasetime... see libtorrent/rtorrent etc etc).
i think the amount of updates is rather unproblematic if there is a
proper qa process in place to prevent too many regressions.
If i wanted a more freezed state and backports of fixes instead lots
of feature updates i would definitely use a different distro.
regards,
Rudolf Kastl
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
2:36 a.m.
Rudolf Kastl wrote:
>
> I never said ignore them. Respond timely. Fix with discretion. Users
> for the most part are willing to accept that not every bug is going to
> be fixed in the current version.
Are you really sure on that? Its atleast not true for me.
The general releases can't by definition fix every bug. Some of them are
always going to be too intrusive to fix in a "stable" branch.
Rahul
12:12 p.m.
On Sun, Jun 10, 2007 at 11:08:35AM -0400, Christopher Aillon wrote:
Axel Thimm wrote:
>On Sat, Jun 09, 2007 at 04:05:00PM -0400, Jesse Keating wrote:
>>Anybody else think we're issuing entirely /way/ too many updates? We've
>>had 138 "stable" updates, and 177 current "testing" updates.
If all
>>those were to go stable, we're talking over 300 updates, in just over a
>>week.
>
>But is that different than at FC6 release time (I don't know, but I
>assume it was similar if not even more)? We're not really doing
>anything different that made updates increase, I would even think that
>it is more difficult to pass updates since they have to be pushed
>through bodhi.
>
>You only feel like there are that many updates, because they are now
>all using bodhi while before F7 only 1/4th (Core) would become visible
>that way.
>
>>Seriously. We're drowning our users in updates. Are all of them
>>really necessary? I feel like we've got this culture of update
>>whatever/whenever coming from Extras where it was just fire and
>>forget. While that might be fun for the maintainer, is it fun for
>>the user? Is it fun for the user with a slow connection?
>
>I think Fedora's success is partly due to being updated that way.
I think the ugpradeability is a factor, but I think you've got it wrong.
If every time someone built a change into rawhide, they also pushed a
fix to F-7 for example because there's a new version of <insert popular
app here>, then what's the point in upgrading to F-8 when that's ready?
Well, blindly upgrading everything wasn't advocated, but still, we
have 12/13 of the time 3 releases and 1/13 of the time 4 releases to
support and it often makes sense to keep the same version across the
releases (especially for voluntary contributors). If we were only
pushing into rawhide F7 would had been far more buggier as many bugs
had been found and fixed during FC6.
Furthermore this *is* by definition Fedora's style of existance. And
don't look at the former Extras, the kernel from the former Core is
giving the best example: Perhaps one of foure kernel upgrades are due
to security fixes, and the kernel upgrades are one of the worst
nightmares given 3rd party repos offering kernel module packages.
Most extras packages have the same version across the board. I
understand the pros of doing that, but do we really want to turn each
Fedora release into the next RHL 7.3?
I don't quite understand the comparison, but FWIW RHEL 7.3 was a very
popular release, and if we could have each Fedora release as pupular,
then why now. Also we're not turning into anything, Fedora has been
like that at least since mid-FC3 when Fedora Extras launched (and as
said the kernel is the best example for this happening outside of
Extras anyway), nothing has changed other than pushing stuff through
bodhi.
And I still don't see any drawbacks mentioned. F8 not being worth to
upgrade to because F7 is already that good? A (or every) Fedora
release becoming as popular as RHL 7.3 (but maybe I missed what is
being compared)? These are not really arguments against the current
(and old) workflow model in Fedora, but more in favour. :=)
Hey, let's not forget what Fedora is:
The Fedora Project is a Red Hat-sponsored and community-supported open
source project that promotes RAPID DEVELOPMENT of INNOVATIVE open
source software through a collaborative, community effort.
As a community forum for ADVANCED DEVELOPMENT, the Fedora Project
provides EARLY VISIBILITY to the LATEST open source technology and
serves as a PROVING GROUND for technology that may eventually make its
way into Red Hat's fully-supported commercial solutions such as Red
Hat Enterprise Linux.
--
Axel.Thimm at ATrpms.net
8:06 p.m.
Jesse Keating <jkeating <at> redhat.com> writes:
Seriously. We're drowning our users in updates. Are all of them
really
necessary? I feel like we've got this culture of update whatever/whenever
coming from Extras where it was just fire and forget. While that might be
fun for the maintainer, is it fun for the user? Is it fun for the user with
a slow connection?
The many updates are really Fedora's strength, and the one reason I can run a
stable distro. :-) I don't want old software with known bugs which are already
fixed upstream, and sometimes feature upgrades are also possible without
breaking things (think leaf applications here, or backwards-compatible library
upgrades like KDE 3.4.2->3.5.0 was, but of course not core libraries with an
soname bump ;-) ) so I'd like to have them. Otherwise I'd have to run an
unstable distribution like Rawhide and those are subject to the usual
dependency breakages and such.
Fedora is usually pretty good about pushing things which break stuff (because
they're still under development) to Rawhide only while still pushing many
updates which work fine to the stable release. I'm pretty sure many people
picked Fedora for that reason. There's plenty of other distributions which
follow strict "security fixes and critical bugfixes only" policies, Red Hat
even produces such a distribution (and people who don't want to pay for it can
use CentOS or Scientific Linux), so IMHO if that's what the users want, that's
what they should be pointed to. Throwing away the frequent upgrades would be
losing Fedora's main "selling" point.
I also love it when there's a newsitem about KOffice at dot.kde.org and I can
comment that the new version is already in F7 updates-testing and will be in
updates soon. That whereas all the other distros only offer the new version in
some strange per-package repository (which doesn't scale, you end up with
hundreds of repos if you want all your packages up to date, and who knows how
many conflicts) or not at all.
As for slow connections, I think a combination of deltarpms and filters like
yum-security can help a lot.
Kevin Kofler
4:34 a.m.
Michael Schwendt wrote:
On Sun, 10 Jun 2007 01:06:39 +0000 (UTC), Kevin Kofler wrote:
> The many updates are really Fedora's strength,
... and also one of its weaknesses, since the users don't like it at all
if an update breaks something.
This is one thing I suspect is being lost in all the talk about trust
and freedom. Maintainer's freedom doesn't mean much if there is a
avalanche of updates where updates-testing time can be reduced or
skipped any time and where every update increases the chances of
breaking stuff
Anyone wants to write a policy on updates?
Rahul
5:11 a.m.
Rahul Sundaram wrote:
Michael Schwendt wrote:
> On Sun, 10 Jun 2007 01:06:39 +0000 (UTC), Kevin Kofler wrote:
>
>> The many updates are really Fedora's strength,
>
> ... and also one of its weaknesses, since the users don't like it at all
> if an update breaks something.
This is one thing I suspect is being lost in all the talk about trust
and freedom. Maintainer's freedom doesn't mean much if there is a
avalanche of updates where updates-testing time can be reduced or
skipped any time and where every update increases the chances of
breaking stuff
Here we go again. Before regulating everything to dead, first please try to
objectively measure that which you are trying to regulate, then analyze those
objective measurements, deducting whats working well and what isn't and then
try to steer things, using little adjustments so that what isn't working well
becomes better without causing regressions all over the place.
More to the point, the last couple of releases extras updates and even extras
rolling release model have been causing not all that many upgrade issues /
pains. Yes there are things to improve, like not allowing updates which will
result in broken dep chains. But overall extras didn't do all that bad. Most of
time there is an update which causes all kinda troubles its a former core
update and not a former extras update.
Regards,
Hans (who has queued only 2 updates on 125+ packages, since F-7 release).
5:53 a.m.
Hans de Goede wrote:
More to the point, the last couple of releases extras updates and even
extras rolling release model have been causing not all that many upgrade
issues / pains. Yes there are things to improve, like not allowing
updates which will result in broken dep chains. But overall extras
didn't do all that bad. Most of time there is an update which causes all
kinda troubles its a former core update and not a former extras update.
Setting aside the fact that I didn't claim that core packages weren't
doing any better, core and extras packages weren't on the same footing
for end users before. None of the extras packages were being installed
by default or available in the media that limits its impact significantly.
Rahul
5:14 a.m.
On Sun, Jun 10, 2007 at 03:04:32PM +0530, Rahul Sundaram wrote:
Michael Schwendt wrote:
>On Sun, 10 Jun 2007 01:06:39 +0000 (UTC), Kevin Kofler wrote:
>
>>The many updates are really Fedora's strength,
>
>... and also one of its weaknesses, since the users don't like it at all
>if an update breaks something.
This is one thing I suspect is being lost in all the talk about trust
and freedom. Maintainer's freedom doesn't mean much if there is a
avalanche of updates where updates-testing time can be reduced or
skipped any time and where every update increases the chances of
breaking stuff
Anyone wants to write a policy on updates?
And very shortly you're going to be asking for a policy to be written which
defines when the maintainers are going to be allowed to have bowel movements,
aren't you?
The strengths of Fedora are its leading (even bleeding, at times) edge software
and its maintainers. I had hoped that the merge would lead to more freedom and
faster throughput for new software, but it looks as though we're on the verge
of a coup by anal, hide-bound, corporate control freaks. (<- hyperbole, but it
worries me)
Please folks - if you're going to build a community, make sure that you have only
the governance that is necessary and NO MORE! Leave the maintainers (who have been
appointed to look after the packages) to do their jobs. Address mistakes and issues
on a case-by-case basis and don't hamstring everyone with a bunch of pettifogging
rules.
--
Cheers! (Relax...have a homebrew)
Neil
THEOREM: VI is perfect.
PROOF: VI in roman numerals is 6. The natural numbers < 6 which divide 6 are
1, 2, and 3. 1+2+3 = 6. So 6 is a perfect number. Therefore, VI is perfect.
QED
-- Arthur Tateishi
5:50 a.m.
Neil Thompson wrote:
And very shortly you're going to be asking for a policy to be written which
defines when the maintainers are going to be allowed to have bowel movements,
aren't you?
Completely Unrelated.
The strengths of Fedora are its leading (even bleeding, at times) edge software
and its maintainers. I had hoped that the merge would lead to more freedom and
faster throughput for new software, but it looks as though we're on the verge
of a coup by anal, hide-bound, corporate control freaks. (<- hyperbole, but it
worries me)
Who exactly are you calling that?
Please folks - if you're going to build a community, make sure
that you have only
the governance that is necessary and NO MORE! Leave the maintainers (who have been
appointed to look after the packages) to do their jobs. Address mistakes and issues
on a case-by-case basis and don't hamstring everyone with a bunch of pettifogging
rules.
Updates policy has been requested before by community folks too. You
don't even have to necessarily change your current practises. Just
document them explicitly.
Rahul
6:05 a.m.
For the record, I'm a community guy requesting a policy on updates.
Leaving it up to the packagers is fine if the packagers feel confident
that they can themselves decide on the best updates policy for users for
each package, I'm not that confident. I'd like to see some guidelines on
when to push updates for certain types of packages, simply because I
just don't know what makes sense.
And I feel really guilty, I alone am responsible for 22 of the updates
in updates-testing, of which 21 are new packages that didn't make it in
before the merge. Then again, the rest of the 300 or so packages have
the same new package/real update ratio as mine do, we're only dealing
with a minor number of real updates.
søn, 10.06.2007 kl. 16.20 +0530, skrev Rahul Sundaram:
Neil Thompson wrote:
>
> And very shortly you're going to be asking for a policy to be written which
> defines when the maintainers are going to be allowed to have bowel movements,
> aren't you?
Completely Unrelated.
>
> The strengths of Fedora are its leading (even bleeding, at times) edge software
> and its maintainers. I had hoped that the merge would lead to more freedom and
> faster throughput for new software, but it looks as though we're on the verge
> of a coup by anal, hide-bound, corporate control freaks. (<- hyperbole, but it
> worries me)
Who exactly are you calling that?
> Please folks - if you're going to build a community, make sure that you have
only
> the governance that is necessary and NO MORE! Leave the maintainers (who have been
> appointed to look after the packages) to do their jobs. Address mistakes and
issues
> on a case-by-case basis and don't hamstring everyone with a bunch of
pettifogging
> rules.
Updates policy has been requested before by community folks too. You
don't even have to necessarily change your current practises. Just
document them explicitly.
Rahul
--
Sindre Pedersen Bjørdal <foolish(a)guezz.net>
- http://www.fedoraproject.org/wiki/SindrePedersenBjordal
2:20 p.m.
On Mon, Jun 11, 2007 at 01:05:51PM +0200, Sindre Pedersen Bjordal wrote:
For the record, I'm a community guy requesting a policy on
updates.
Leaving it up to the packagers is fine if the packagers feel confident
that they can themselves decide on the best updates policy for users for
each package, I'm not that confident. I'd like to see some guidelines on
when to push updates for certain types of packages, simply because I
just don't know what makes sense.
Do you really want a policy or an advice? It will be quite hard to come
up with a policy that matches all the use cases and all the types of
packages and isn't too complex nor bureaucratic.
And I feel really guilty, I alone am responsible for 22 of the
updates
You shouldn't.
--
Pat
8:36 a.m.
On Sun, 2007-06-10 at 12:14 +0200, Neil Thompson wrote:
And very shortly you're going to be asking for a policy to be written which
defines when the maintainers are going to be allowed to have bowel movements,
aren't you?
The strengths of Fedora are its leading (even bleeding, at times) edge software
and its maintainers. I had hoped that the merge would lead to more freedom and
faster throughput for new software, but it looks as though we're on the verge
of a coup by anal, hide-bound, corporate control freaks. (<- hyperbole, but it
worries me)
Please folks - if you're going to build a community, make sure that you have only
the governance that is necessary and NO MORE! Leave the maintainers (who have been
appointed to look after the packages) to do their jobs. Address mistakes and issues
on a case-by-case basis and don't hamstring everyone with a bunch of pettifogging
rules.
Ignoring the abusive language in the above, I think what we need is not
so much rules about what kind of updates are allowed, but a bit more
finegrained classification of updates, plus easy ways to filter by this
classification on the client side, and I mean some easy to use ui in
pup/pirut, not some manually installable and configurable yum plugin.
The current classification we have is just
"bugfix - enhancement - security". It would be nice add some more
categories to this, like "cosmetic" (for minor packaging cleanups like
directory ownership handling), and some way to differentiate by
severity.
9:43 a.m.
On Sun, Jun 10, 2007 at 09:36:59AM -0400, Matthias Clasen wrote:
Ignoring the abusive language in the above, I think what we need is not
Hardly abusive, although I will admit to being somewhat intemperate - I'm
just sick and tired of the midset which attempts to introduce policies and
rules to cover every conceivable (and some not even) eventuality.
so much rules about what kind of updates are allowed, but a bit more
finegrained classification of updates, plus easy ways to filter by this
classification on the client side, and I mean some easy to use ui in
pup/pirut, not some manually installable and configurable yum plugin.
Agreed - that's much more the thing.
The current classification we have is just
"bugfix - enhancement - security". It would be nice add some more
categories to this, like "cosmetic" (for minor packaging cleanups like
directory ownership handling), and some way to differentiate by
severity.
This will pretty much have to be driven by the maintainer, though, as she's
the only person who will have enough knowledge about the package to make those
kind of distinctions. You really don't want to introduce any more approval-type
steps into the process - there'll be even more push-back at that.
--
Cheers! (Relax...have a homebrew)
Neil
THEOREM: VI is perfect.
PROOF: VI in roman numerals is 6. The natural numbers < 6 which divide 6 are
1, 2, and 3. 1+2+3 = 6. So 6 is a perfect number. Therefore, VI is perfect.
QED
-- Arthur Tateishi
10:12 p.m.
On Sun, 2007-06-10 at 09:36 -0400, Matthias Clasen wrote:
The current classification we have is just
"bugfix - enhancement - security". It would be nice add some more
categories to this, like "cosmetic" (for minor packaging cleanups like
directory ownership handling), and some way to differentiate by
severity.
Why would someone push an update for cosmetic issues?
8:19 a.m.
On Sun, 2007-06-10 at 23:12 -0400, Colin Walters wrote:
On Sun, 2007-06-10 at 09:36 -0400, Matthias Clasen wrote:
> The current classification we have is just
> "bugfix - enhancement - security". It would be nice add some more
> categories to this, like "cosmetic" (for minor packaging cleanups like
> directory ownership handling), and some way to differentiate by
> severity.
Why would someone push an update for cosmetic issues?
Because what to consider
cosmetic is largely up to the eye of the
beholder. I for one would consider changes which don't have any impact
on a binary rpm to be cosmetic, and anything else to be "bugfix".
That said, broken permissions/ownerships never are cosmetic, they are
real bug fixes.
Ralf
10:10 a.m.
On Mon, 2007-06-11 at 15:19 +0200, Ralf Corsepius wrote:
On Sun, 2007-06-10 at 23:12 -0400, Colin Walters wrote:
> On Sun, 2007-06-10 at 09:36 -0400, Matthias Clasen wrote:
>
> > The current classification we have is just
> > "bugfix - enhancement - security". It would be nice add some more
> > categories to this, like "cosmetic" (for minor packaging cleanups
like
> > directory ownership handling), and some way to differentiate by
> > severity.
>
> Why would someone push an update for cosmetic issues?
Because what to consider cosmetic is largely up to the eye of the
beholder. I for one would consider changes which don't have any impact
on a binary rpm to be cosmetic, and anything else to be "bugfix".
That said, broken permissions/ownerships never are cosmetic, they are
real bug fixes.
Here is a typical example of what I consider cosmetic:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243689
10:34 a.m.
On Mon, 2007-06-11 at 11:10 -0400, Matthias Clasen wrote:
On Mon, 2007-06-11 at 15:19 +0200, Ralf Corsepius wrote:
> On Sun, 2007-06-10 at 23:12 -0400, Colin Walters wrote:
> > On Sun, 2007-06-10 at 09:36 -0400, Matthias Clasen wrote:
> >
> > > The current classification we have is just
> > > "bugfix - enhancement - security". It would be nice add some
more
> > > categories to this, like "cosmetic" (for minor packaging
cleanups like
> > > directory ownership handling), and some way to differentiate by
> > > severity.
> >
> > Why would someone push an update for cosmetic issues?
> Because what to consider cosmetic is largely up to the eye of the
> beholder. I for one would consider changes which don't have any impact
> on a binary rpm to be cosmetic, and anything else to be "bugfix".
>
> That said, broken permissions/ownerships never are cosmetic, they are
> real bug fixes.
Here is a typical example of what I consider cosmetic:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243689
It's an example of what I call bug.
I also consider it granted that you will be going to fix this for FC-7
ASAP.
Ralf
10:46 a.m.
On Monday 11 June 2007 11:34:25 Ralf Corsepius wrote:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243689
It's an example of what I call bug.
I also consider it granted that you will be going to fix this for FC-7
ASAP.
I also consider this a bug. It winds up pulling metacity-devel onto a user's
system when they try to install something that requires metacity. Then all
the depchain of metacity-devel is pulled in as well.
--
Jesse Keating
Release Engineer: Fedora
10:44 a.m.
On Mon, 2007-06-11 at 11:46 -0400, Jesse Keating wrote:
On Monday 11 June 2007 11:34:25 Ralf Corsepius wrote:
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243689
>
> It's an example of what I call bug.
>
> I also consider it granted that you will be going to fix this for FC-7
> ASAP.
I also consider this a bug. It winds up pulling metacity-devel onto a user's
system when they try to install something that requires metacity. Then all
the depchain of metacity-devel is pulled in as well.
Doesn't rpm's grandiose shortest-name-wins rule save us there ?
10:56 a.m.
Matthias Clasen wrote:
On Mon, 2007-06-11 at 11:46 -0400, Jesse Keating wrote:
> I also consider this a bug. It winds up pulling metacity-devel onto a user's
> system when they try to install something that requires metacity. Then all
> the depchain of metacity-devel is pulled in as well.
Fortunately, not many things require metacity, and chances are that the
user isn't going to install it post facto since we install firstboot by
default which has an explicit metacity requirement.
Doesn't rpm's grandiose shortest-name-wins rule save us there
?
Not quite sure, there may be a bug. I accidentally had
firefox-debuginfo providing gecko-devel (along with firefox-devel) and
firefox-devel won all of the time in brew. As soon as we switched to
koji, -debuginfo started to win half the time which is when I noticed
the error. Could be that we switched around the time we got a new rpm
that broke this behavior, I didn't investigate too far...
11:04 a.m.
On Monday 11 June 2007 11:56:21 Christopher Aillon wrote:
Fortunately, not many things require metacity, and chances are that
the
user isn't going to install it post facto since we install firstboot by
default which has an explicit metacity requirement.
The way it came to my attention was somebody trying to use pungi to respin
Fedora. Depsolving brought in all the -devel stuff. Perhaps this is also a
result of how pungi is doing the depsolving as it has to do it differently
than one would do at install time. (IE I can't rely on the metacity already
in the transaction to satisfy a dep of something else as that user may not
actually select metacity, I need to pull in all possible providers of a dep
and have anaconda/yum sort it out at install time based on the packages
selected then).
--
Jesse Keating
Release Engineer: Fedora
12:12 a.m.
New subject: The updates firehose - major updates breaking
On Sun, 10 Jun 2007, Michael Schwendt wrote:
On Sun, 10 Jun 2007 01:06:39 +0000 (UTC), Kevin Kofler wrote:
> The many updates are really Fedora's strength,
... and also one of its weaknesses, since the users don't like it at all
if an update breaks something.
.. and it's not clear if anyone is interested in hearing about such
breakages, or doing anything about them.
For example, 'pan' newsreader broke back in 2006. It was upgraded
from 'stable' train to 'beta'. Unfortunately, the group configuration
is incompatible and you'd need to redo your newsgroups to use it.
Neither upstream or the Fedora Extras maintainer has responded to my
complaints. I suggested that either there needs to be a better
transition path, or the new pan should be shipped as 'pan2' or
something else that won't obsolete the old one. The package is still
broken in this respect.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
10:49 p.m.
Jesse Keating <jkeating <at> redhat.com> writes:
Anybody else think we're issuing entirely /way/ too many updates? We've had
138 "stable" updates, and 177 current "testing" updates. If all
those were
to go stable, we're talking over 300 updates, in just over a week.
Maybe some of those updates aren't really updates, but packages that didn't make
it into F7 final because there was no way to label them as such by maintainers?
I have one such package in updates-testing right now.
Seriously. We're drowning our users in updates. Are all of them
really
necessary? I feel like we've got this culture of update whatever/whenever
coming from Extras where it was just fire and forget. While that might be
fun for the maintainer, is it fun for the user?
Personally, I'm a new software junkie, so I don't mind at all as a user.
Is it fun for the user with
a slow connection?
That may be a real problem. Not sure how many people fall in that category
though. Maybe smolt could also have the "available bandwidth" statistics...
--
Bojan
3:48 a.m.
On Saturday, 09 June 2007 at 22:05, Jesse Keating wrote:
Anybody else think we're issuing entirely /way/ too many updates?
We've had
138 "stable" updates, and 177 current "testing" updates. If all
those were
to go stable, we're talking over 300 updates, in just over a week.
That's normal, I'd say. Same thing happened right after FC6 release.
Seriously. We're drowning our users in updates. Are all of them
really
necessary?
Fedora is known for having the latest software. I'm actually happy to see
those, because it means you haven't killed maintainers' willingness to keep
updating their packages despite adding new hoops to jump through.
I feel like we've got this culture of update whatever/whenever
coming
from Extras where it was just fire and forget.
I feel like you're saying that Core's "culture" (whatever you mean by
that)
should have precedence over Extras' and that "your way" is better than
"our way". I assure you that Extras maintainers didn't just "fire and
forget"
their updates. They were tested. Yes, some accidents happened, but that was
the price of greater freedom the maintainers used to have. So please don't
try to discourage those who managed to put up with all the new obstacles any
further.
While that might be fun for the maintainer, is it fun for the user?
Is
it fun for the user with a slow connection?
Presto.
Regards,
R.
--
Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
6:31 a.m.
On Sunday 10 June 2007 04:48:16 Dominik 'Rathann' Mierzejewski wrote:
I feel like you're saying that Core's "culture"
(whatever you mean by that)
should have precedence over Extras' and that "your way" is better than
"our way". I assure you that Extras maintainers didn't just "fire and
forget" their updates. They were tested. Yes, some accidents happened, but
that was the price of greater freedom the maintainers used to have. So
please don't try to discourage those who managed to put up with all the new
obstacles any further.
I didn't mean to say that Core's was better. Just different. I was mostly
seeking opinions on the matter, not urging change or even expecting it.
--
Jesse Keating
Release Engineer: Fedora
7:06 p.m.
On Sun, 2007-06-10 at 07:31 -0400, Jesse Keating wrote:
On Sunday 10 June 2007 04:48:16 Dominik 'Rathann'
Mierzejewski wrote:
> I feel like you're saying that Core's "culture" (whatever you mean
by that)
> should have precedence over Extras' and that "your way" is better
than
> "our way". I assure you that Extras maintainers didn't just "fire
and
> forget" their updates. They were tested. Yes, some accidents happened, but
> that was the price of greater freedom the maintainers used to have. So
> please don't try to discourage those who managed to put up with all the new
> obstacles any further.
I didn't mean to say that Core's was better. Just different.
Core was
worse ... Core maintainers not shipping updated packages was/is
the reason for me to locally rebuild "up-distro" packages or locally
build patched packages.
Ralf
8:54 a.m.
On Mon, 2007-06-11 at 02:06 +0200, Ralf Corsepius wrote:
On Sun, 2007-06-10 at 07:31 -0400, Jesse Keating wrote:
> On Sunday 10 June 2007 04:48:16 Dominik 'Rathann' Mierzejewski wrote:
> > I feel like you're saying that Core's "culture" (whatever you
mean by that)
> > should have precedence over Extras' and that "your way" is better
than
> > "our way". I assure you that Extras maintainers didn't just
"fire and
> > forget" their updates. They were tested. Yes, some accidents happened,
but
> > that was the price of greater freedom the maintainers used to have. So
> > please don't try to discourage those who managed to put up with all the
new
> > obstacles any further.
>
> I didn't mean to say that Core's was better. Just different.
Core was worse ... Core maintainers not shipping updated packages was/is
the reason for me to locally rebuild "up-distro" packages or locally
build patched packages.
Me too.
We use Fedora in some "non-typical" production environment, hence some
"hidden" bugs affect us from time to time. Any attempt to bugzilla it
(i.e. to share the fixes with other people) does nothing -- we are
compelled to rebuild locally. :(
Sometimes even the "back-porting" of the new "rawhide" package into
the
current used release is enough. It looks a bit strange -- there is a new
upstream stable version, this version works OK, is fully compatible with
the current Fedora release we use, but is present in rawhide only... We
even thought in the past of creating of some "more fast updates for
Core" repository...
Dmitry Butskoy
6:48 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Jun 9, 2007, at 4:05 PM, Jesse Keating wrote:
Anybody else think we're issuing entirely /way/ too many updates?
We've had
138 "stable" updates, and 177 current "testing" updates. If all
those were
to go stable, we're talking over 300 updates, in just over a week.
This doesn't seem so bad to me -- and for the record, yes, I'm on a
very slow and unreliable connection :)
Even if we say that there are 300 updates at this point, that is
still a small percentage of the total number of packages. In my
'Everything' SRPMs directory, I see 4229 packages. That means that
only 7% of packages have been updated (including updates-testing)
since release.
I know that in my case, I would have updated before release but I
waited for the freeze to unthaw -- I'm sure there were many other
packagers in the same boat. The point is, we're bound to see a
larger number of updates just after release than we should expect to
see in general for the lifetime of the release.
- -Jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iD8DBQFGa+UeKe7MLJjUbNMRAp2HAKCHMmfkRyj4C71PZAEWUKE4AUSLoACgt1ZV
4LwGq27vYNcEhXEbGgo3xqo=
=zwjE
-----END PGP SIGNATURE-----
2:50 p.m.
On Sat, Jun 09, 2007 at 04:05:00PM -0400, Jesse Keating wrote:
Anybody else think we're issuing entirely /way/ too many updates?
We've had
138 "stable" updates, and 177 current "testing" updates. If all
those were
to go stable, we're talking over 300 updates, in just over a week.
These numbers are useless, in my opinion. Among those updates how many are
problematic? Still nn my opinion those are not problematic:
* fix important bug
* interesting new features, without important and backward incompatible
changes
* new package
* soname change, but with a compat (including a compat-devel) package
* specialzed software with small userbase and a packager knowing what
he is doing
So, how much left after removing those?
--
Pat
4:17 p.m.
Jesse Keating wrote:
Anybody else think we're issuing entirely /way/ too many updates?
We've had
138 "stable" updates, and 177 current "testing" updates. If all
those were
to go stable, we're talking over 300 updates, in just over a week.
Seriously. We're drowning our users in updates. Are all of them really
necessary? I feel like we've got this culture of update whatever/whenever
coming from Extras where it was just fire and forget. While that might be
fun for the maintainer, is it fun for the user? Is it fun for the user with
a slow connection?
Keep in mind that updates now encompass Core/Extras and *new* added
packages. A better question would be to ask, of the packages users
actually have INSTALLED are updates really churning faster now than
before? I would expect no if you look at Core + Extras of previous
releases.
Presto would be the next important step to formalize to make the
updating process more tolerable to users.
Warren Togami
wtogami(a)redhat.com
5 p.m.
Keep in mind that updates now encompass Core/Extras and *new* added
packages. A better question would be to ask, of the packages users
actually have INSTALLED are updates really churning faster now than
before?
Yes they are. Here's a couple packages that should be rock solid steady that are
being updated *way* to much:
xinetd, tcp_wrappers, bind.
I can cite more, but these should be easily verifiable. The fact that there is a
mad rush to pump out updates says something about the process is broken. Either
the freeze did not let packages that had real problems get fixed, we are not
doing a good enough QA job in rawhide, or people's standards have lowered as to
when to do a release for a stable series.
Presto would be the next important step to formalize to make the
updating process more tolerable to users.
Presto will help download speed, but we still have a problem where too many
updates are being issued in a stable release. Seriously, we need a speedbump to
force some restraint if we don't slow it down. All these updates can cause a
package to get out of sync with SE Linux, which then causes us to rush out a new
SE Linux policy package.
-Steve
____________________________________________________________________________________
The fish are biting.
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php
6:29 p.m.
On Sunday 10 June 2007 17:17:01 Warren Togami wrote:
Keep in mind that updates now encompass Core/Extras and *new* added
packages. A better question would be to ask, of the packages users
actually have INSTALLED are updates really churning faster now than
before? I would expect no if you look at Core + Extras of previous
releases.
Presto would be the next important step to formalize to make the
updating process more tolerable to users.
I know that we're seeing more because previous Extras is going through bodhi
now. The point is that we're noticing how many they are now (: Just seeking
opinions.
--
Jesse Keating
Release Engineer: Fedora
6:38 p.m.
On Sat, 2007-06-09 at 16:05 -0400, Jesse Keating wrote:
Anybody else think we're issuing entirely /way/ too many updates?
No.
We've had
138 "stable" updates, and 177 current "testing" updates. If all
those were
to go stable, we're talking over 300 updates, in just over a week.
Yes, and ...
IMO, this is expected and not unusual.
Seriously. We're drowning our users in updates.
You
aren't, because users will only receive those updated packages they
have install.
Are all of them really
necessary? I feel like we've got this culture of update whatever/whenever
coming from Extras where it was just fire and forget. While that might be
fun for the maintainer, is it fun for the user?
It's partially a consequence of
a "release early/release often policy",
which applied to released packages means "release once a bug is fixed".
Though you repeatedly have stated not to be wanting to accept this kind
of policy, it is the policy which many people (comprising me) consider
the only viable release policy.
Is it fun for the user with a slow connection?
Is Fedora
usable for users with slow connections? No, it has never been
and has always required tricks.
Ralf
7:14 p.m.
On Saturday 09 June 2007 21:05:00 Jesse Keating wrote:
Anybody else think we're issuing entirely /way/ too many updates?
We've
had 138 "stable" updates, and 177 current "testing" updates. If all
those
were to go stable, we're talking over 300 updates, in just over a week.
Jesse you know that due to the freeze policy there are lots of 0-day updates,
I assume that your numbers don't take into account that. So in a sense that
number should represent (more or less) three weeks worth of updates.
Ironically this message remembered me one article by Jon Corbet about RHL y.x
(I don't remember which x and 5<=y<=7) when there were over 100 Mb of updates
since the initial release (one CD at the time), that meant that the updates
represented almost 20% of the original release.
Some years after that post I am still reading (and subscribing) Linux Weekly
News and using a distribution with a high number of updates (and in some
cases being the responsible for them). I like both. :-)
--
José Abílio
3:52 a.m.
Jesse Keating wrote :
Anybody else think we're issuing entirely /way/ too many updates?
We've had
138 "stable" updates, and 177 current "testing" updates. If all
those were
to go stable, we're talking over 300 updates, in just over a week.
Keep in mind that quite a few of those are actually new packages. I
know that I haven't yet had to issue a single "update" to the F7
packages I maintain, but have already gotten a few new ones in ;-)
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3194.fc7
Load : 1.47 1.35 1.29
8:31 p.m.
Jesse Keating wrote:
Anybody else think we're issuing entirely /way/ too many updates?
We've had
138 "stable" updates, and 177 current "testing" updates. If all
those were
to go stable, we're talking over 300 updates, in just over a week.
Seriously. We're drowning our users in updates. Are all of them really
necessary? I feel like we've got this culture of update whatever/whenever
coming from Extras where it was just fire and forget. While that might be
fun for the maintainer, is it fun for the user? Is it fun for the user with
a slow connection?
I'm a user (of my own system, so also an administrator).... here's my 2
cents...
I don't really care if there is a "flood of updates".... I interpret it
as "people are busy" at making my system better. :-) or adding new
things to make other systems better. :-)
What I *would* like (just started thinking about it) is a procmail
recipe to divide the announcement e-mails into "installed" and "not
installed" packages.
For example... I received an e-mail with this subject:
Fedora 7 Update: xorg-x11-server-1.3.0.0-8.fc7
Thats great... very consistent subject patterns, but from a programming
point of view, how do I know where the program name ends (so I can use
it with an rpm -q command to see if it is installed), and where the
version number starts (so I can compare it with the results of rpm -q)?
It would help is there was a blank between program name and version
number... or even more explicit:
Fedora 7 Update: xorg-x11-server Version: 1.3.0.0-8.fc7
ThenI can easily just grab everything between "Update:" and "Version:"
for the program name, and everything aftet "Version:" for the version
number.
Ideally, I'll have procmail divide these announcements into three groups:
1 - program is installed and announcement is advising of newer version
(yum should pick those up automatically when the nightly yum runs)
2 - program is installed and already at/beyond the announced version
(i.e yum update beat the announcement)
3 - program is not installed, but I can look at the announcement to see
if it's something I might be interested in
10:07 p.m.
Don Russell (fedora(a)drussell.dnsalias.com) said:
What I *would* like (just started thinking about it) is a procmail
recipe to divide the announcement e-mails into "installed" and "not
installed" packages.
Well, there's no guarantee that you're reading the mail on the
box in question, etc. Perhaps something utilizing yum-updatesd
might be better?
For example... I received an e-mail with this subject:
Fedora 7 Update: xorg-x11-server-1.3.0.0-8.fc7
Thats great... very consistent subject patterns, but from a programming
point of view, how do I know where the program name ends (so I can use
it with an rpm -q command to see if it is installed), and where the
version number starts (so I can compare it with the results of rpm -q)?
It would help is there was a blank between program name and version
number... or even more explicit:
Fedora 7 Update: xorg-x11-server Version: 1.3.0.0-8.fc7
echo "xorg-x11-server-1.3.0.0-8.fc7" | awk -F '-' '{ print
gensub("-"," ",NF-2) }'
There are certainly simpler ways.
Bill
2:38 a.m.
Bill Nottingham wrote:
Don Russell (fedora(a)drussell.dnsalias.com) said:
> What I *would* like (just started thinking about it) is a procmail
> recipe to divide the announcement e-mails into "installed" and "not
> installed" packages.
>
Well, there's no guarantee that you're reading the mail on the
box in question, etc. Perhaps something utilizing yum-updatesd
might be better?
Actually I can guarantee that because sendmail/procmail runs on my
Fedora box... I access my e-mail via IMAP.
But, I see your point in general applications... if I have F7 on my
laptop for example, that mail-sorting method won't be accurate. But, for
what I want... it's perfect. :-)
> For example... I received an e-mail with this subject:
> Fedora 7 Update: xorg-x11-server-1.3.0.0-8.fc7
>
> Thats great... very consistent subject patterns, but from a programming
> point of view, how do I know where the program name ends (so I can use
> it with an rpm -q command to see if it is installed), and where the
> version number starts (so I can compare it with the results of rpm -q)?
> It would help is there was a blank between program name and version
> number... or even more explicit:
> Fedora 7 Update: xorg-x11-server Version: 1.3.0.0-8.fc7
>
echo "xorg-x11-server-1.3.0.0-8.fc7" | awk -F '-' '{ print
gensub("-"," ",NF-2) }'
There are certainly simpler ways.
Thanks.... I found a way to easily extract the info from the message boy
using native procmail syntax.
10:26 p.m.
Don Russell wrote:
Jesse Keating wrote:
> Anybody else think we're issuing entirely /way/ too many updates?
> We've had 138 "stable" updates, and 177 current "testing"
updates.
> If all those were to go stable, we're talking over 300 updates, in
> just over a week.
>
> Seriously. We're drowning our users in updates. Are all of them
> really necessary? I feel like we've got this culture of update
> whatever/whenever coming from Extras where it was just fire and
> forget. While that might be fun for the maintainer, is it fun for
> the user? Is it fun for the user with a slow connection?
>
I'm a user (of my own system, so also an administrator).... here's my
2 cents...
I don't really care if there is a "flood of updates".... I interpret
it as "people are busy" at making my system better. :-) or adding new
things to make other systems better. :-)
What I *would* like (just started thinking about it) is a procmail
recipe to divide the announcement e-mails into "installed" and "not
installed" packages.
For example... I received an e-mail with this subject:
Fedora 7 Update: xorg-x11-server-1.3.0.0-8.fc7
Thats great... very consistent subject patterns, but from a
programming point of view, how do I know where the program name ends
(so I can use it with an rpm -q command to see if it is installed),
and where the version number starts (so I can compare it with the
results of rpm -q)? It would help is there was a blank between program
name and version number... or even more explicit:
Fedora 7 Update: xorg-x11-server Version: 1.3.0.0-8.fc7
ThenI can easily just grab everything between "Update:" and
"Version:"
for the program name, and everything aftet "Version:" for the version
number.
Ideally, I'll have procmail divide these announcements into three groups:
1 - program is installed and announcement is advising of newer version
(yum should pick those up automatically when the nightly yum runs)
2 - program is installed and already at/beyond the announced version
(i.e yum update beat the announcement)
3 - program is not installed, but I can look at the announcement to
see if it's something I might be interested in
As I started looking into this more, I realized the needed information
(package name, version, etc) are already nicely formatted in the message
body.... so, no need to add a blank in the subject line material. :-)
6149
days inactive
6159
days old
127 comments
58 participants
participants (58)
-
Ahmed Kamal -
Axel Thimm -
Bernie Innocenti -
Bill Nottingham -
Bojan Smojver -
Brian Pepple -
Bruno Wolff III -
Christopher Aillon -
Christopher Blizzard -
Colin Walters -
Dax Kelson -
Dmitry Butskoy -
Dominik 'Rathann' Mierzejewski -
Don Russell -
Gianluca Sforna -
Hans de Goede -
Horst H. von Brand -
Jakub Jelinek -
Jason L Tibbitts III -
Jef Spaleta -
Jeff Sheltren -
Jesse Keating -
Joachim Frieben -
Jonathan Dieter -
José Abílio Matos -
Kevin Kofler -
Kostas Georgiou -
Luke Macken -
Matej Cepl -
Matt Domsch -
Matt Domsch
-
Matthias Clasen -
Matthias Saou -
Michael Schwendt -
Mike Chambers -
Neil Thompson -
Nicolas Mailhot -
Nigel Jones -
Orion Poplawski -
Patrice Dumas -
Paul W. Frields -
Pekka Savola -
Pete Chown -
Quentin Spencer -
Rahul Sundaram -
Ralf Corsepius -
Ralf Ertzinger -
Rudolf Kastl -
seth vidal -
Simon Andrews -
Sindre Pedersen Bjordal -
Steve G -
Thorsten Leemhuis -
Till Maas -
Todd Zullinger -
Tony Nelson -
Warren Togami -
Will Woods