1:49 a.m.
Hi,
A while back, I tried to selectively update some packages and noticed
that the update information provided by package maintainers (seen via
PackageKit) is sorely lacking.
* Update foo to upstream 2.16.2
Was very common, which is practically useless since it doesn't refer to
upstream or downstream bugzillas or feature list or changelog. Would it
be useful to introduce some guidelines to cover this?
Rahul
2:16 a.m.
Rahul Sundaram pisze:
Hi,
A while back, I tried to selectively update some packages and noticed
that the update information provided by package maintainers (seen via
PackageKit) is sorely lacking.
* Update foo to upstream 2.16.2
Was very common, which is practically useless since it doesn't refer to
upstream or downstream bugzillas or feature list or changelog. Would it
be useful to introduce some guidelines to cover this?
Rahul
While I'm always trying to be precise in my update notes, I only
maintain a handful of packages. I can understand how putting verbose
update notes can be a daunting task. Also, what's the problem of going
to upstream website to check what changed in 2.16.2? Or to
/usr/share/doc/foo-2.16.2-1? I think that a more sane reason to put
elaborate update notes would be some packaging changes/patches within
one upstream version.
Btw, how about pulling the data from spec %changelog automatically?
Regards,
Julian
2:28 a.m.
On Mon, Jan 26, 2009 at 9:16 AM, Julian Sikorski <belegdol(a)gmail.com> wrote:
Rahul Sundaram pisze:
> Hi,
>
> A while back, I tried to selectively update some packages and noticed
> that the update information provided by package maintainers (seen via
> PackageKit) is sorely lacking.
>
> * Update foo to upstream 2.16.2
[..]
Btw, how about pulling the data from spec %changelog automatically?
Well in most cases the changelog will just contain the same "update to x.y.z"
For some packages the changes just aren't worth listing.
For example each iw release only contain minor changes, people that
really care about them know how to look it up.
I could also just add "Small fixes and minor updates from upstream"
but that's the same as "Update to x.y.z".
Copying the upstream changelog, that must people do not understand
does not help either.
10:56 a.m.
On Mon, 2009-01-26 at 09:28 +0100, drago01 wrote:
On Mon, Jan 26, 2009 at 9:16 AM, Julian Sikorski
<belegdol(a)gmail.com> wrote:
> Rahul Sundaram pisze:
>> Hi,
>>
>> A while back, I tried to selectively update some packages and noticed
>> that the update information provided by package maintainers (seen via
>> PackageKit) is sorely lacking.
>>
>> * Update foo to upstream 2.16.2
>[..]
> Btw, how about pulling the data from spec %changelog automatically?
Well in most cases the changelog will just contain the same "update to x.y.z"
For some packages the changes just aren't worth listing.
For example each iw release only contain minor changes, people that
really care about them know how to look it up.
I could also just add "Small fixes and minor updates from upstream"
but that's the same as "Update to x.y.z".
Copying the upstream changelog, that must people do not understand
does not help either.
If they're really such minor and uninteresting changes, why push them
out to users? Why consume infrastructure resources to build, releng
resources to sign and push, bandwidth resources to mirror, bandwidth
resources and cpu resources on the clients to consume the metadata, and
cpu / disk resources on the clients to do the update?
If you don't have anything interesting to say about the update, maybe
you shouldn't be pushing the update at all.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
8:29 p.m.
On Mon, Jan 26, 2009 at 08:56:58AM -0800, Jesse Keating wrote:
On Mon, 2009-01-26 at 09:28 +0100, drago01 wrote:
> On Mon, Jan 26, 2009 at 9:16 AM, Julian Sikorski <belegdol(a)gmail.com> wrote:
> > Rahul Sundaram pisze:
> >> Hi,
> >>
> >> A while back, I tried to selectively update some packages and noticed
> >> that the update information provided by package maintainers (seen via
> >> PackageKit) is sorely lacking.
> >>
> >> * Update foo to upstream 2.16.2
> >[..]
> > Btw, how about pulling the data from spec %changelog automatically?
>
> Well in most cases the changelog will just contain the same "update to
x.y.z"
> For some packages the changes just aren't worth listing.
> For example each iw release only contain minor changes, people that
> really care about them know how to look it up.
> I could also just add "Small fixes and minor updates from upstream"
> but that's the same as "Update to x.y.z".
> Copying the upstream changelog, that must people do not understand
> does not help either.
If they're really such minor and uninteresting changes, why push them
out to users? Why consume infrastructure resources to build, releng
resources to sign and push, bandwidth resources to mirror, bandwidth
resources and cpu resources on the clients to consume the metadata, and
cpu / disk resources on the clients to do the update?
All good questions.
If you don't have anything interesting to say about the update,
maybe
you shouldn't be pushing the update at all.
Not only is 'Update foo to upstream 2.16.2' pointless, but that text
lives in both bodhi and koji's databases, the updateinfo.xml in our
repodata, mailing lists, CVS commit logs, and RPM changelogs...
luke
8:47 p.m.
On Mon, Jan 26, 2009 at 6:29 PM, Luke Macken <lmacken(a)redhat.com> wrote:
On Mon, Jan 26, 2009 at 08:56:58AM -0800, Jesse Keating wrote:
> If they're really such minor and uninteresting changes, why push them
> out to users? Why consume infrastructure resources to build, releng
> resources to sign and push, bandwidth resources to mirror, bandwidth
> resources and cpu resources on the clients to consume the metadata, and
> cpu / disk resources on the clients to do the update?
All good questions.
And all obviated by Fedora policy and practice: we expressly give and
expect maintainers to exercise their judgement here.
Unless, of course, we need a Committee of Update Oversight set up...?
Maybe a new set of highly detailed guidelines, detailing when and how
updates are to be blessed and released to the great unwashed, or cast
asunder?
-Chris
--
Chris Weyl
Ex astris, scientia
3:08 a.m.
Chris Weyl wrote:
And all obviated by Fedora policy and practice: we expressly give
and
expect maintainers to exercise their judgement here.
Yes, we let maintainers decide when to push updates, and that's a good
thing. But is it really so hard to write one or two sentences explaining
why your decided that way and what other changes to expect? For me it was
always just a matter of seconds for the updates I submitted. Some users
(like me) want to know what they're getting in an update. I still end up
installing them all unless something is known broken, but that doesn't mean
I don't want to know what I'm getting.
Kevin Kofler
2:30 p.m.
On Tue, Jan 27, 2009 at 1:08 AM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Chris Weyl wrote:
> And all obviated by Fedora policy and practice: we expressly give and
> expect maintainers to exercise their judgement here.
Yes, we let maintainers decide when to push updates, and that's a good
thing. But is it really so hard to write one or two sentences explaining
why your decided that way and what other changes to expect? For me it was
always just a matter of seconds for the updates I submitted. Some users
(like me) want to know what they're getting in an update. I still end up
installing them all unless something is known broken, but that doesn't mean
I don't want to know what I'm getting.
Neither is it difficult to rig something to point automatically at an
included package changelog. Before we mandate a new manual task,
can't we at least try an automated approach first?
-Chris
--
Chris Weyl
Ex astris, scientia
5:03 a.m.
Chris Weyl wrote:
Neither is it difficult to rig something to point automatically at
an
included package changelog. Before we mandate a new manual task,
can't we at least try an automated approach first?
The included changelog is often way too detailed (especially FSF-style
changelogs, see e.g. the GCC one) and it also doesn't give the rationale
why the update is being pushed. And there are also many packages where the
changelog is provided on some web page, not as part of the source code. So
this is no substitute for doing it properly.
Kevin Kofler
1:21 p.m.
Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Chris Weyl wrote:
> Neither is it difficult to rig something to point automatically at an
> included package changelog. Before we mandate a new manual task,
> can't we at least try an automated approach first?
The included changelog is often way too detailed (especially
FSF-style
changelogs, see e.g. the GCC one) and it also doesn't give the rationale
why the update is being pushed. And there are also many packages where the
changelog is provided on some web page, not as part of the source code. So
this is no substitute for doing it properly.
I for one don't think asking (not demanding!) a short paragraph giving the
rationale of doing the new package is too much to ask. The packager must
have some reason for pushing the new version, particularly for a released
branch.
--
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 2340000 Fax: +56 32 2797513
12:04 p.m.
On Mon, 2009-01-26 at 18:47 -0800, Chris Weyl wrote:
And all obviated by Fedora policy and practice: we expressly give
and
expect maintainers to exercise their judgement here.
Unless, of course, we need a Committee of Update Oversight set up...?
Maybe a new set of highly detailed guidelines, detailing when and how
updates are to be blessed and released to the great unwashed, or cast
asunder?
Given that we have maintainers not following the policy, we need to do
something. By having maintainers mention in the update request /why/
they are issuing an update, it's far easier to spot check and verify.
Trust, but verify.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:35 p.m.
2009/1/26 Jesse Keating <jkeating(a)redhat.com>:
On Mon, 2009-01-26 at 09:28 +0100, drago01 wrote:
> On Mon, Jan 26, 2009 at 9:16 AM, Julian Sikorski <belegdol(a)gmail.com> wrote:
> > Rahul Sundaram pisze:
> >> Hi,
> >>
> >> A while back, I tried to selectively update some packages and noticed
> >> that the update information provided by package maintainers (seen via
> >> PackageKit) is sorely lacking.
> >>
> >> * Update foo to upstream 2.16.2
> >[..]
> > Btw, how about pulling the data from spec %changelog automatically?
>
> Well in most cases the changelog will just contain the same "update to
x.y.z"
> For some packages the changes just aren't worth listing.
> For example each iw release only contain minor changes, people that
> really care about them know how to look it up.
> I could also just add "Small fixes and minor updates from upstream"
> but that's the same as "Update to x.y.z".
> Copying the upstream changelog, that must people do not understand
> does not help either.
If they're really such minor and uninteresting changes, why push them
out to users? Why consume infrastructure resources to build, releng
resources to sign and push, bandwidth resources to mirror, bandwidth
resources and cpu resources on the clients to consume the metadata, and
cpu / disk resources on the clients to do the update?
If you don't have anything interesting to say about the update, maybe
you shouldn't be pushing the update at all.
To keep it in sync with upstream, if a update does not hurt end user
(fix small bugs, add features etc) there is no reason to hold it
unless it breaks something.
For example this update allows the user to see if the wireless card
really runs in 802.11n mode (legacy tools like iwconfig does not know
about it).
Sure I should have mentioned this in the text, but for a package with
small changes like this I just bump the release from time to time.
(And no I do not push it once upstream releases a new version but I
just resync with upstream from time to time).
4:20 p.m.
On Tue, 2009-01-27 at 22:35 +0100, drago01 wrote:
To keep it in sync with upstream, if a update does not hurt end
user
(fix small bugs, add features etc) there is no reason to hold it
unless it breaks something.
For example this update allows the user to see if the wireless card
really runs in 802.11n mode (legacy tools like iwconfig does not know
about it).
Sure I should have mentioned this in the text, but for a package with
small changes like this I just bump the release from time to time.
(And no I do not push it once upstream releases a new version but I
just resync with upstream from time to time).
Had you put that information in, users of updates-testing could actually
report whether that change was successful or not, given the wide variety
of wireless drivers out there that people are using. Is that not useful
feedback for upstream? Maybe something in our kernels isn't enabled for
this to work, or some other distro specific side effect. If the users
don't know what to expect/test, how can they ever provide relevant
feedback?
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
12:13 p.m.
On Mon, 2009-01-26 at 09:28 +0100, drago01 wrote:
On Mon, Jan 26, 2009 at 9:16 AM, Julian Sikorski
<belegdol(a)gmail.com> wrote:
> Rahul Sundaram pisze:
>> Hi,
>>
>> A while back, I tried to selectively update some packages and noticed
>> that the update information provided by package maintainers (seen via
>> PackageKit) is sorely lacking.
>>
>> * Update foo to upstream 2.16.2
>[..]
> Btw, how about pulling the data from spec %changelog automatically?
Well in most cases the changelog will just contain the same "update to x.y.z"
For some packages the changes just aren't worth listing.
For example each iw release only contain minor changes, people that
really care about them know how to look it up.
I could also just add "Small fixes and minor updates from upstream"
but that's the same as "Update to x.y.z".
It's the same _to you_, because you know that there are only some minor
number of fixes. But for almost anyone not you it could mean:
. fix for specific bug
. minor fixes
. minor fixes and minor feature or two
. minor fixes and one huge new feature
. lots of new features
...so putting the longer form in there helps everyone else.
Copying the upstream changelog, that must people do not understand
does not help either.
There's a big difference between a "git log"¹, a complete overview
changelog² and something you put in a bodhi update³.
¹
http://yum.baseurl.org/gitweb?p=yum.git;a=shortlog;h=refs/heads/yum-3_2_X
² http://james.fedorapeople.org/yum/yum%20overview%20changelog
³ https://admin.fedoraproject.org/updates/F10/FEDORA-2008-11027
--
James Antill <james(a)fedoraproject.org>
Fedora
3:40 p.m.
On Mon, Jan 26, 2009 at 7:13 PM, James Antill <james(a)fedoraproject.org> wrote:
On Mon, 2009-01-26 at 09:28 +0100, drago01 wrote:
> On Mon, Jan 26, 2009 at 9:16 AM, Julian Sikorski <belegdol(a)gmail.com> wrote:
> > Rahul Sundaram pisze:
> >> Hi,
> >>
> >> A while back, I tried to selectively update some packages and noticed
> >> that the update information provided by package maintainers (seen via
> >> PackageKit) is sorely lacking.
> >>
> >> * Update foo to upstream 2.16.2
> >[..]
> > Btw, how about pulling the data from spec %changelog automatically?
>
> Well in most cases the changelog will just contain the same "update to
x.y.z"
> For some packages the changes just aren't worth listing.
> For example each iw release only contain minor changes, people that
> really care about them know how to look it up.
> I could also just add "Small fixes and minor updates from upstream"
> but that's the same as "Update to x.y.z".
It's the same _to you_, because you know that there are only some minor
number of fixes. But for almost anyone not you it could mean:
. fix for specific bug
. minor fixes
. minor fixes and minor feature or two
. minor fixes and one huge new feature
. lots of new features
...so putting the longer form in there helps everyone else.
OK, you (and Jesse) have valid points, will be more verbose in the future.
Note: For packages that have interesting changes I already *do* put
the info into the update, so its not like I always do "update to
x.y.z"
2:42 a.m.
Julian Sikorski wrote:
While I'm always trying to be precise in my update notes, I only
maintain a handful of packages. I can understand how putting verbose
update notes can be a daunting task. Also, what's the problem of going
to upstream website to check what changed in 2.16.2?
Problem is finding out such information. It isn't easy at all for end
users to do and sometimes doesn't exist in the upstream website. It
would be very useful if package maintainers spend a little bit more time
including more complete descriptions in the updates. Note that, I am
referring here to description that is part of bodhi update and not the
changelog which can be very brief.
Rahul
6:09 p.m.
Rahul Sundaram <sundaram(a)fedoraproject.org> wrote:
Julian Sikorski wrote:
> While I'm always trying to be precise in my update notes, I only
> maintain a handful of packages. I can understand how putting verbose
> update notes can be a daunting task. Also, what's the problem of going
> to upstream website to check what changed in 2.16.2?
Problem is finding out such information. It isn't easy at all for
end
users to do and sometimes doesn't exist in the upstream website. It
would be very useful if package maintainers spend a little bit more
time including more complete descriptions in the updates. Note that, I
am referring here to description that is part of bodhi update and not
the changelog which can be very brief.
The %changelog remains. I'd prefer a decent entry there, and copy that (by
default?) here.
--
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 2340000 Fax: +56 32 2797513
2:49 a.m.
On Mon, 26 Jan 2009, Rahul Sundaram wrote:
Was very common, which is practically useless since it doesn't
refer to
upstream or downstream bugzillas or feature list or changelog. Would it
be useful to introduce some guidelines to cover this?
Well, %changelog should be only used for RPM changes, not for upstream
ones. Something else seems abusing %changelog for me.
Anyway most projects are delivering %doc ChangeLog, %doc Changes, %doc
NEWS. Why is PackageKit not able to handle such things and to show that
changelog or these news?
The only thing looking reasonable to me, would be e.g. a a bugzilla number
after the %changelog entry, which refers to that, but on the other hand why
opening a bug report for each package update?
Finally, I don't get your idea to do things twice.
Instead of that, I really would like to see PackageKit reading Bodhi texts
and not only the bug report numbers. I'm always using the text, I can enter
in Bodhi for upstream and downstream changes. But they're only going to the
mailing lists, not to the PackageKit user - and that's wrong and has to be
changed ASAP. Maybe we can make a guideline for this to cover it...
Greetings,
Robert
3:01 a.m.
Robert Scheck wrote:
On Mon, 26 Jan 2009, Rahul Sundaram wrote:
> Was very common, which is practically useless since it doesn't refer to
> upstream or downstream bugzillas or feature list or changelog. Would it
> be useful to introduce some guidelines to cover this?
Well, %changelog should be only used for RPM changes, not for upstream
ones. Something else seems abusing %changelog for me.
I wasn't talking about changelog at all but update descriptions that are
put out by maintainers via bodhi. These two serve different purposes.
One is brief package changelog meant more developers and other is for
end users and should include upstream changes as well. If you are just
copy pasting changelog information, then, yes PackageKit might as well
as show that but that's not the case.
Rahul
3:23 a.m.
Robert Scheck píše v Po 26. 01. 2009 v 09:49 +0100:
On Mon, 26 Jan 2009, Rahul Sundaram wrote:
> Was very common, which is practically useless since it doesn't refer to
> upstream or downstream bugzillas or feature list or changelog. Would it
> be useful to introduce some guidelines to cover this?
Well, %changelog should be only used for RPM changes, not for upstream
ones. Something else seems abusing %changelog for me.
Anyway most projects are delivering %doc ChangeLog, %doc Changes, %doc
NEWS. Why is PackageKit not able to handle such things and to show that
changelog or these news?
And there is also the URL tag in the spec file.
Dan
10:58 a.m.
On Mon, 2009-01-26 at 09:49 +0100, Robert Scheck wrote:
Instead of that, I really would like to see PackageKit reading Bodhi texts
and not only the bug report numbers. I'm always using the text, I can enter
in Bodhi for upstream and downstream changes. But they're only going to the
mailing lists, not to the PackageKit user - and that's wrong and has to be
changed ASAP. Maybe we can make a guideline for this to cover it...
PackageKit /does/ read the text you input into Bodhi as far as update
notes. It also does read the bug numbers, and categorizes the updates
as you do in bodhi (enhancement, bugfix, security, etc.)
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:08 a.m.
On Mon, 2009-01-26 at 13:19 +0530, Rahul Sundaram wrote:
Hi,
A while back, I tried to selectively update some packages and noticed
that the update information provided by package maintainers (seen via
PackageKit) is sorely lacking.
* Update foo to upstream 2.16.2
Some people don't even put that into Bohdi. I think that some update
text and CVE's should be mandatory and bugzillas should be recommended.
Unless packagers use Bohdi, PackageKit can't really do anything clever
using upstream ChangeLogs and stuff like that.
Richard.
3:26 a.m.
Richard Hughes píše v Po 26. 01. 2009 v 09:08 +0000:
On Mon, 2009-01-26 at 13:19 +0530, Rahul Sundaram wrote:
> Hi,
>
> A while back, I tried to selectively update some packages and noticed
> that the update information provided by package maintainers (seen via
> PackageKit) is sorely lacking.
>
> * Update foo to upstream 2.16.2
Some people don't even put that into Bohdi. I think that some update
text and CVE's should be mandatory and bugzillas should be recommended.
Unless packagers use Bohdi, PackageKit can't really do anything clever
using upstream ChangeLogs and stuff like that.
It should be possible to automagically include "clog" into the bodhi
template when creating the update from the command line.
Dan
3:41 a.m.
Kevin Kofler píše v Po 26. 01. 2009 v 10:31 +0100:
Dan Horák wrote:
> It should be possible to automagically include "clog" into the bodhi
> template when creating the update from the command line.
That doesn't help much because the RPM changelog usually just says "update
to 1.2.3".
But you will have at least this and the main point is that it is done
without manual intervention.
Dan
2:01 p.m.
On Mon, 26 Jan 2009, Richard Hughes wrote:
Some people don't even put that into Bohdi. I think that some
update
text and CVE's should be mandatory and bugzillas should be recommended.
It doesn't make sense to make CVEs mandatory. For packages like phpMyAdmin
and ClamAV security issues the CVEs are often created after the update
happened, so the only thing, I can do there, when preparing the update is
to add the Red Hat Bugzilla ID.
Making CVE mandatory for a bugfix-only or for an enhancement update also
doesn't make any sense.
Greetings,
Robert
6:02 a.m.
On Mon, Jan 26, 2009 at 01:19:56PM +0530, Rahul Sundaram wrote:
Hi,
A while back, I tried to selectively update some packages and noticed
that the update information provided by package maintainers (seen via
PackageKit) is sorely lacking.
* Update foo to upstream 2.16.2
Was very common, which is practically useless since it doesn't refer to
upstream or downstream bugzillas or feature list or changelog. Would it
be useful to introduce some guidelines to cover this?
It looks good to me, users should refer to the package documentation or
to the package url. The only thing I see that could be made mandatory,
would be to associate it with the fedora bugs that were solved by this
update.
Also, if the maintainer knows where the information about the update is
it could be nice to have it in bodhi, but not mandatory. Something like
See some.site.org/release_notes.html for the changes.
or
See /usr/share/doc/foo-1.0/NEWS for the changes.
--
Pat
6:12 a.m.
Also, if the maintainer knows where the information about the update
is
it could be nice to have it in bodhi, but not mandatory. Something like
See some.site.org/release_notes.html for the changes.
or
See /usr/share/doc/foo-1.0/NEWS for the changes.
The first one is nice, but the second one causes a problem: how can
you review the changes _before_ updating if the file listing changes
is inside the updated package ?
You could of course yumdownload the package and install it in some
safe root where you would check the file, but we're talking about
reviewing changes in Bohdi / PackageKit, which means avoiding these
kind of acrobatics.
Regards,
----------
Mathieu Bridon (bochecha)
French Fedora Ambassador
----------
"They who can give up essential liberty to obtain a little temporary
safety, deserve neither liberty nor safety." ~Benjamin Franklin
6:15 a.m.
On Mon, Jan 26, 2009 at 01:12:23PM +0100, Mathieu Bridon (bochecha) wrote:
> Also, if the maintainer knows where the information about the
update is
> it could be nice to have it in bodhi, but not mandatory. Something like
>
> See some.site.org/release_notes.html for the changes.
>
> or
> See /usr/share/doc/foo-1.0/NEWS for the changes.
The first one is nice, but the second one causes a problem: how can
you review the changes _before_ updating if the file listing changes
is inside the updated package ?
You can't. But this is something for upstream, in my opinion.
--
Pat
6:22 a.m.
Patrice Dumas wrote:
On Mon, Jan 26, 2009 at 01:12:23PM +0100, Mathieu Bridon (bochecha)
wrote:
>> Also, if the maintainer knows where the information about the update is
>> it could be nice to have it in bodhi, but not mandatory. Something like
>>
>> See some.site.org/release_notes.html for the changes.
>>
>> or
>> See /usr/share/doc/foo-1.0/NEWS for the changes.
> The first one is nice, but the second one causes a problem: how can
> you review the changes _before_ updating if the file listing changes
> is inside the updated package ?
You can't. But this is something for upstream, in my opinion.
If upstream does it on their own, package maintainers must add pointers
to it. If not, the job of summarizing the need for an update rests with
the package maintainers since they are the ones pushing it to end users.
Package maintainers can help upstream in the process if necessary as
well. Version numbers by themselves don't mean much, if anything at all
since they aren't used consistently across different projects or even
between releases. The whole point of enforcing a description field is
to help end users get more information beyond just version numbers.
Rahul
1:37 p.m.
On Mon, Jan 26, 2009 at 4:22 AM, Rahul Sundaram
<sundaram(a)fedoraproject.org> wrote:
Patrice Dumas wrote:
>
> On Mon, Jan 26, 2009 at 01:12:23PM +0100, Mathieu Bridon (bochecha) wrote:
>>>
>>> Also, if the maintainer knows where the information about the update is
>>> it could be nice to have it in bodhi, but not mandatory. Something like
>>>
>>> See some.site.org/release_notes.html for the changes.
>>>
>>> or
>>> See /usr/share/doc/foo-1.0/NEWS for the changes.
>>
>> The first one is nice, but the second one causes a problem: how can
>> you review the changes _before_ updating if the file listing changes
>> is inside the updated package ?
>
> You can't. But this is something for upstream, in my opinion.
If upstream does it on their own, package maintainers must add pointers to
it. If not, the job of summarizing the need for an update rests with the
package maintainers since they are the ones pushing it to end users. Package
maintainers can help upstream in the process if necessary as well. Version
numbers by themselves don't mean much, if anything at all since they aren't
used consistently across different projects or even between releases. The
whole point of enforcing a description field is to help end users get more
information beyond just version numbers.
Sigh. I hesitate to get in the middle of this one, but...
Let's not make anything more difficult for the package maintainers,
eh? Over the last couple years we've already seen a slew of new
policy, requirements, etc, that make things more onerous for our
(largely UNPAID volunteer) maintainers; I suspect some are still
not-so-happy with having to go through bodhi for that. I know that if
I had to manually touch each update's notes, I'd be very hard pressed
to maintain my packages. Any policy along these lines seems like a
HUGE amount of extra work (every maintainer summarizing a changelog
that may or may not exist for every update) with little added benefit
(those who are likely to be looking at this are those who probably
know how to find and read a changelog; those who don't probably will
just update anyways).
Also, as others have pointed out, the rpm %changelog is the place to
summarize changes to the _delivered_ package, not the program itself.
e.g. "added examples/ to %%doc" or "resolved RHBZ#123456 by excluding
*.a from %%files" would be appropriate in a changelog, whereas "major
changes to the functionality of this version include the new
frobnicate feature of the Fedora Orbital Laser, ..." would be out of
place. Let's not overload %changelog to be something it isn't.
In any case, regardless of this, a couple solutions with little to no
maintainer impact present themselves to me:
1) Have the graphical updater tool present a message like "These are
the package update notes and changes as noted by the packager; for a
comprehensive list please find the package changelog through its
homepage at <url>"
2) Submit such a statement at the head of the bodhi update notes.
I'll be updating my bodhi-enh[1] script to do just this.
-Chris
[1] right now, something like this:
#!/bin/sh
set -ex
REL=`cat branch | sed -e s/-//`
make clog
bodhi -n -c "`cat clog`" -r $REL -t enhancement -R testing `make verrel`
--
Chris Weyl
Ex astris, scientia
1:47 p.m.
Chris Weyl wrote:
Let's not make anything more difficult for the package
maintainers,
eh?
In general, I certainly agree but policies weren't introduced in the
last to make life harder for maintainers but easier for end users and
for a small additional cost to maintainers, we can benefit end users
much more. We are doing a pretty sloppy job with updates and are
providing good information on why those massive amount of updates are
needed for end users. Just simply pushing the latest version isn't a
good reason. There must be a definite need for it and bodhi should have
that information from the package maintainers. I also suggest everyone
to get more co-maintainers. Certainly made life much more easier for me.
Also, as others have pointed out, the rpm %changelog is the place to
summarize changes to the _delivered_ package, not the program itself.
... and I have pointed out repeatedly that I wasn't talking about the
changelog but the description field in bodhi.
Rahul
1:57 p.m.
On Tue, 27 Jan 2009, Rahul Sundaram wrote:
much more. We are doing a pretty sloppy job with updates and are
providing good information on why those massive amount of updates are
needed for end users. Just simply pushing the latest version isn't a
In general, I agree with you. Maintainers must and have to put information
and details into Bodhi when submitting an update. Just "upgrade to xxx" is
not suitable, yes. But there are exceptions sometimes, e.g. when ClamAV or
phpMyAdmin upstream goes crazy again and pushes out the fix, tells "this is
an important security fix, details will follow in the next days or so" as
this already happend multiple times in the past. Usually then, it is a more
bigger security issue with remote impacts which has to pass through without
any stoppers except for or by the Fedora Security team.
So yes, we need some kind of guideline, either some fazit about the update
or the upstream changelog (depends on what is understandable, so gcc, glibc
and friends are also some exceptions, I would guess). On the other hand,
the Bodhi stuff has to be handable for the package maintainer. Speaking for
me and the other unpaid Fedora package maintainers, it is our time, we like
to spend and we spend for the project. Making it unnecessary complicated
shouldn't be the goal at all: Keep it simple, doable and suitable for both
sides: Maintainers and users.
... and I have pointed out repeatedly that I wasn't talking about
the
changelog but the description field in bodhi.
I think, I brought this wrong understanding up a couple of hours ago. I'm
sorry, that I misunderstood you. I was thinking, you are referring to RPM
%changelog, not do Bodhi.
Greetings,
Robert
2:04 p.m.
Robert Scheck wrote:
On Tue, 27 Jan 2009, Rahul Sundaram wrote:
> much more. We are doing a pretty sloppy job with updates and are
> providing good information on why those massive amount of updates are
> needed for end users. Just simply pushing the latest version isn't a
In general, I agree with you. Maintainers must and have to put information
and details into Bodhi when submitting an update. Just "upgrade to xxx" is
not suitable, yes. But there are exceptions sometimes, e.g. when ClamAV or
phpMyAdmin upstream goes crazy again and pushes out the fix, tells "this is
an important security fix, details will follow in the next days or so" as
this already happend multiple times in the past. Usually then, it is a more
bigger security issue with remote impacts which has to pass through without
any stoppers except for or by the Fedora Security team.
I wasn't aware of this. This seems a very odd practise. Why is this
happening?
So yes, we need some kind of guideline, either some fazit about the
update
or the upstream changelog (depends on what is understandable, so gcc, glibc
and friends are also some exceptions, I would guess). On the other hand,
the Bodhi stuff has to be handable for the package maintainer. Speaking for
me and the other unpaid Fedora package maintainers, it is our time, we like
to spend and we spend for the project. Making it unnecessary complicated
shouldn't be the goal at all: Keep it simple, doable and suitable for both
sides: Maintainers and users.
Absolutely. So would you mind drafting a guideline for this? My goal
from this as a end user was just to more intelligently cherry pick
updates (bandwidth issues, cost of connection etc) and some of the
updates give me zero information beyond just semi random version numbers
to do this. Another potential problem is that third party repositories
typically don't make use of bodhi or equivalent so the experience is
very inconsistent across updates.
Rahul
2:22 p.m.
On Tue, 27 Jan 2009, Rahul Sundaram wrote:
Robert Scheck wrote:
> In general, I agree with you. Maintainers must and have to put information
> and details into Bodhi when submitting an update. Just "upgrade to xxx" is
> not suitable, yes. But there are exceptions sometimes, e.g. when ClamAV or
> phpMyAdmin upstream goes crazy again and pushes out the fix, tells "this is
> an important security fix, details will follow in the next days or so" as
> this already happend multiple times in the past. Usually then, it is a more
> bigger security issue with remote impacts which has to pass through without
> any stoppers except for or by the Fedora Security team.
I wasn't aware of this. This seems a very odd practise. Why is this
happening?
Very good question. When asking, I didn't get a real answer. Sometimes, a
public proof of concept exists already. Maybe the intention is, that if
they make the security issue public, the vendors had time to put updated
packages into their systems. Luckily, that doesn't happen all the time, but
only sometimes. If you click through my phpMyAdmin updates, you will find
some bug reports referencing "not yet clearly specified security issue" or
similar things. Much more can a packager not do, I would guess.
Greetings,
Robert
2:36 p.m.
Robert Scheck wrote:
Very good question. When asking, I didn't get a real answer. Sometimes, a
public proof of concept exists already. Maybe the intention is, that if
they make the security issue public, the vendors had time to put updated
packages into their systems. Luckily, that doesn't happen all the time, but
only sometimes. If you click through my phpMyAdmin updates, you will find
some bug reports referencing "not yet clearly specified security issue" or
similar things. Much more can a packager not do, I would guess.
Maybe you can take this up to
http://lists.freedesktop.org/mailman/listinfo/distributions
Collectively apply some pressure to upstream or atleast find good
consistent workarounds.
Rahul
3:43 p.m.
Robert Scheck wrote:
In general, I agree with you. Maintainers must and have to put
information
and details into Bodhi when submitting an update. Just "upgrade to xxx" is
not suitable, yes. But there are exceptions sometimes, e.g. when ClamAV or
phpMyAdmin upstream goes crazy again and pushes out the fix, tells "this
is an important security fix, details will follow in the next days or so"
as this already happend multiple times in the past. Usually then, it is a
more bigger security issue with remote impacts which has to pass through
without any stoppers except for or by the Fedora Security team.
diff -Nur foo-old foo-new
and you'll see fairly quickly what they fixed. (And it's also trivial for a
cracker to do that, so it's utterly pointless to try withholding
information that way.)
Kevin Kofler
5:03 p.m.
On Mon, 26 Jan 2009, Kevin Kofler wrote:
diff -Nur foo-old foo-new
and you'll see fairly quickly what they fixed. (And it's also trivial for a
cracker to do that, so it's utterly pointless to try withholding
information that way.)
In theory, yes. But nearly always, these upstreams are putting the security
fixes into the forward development. Further development, sometimes even
code rewrites after last stable release and somewhen a security fix doesn't
make it readable that easy (unified diff can be ~ 2500-7500 lines). For PHP
that might be readable easily, but when not being a C coder, reading/seeing
an overflow, memory games or other leaks might be more hard in such a diff.
Greetings,
Robert
5:22 p.m.
Kevin Kofler wrote:
diff -Nur foo-old foo-new
and you'll see fairly quickly what they fixed. (And it's also trivial for a
cracker to do that, so it's utterly pointless to try withholding
information that way.)
I disagree.
I recently fixed something that could be considered "denial of service"
in a program I maintain. The patch basically replaces some instances of
"foo=object; object.incrementRefCount();' with 'foo=object.clone();'.
I'd challenge you to figure out from just that how to exploit the
problem, whereas the bug report might contain a detailed description of
what you had to do, how the timing has to work out, and exactly what
effect would be seen.
There's a difference between having to engineer an exploit from the
patch (especially if even the commit is vaguely worded), and having full
documentation on the problem and its cause.
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
find / -user your -name base -print0 | xargs -0 chown us:cats -- Unknown
2:06 p.m.
On Mon, Jan 26, 2009 at 11:47 AM, Rahul Sundaram
<sundaram(a)fedoraproject.org> wrote:
Chris Weyl wrote:
> Let's not make anything more difficult for the package maintainers,
> eh?
In general, I certainly agree but policies weren't introduced in the last to
make life harder for maintainers but easier for end users and for a small
additional cost to maintainers, we can benefit end users much more. We are
doing a pretty sloppy job with updates and are providing good information on
why those massive amount of updates are needed for end users. Just simply
pushing the latest version isn't a good reason. There must be a definite
need for it and bodhi should have that information from the package
maintainers. I also suggest everyone to get more co-maintainers. Certainly
made life much more easier for me.
It's hardly a "small additional cost", especially when looked at in
aggregate; this would be an additional non-automateable step required
for every update release that is of very questionable value/utility to
the vast majority of our users. I realize it would make your life
easier, but is it worth an additional imposition on our already
highly-regulated maintainers just to make your life easier? I stand
by my earlier assessment that the vast bulk of our users could care
less, and those that do care would know how to find a package's
changelog. If this is important, we should find some way of
automatically including a pointer to upstream's changelog in the
update tool itself.
Basically, this seems to be "I don't really trust the package
maintainer's decision on why I should upgrade, so I want to know what
changes this introduces." Which is absolutely fine -- and also when
someone should be reading upstream's changelog to understand the
changes introduced by upstream. In terms of the spec changes as
documented in %changelog, "updated to version x.y.z" is all the
justification needed as to why the new level was built and released;
what actually changed in that new level is the purview of the upstream
maintainer.
> Also, as others have pointed out, the rpm %changelog is the place
to
> summarize changes to the _delivered_ package, not the program itself.
... and I have pointed out repeatedly that I wasn't talking about the
changelog but the description field in bodhi.
Not all pontifications are specifically aimed your way :-)
-Chris
--
Chris Weyl
Ex astris, scientia
2:19 p.m.
Chris Weyl wrote:
It's hardly a "small additional cost", especially when looked at in
aggregate; this would be an additional non-automateable step required
for every update release that is of very questionable value/utility to
the vast majority of our users.
I wouldn't say that. Currently it is of questionable value currently but
it would be much more valuable without just version bumping and more
careful thought put into justifying the need for updates. Every update
adds to a large cost in terms of build time, bandwidth, potential
regressions etc.
I realize it would make your life
easier, but is it worth an additional imposition on our already
highly-regulated maintainers just to make your life easier?
This is hardly about just me. I am not the only user on low bandwidth
connections at times. Many regions of the world are as you can see from
the number of people agreeing with the general idea.
Basically, this seems to be "I don't really trust the
package
maintainer's decision on why I should upgrade, so I want to know what
changes this introduces."
There are other considerations including but not limited to bandwidth
and yes, the criteria that users choose for consuming updates can be
quite different from the maintainer's reason for pushing the update and
without the maintainers informing me of why they decided to do a push,
users can't arbitrate their decisions either.
This step requires human intelligence and cannot be automated
completely. You will have to take into account not only things like
upstream changelogs (names,location etc differ widely and may not even
be provided) but also downstream patches, downstream bugs filed that are
being fixed by a particular update, CVE information for security updates
and much more information that a package maintainer would know about and
is very valuable to be passed on to end users. Some portions which can
be automated, already are, such as bodhi closing updates optionally if
the bug numbers are specified.
Rahul
3:37 p.m.
On Mon, Jan 26, 2009 at 12:19 PM, Rahul Sundaram
<sundaram(a)fedoraproject.org> wrote:
Chris Weyl wrote:
> It's hardly a "small additional cost", especially when looked at in
> aggregate; this would be an additional non-automateable step required
> for every update release that is of very questionable value/utility to
> the vast majority of our users.
I wouldn't say that. Currently it is of questionable value currently but it
would be much more valuable without just version bumping and more careful
thought put into justifying the need for updates. Every update adds to a
large cost in terms of build time, bandwidth, potential regressions etc.
...costs which are trivial next to the packager/maintainer time and
increase in their workload. (did I mention, largely unpaid workload?)
If you think that "version bumping" is a bad thing (which, frankly, I
suspect most people refer to as "tracking upstream"), then argue we
should put in place guidelines requiring "maintainers evaluate and
justify issuing an update"... of course, then we'd need a review
board, appeal process, procedures, etc, etc. If you're worried about
regressions, then let's get something going that tracks what packages
depend on the package the update and exercises their functionality...
Which would be next to impossible for programs that don't have a test
suite. (Arguably, the best way to detect and correct regressions is
to track upstream and provide feedback to them.)
None of these "goals" will be helped by imposing a barely related new
manual process requirement that you concede is "[c]ertainly of
questionable value".
> I realize it would make your life
> easier, but is it worth an additional imposition on our already
> highly-regulated maintainers just to make your life easier?
This is hardly about just me. I am not the only user on low bandwidth
connections at times. Many regions of the world are as you can see from the
number of people agreeing with the general idea.
I suspect those on low-bandwidth connections would be better served by presto.
> Basically, this seems to be "I don't really trust the
package
> maintainer's decision on why I should upgrade, so I want to know what
> changes this introduces."
There are other considerations including but not limited to bandwidth and
yes, the criteria that users choose for consuming updates can be quite
different from the maintainer's reason for pushing the update and without
the maintainers informing me of why they decided to do a push, users can't
arbitrate their decisions either.
Not to be blunt, but "too bad". That's why we're called
"maintainers", and they are "end users". If "updating to
1.2.3" isn't
good enough, and someone really wants to know what's going on with the
package, then they should read upstream's changelog. That's what it's
there for, and why we incorporate it by reference.
People know that Fedora aims to be leading-edge technology. They
expect our packages to track upstream pretty closely, and understand,
yes, we do sometimes have regressions (that are generally tracked
pretty quickly, from what I've seen). If "too many updates" is a
problem, then perhaps they should rethink what they're doing.
-Chris
--
Chris Weyl
Ex astris, scientia
3:55 p.m.
On Mon, 2009-01-26 at 13:37 -0800, Chris Weyl wrote:
"maintainers evaluate and
justify issuing an update"...
http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility...
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
4:07 p.m.
2009/1/26 Jesse Keating <jkeating(a)redhat.com>:
On Mon, 2009-01-26 at 13:37 -0800, Chris Weyl wrote:
> "maintainers evaluate and
> justify issuing an update"...
http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility...
And that's exactly what we are (or should be) doing; we just don't
write an essay about it afterwards :-)
-Chris
--
Chris Weyl
Ex astris, scientia
4:14 p.m.
On Mon, 2009-01-26 at 14:07 -0800, Chris Weyl wrote:
And that's exactly what we are (or should be) doing; we just don't
write an essay about it afterwards :-)
Did you actually read the link?
* Package Maintainers should not push every single upstream update to
all branches. Examine the changes in each upstream release and ask if
the update is worth download and update time for many users. For
upstreams that update very often with many small updates, consider
waiting and updated only when the amount of changes is worth updating.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
8:17 p.m.
2009/1/26 Jesse Keating <jkeating(a)redhat.com>:
On Mon, 2009-01-26 at 14:07 -0800, Chris Weyl wrote:
>
> And that's exactly what we are (or should be) doing; we just don't
> write an essay about it afterwards :-)
Did you actually read the link?
* Package Maintainers should not push every single upstream update to
all branches. Examine the changes in each upstream release and ask if
the update is worth download and update time for many users. For
upstreams that update very often with many small updates, consider
waiting and updated only when the amount of changes is worth updating.
Yes, actually I did. Perhaps I misunderstood your meaning here: are
you saying that it's policy in Fedora that a maintainer should not
keep their packages up to date in the best fashion that their
judgement suggests, in line with the above?
In any case, this is off-topic to the discussion; the question is
about imposing another manual task on a maintainer, rather than how
maintainers should exercise their judgement as to pushing updates
(which the above quote appears to address quite nicely).
-Chris
--
Chris Weyl
Ex astris, scientia
11:31 a.m.
On Mon, 2009-01-26 at 18:17 -0800, Chris Weyl wrote:
Yes, actually I did. Perhaps I misunderstood your meaning here:
are
you saying that it's policy in Fedora that a maintainer should not
keep their packages up to date in the best fashion that their
judgement suggests, in line with the above?
No, I'm trying to illustrate that there is a difference between
"tracking upstream" and making judgment calls on proper updates for a
release, and in fact we have policy about it.
In any case, this is off-topic to the discussion; the question is
about imposing another manual task on a maintainer, rather than how
maintainers should exercise their judgement as to pushing updates
(which the above quote appears to address quite nicely).
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
2:35 p.m.
2009/1/27 Jesse Keating <jkeating(a)redhat.com>:
On Mon, 2009-01-26 at 18:17 -0800, Chris Weyl wrote:
> Yes, actually I did. Perhaps I misunderstood your meaning here: are
> you saying that it's policy in Fedora that a maintainer should not
> keep their packages up to date in the best fashion that their
> judgement suggests, in line with the above?
No, I'm trying to illustrate that there is a difference between
"tracking upstream" and making judgment calls on proper updates for a
release, and in fact we have policy about it.
Obviously there's a difference; but just because two things are
different doesn't mean they can't be done concomitantly, or that
they're mutally exclusive. e.g. I can eat both an apple and an
orange.
-Chris
--
Chris Weyl
Ex astris, scientia
3:58 p.m.
On Mon, Jan 26, 2009 at 12:37 PM, Chris Weyl <cweyl(a)alumni.drew.edu> wrote:
People know that Fedora aims to be leading-edge technology. They
expect our packages to track upstream pretty closely, and understand,
yes, we do sometimes have regressions (that are generally tracked
pretty quickly, from what I've seen). If "too many updates" is a
problem, then perhaps they should rethink what they're doing.
The is another option, which is to grow some refinement in our update
collection structuring. We keep updates-testing and updates exactly
as they are but introduce a self-consistent culled-updates collection
with a higher reporting mandate that is a subset of what flows through
updates-released. People step forward to do the work to meet the
higher reporting mandate of the culled collection so that each culled
update has adequate information in its bodhi record to meet the higher
standard. That would keep current package maintainers are not
burdened by the additional requirement, but would create a space for
people to prove that the additional information has a cost to benefit
ratio that makes it worth doing as a best practise.
However such a culled space is still not zero cost, as it would
require its own repository layout and mirroring since it would be
slower moving than updates. We'd still have to decide if it were worth
doing with project resources even as an experiment.
-jef
4:34 p.m.
Jeff Spaleta wrote:
The is another option, which is to grow some refinement in our
update
collection structuring. We keep updates-testing and updates exactly
as they are but introduce a self-consistent culled-updates collection
with a higher reporting mandate that is a subset of what flows through
updates-released. People step forward to do the work to meet the
higher reporting mandate of the culled collection so that each culled
update has adequate information in its bodhi record to meet the higher
standard. That would keep current package maintainers are not
burdened by the additional requirement, but would create a space for
people to prove that the additional information has a cost to benefit
ratio that makes it worth doing as a best practise.
I don't think that makes sense. We should just require proper update details
for the existing updates. It takes almost no time to fill them in.
Kevin Kofler
2:42 a.m.
Chris Weyl wrote:
None of these "goals" will be helped by imposing a barely related new
manual process requirement that you concede is "[c]ertainly of
questionable value".
You aren't reading what I said. I said, the updates aren't useful
without even a short sentence about what it is required.
I suspect those on low-bandwidth connections would be better served
by presto.
Presto works for some use cases but not others and is cpu intensive as
well.
Not to be blunt, but "too bad". That's why we're
called
"maintainers", and they are "end users".
Maintainers are supposed to serve and meet end user needs and not the
other way around.
If "updating to 1.2.3" isn't
good enough, and someone really wants to know what's going on
with the
package, then they should read upstream's changelog. That's what it's
there for, and why we incorporate it by reference.
Many maintainers don't and sometimes there is no proper upstream
changelog to refer to. This is why, ultimately it is the maintainer's
responsibility to summarize the need for an update. As I said earlier,
upstream changelog would have no knowledge on Fedora downstream bugs,
backported patches etc.
Rahul
2:38 p.m.
On Tue, Jan 27, 2009 at 12:42 AM, Rahul Sundaram
<sundaram(a)fedoraproject.org> wrote:
Chris Weyl wrote:
> Not to be blunt, but "too bad". That's why we're called
> "maintainers", and they are "end users".
Maintainers are supposed to serve and meet end user needs and not the other
way around.
That would be completely true IF we were being paid for this;
otherwise we have to acknowledge that it's a matter of enlightened
self-interest to contribute. Right?
-Chris
--
Chris Weyl
Ex astris, scientia
2:51 p.m.
Chris Weyl wrote:
On Tue, Jan 27, 2009 at 12:42 AM, Rahul Sundaram
<sundaram(a)fedoraproject.org> wrote:
> Chris Weyl wrote:
>> Not to be blunt, but "too bad". That's why we're called
>> "maintainers", and they are "end users".
> Maintainers are supposed to serve and meet end user needs and not the other
> way around.
That would be completely true IF we were being paid for this;
otherwise we have to acknowledge that it's a matter of enlightened
self-interest to contribute. Right?
False dichotomy.
Regardless of whether you are paid to do it or not, you are there to
meet users and community needs. I would argue more so, if you are
volunteer since the people who are doing it just because they are
getting paid are doing it for the money instead of the users. I don't
think anybody in the Fedora community is that way.
If you don't even want to try, you might as well as stop doing it and
enlightened self interest isn't incompatible with serving users needs at
all. In fact, your enlightened self interest must compel you to work
together with other contributors to do a good job of it instead of
excusing yourself because you are volunteer just like the majority in
this community.
If you read the guidelines, they are very simple common sense items that
package maintainers have been expected to follow all along. I am merely
documenting them for everybody's benefit especially new maintainers.
Rahul
2:59 p.m.
On Tue, Jan 27, 2009 at 12:51 PM, Rahul Sundaram
<sundaram(a)fedoraproject.org> wrote:
Chris Weyl wrote:
>
> On Tue, Jan 27, 2009 at 12:42 AM, Rahul Sundaram
> <sundaram(a)fedoraproject.org> wrote:
>>
>> Chris Weyl wrote:
>>>
>>> Not to be blunt, but "too bad". That's why we're called
>>> "maintainers", and they are "end users".
>>
>> Maintainers are supposed to serve and meet end user needs and not the
>> other
>> way around.
>
> That would be completely true IF we were being paid for this;
> otherwise we have to acknowledge that it's a matter of enlightened
> self-interest to contribute. Right?
False dichotomy.
Regardless of whether you are paid to do it or not, you are there to meet
users and community needs. I would argue more so, if you are volunteer since
the people who are doing it just because they are getting paid are doing it
for the money instead of the users. I don't think anybody in the Fedora
community is that way.
If you don't even want to try, you might as well as stop doing it and
enlightened self interest isn't incompatible with serving users needs at
all. In fact, your enlightened self interest must compel you to work
together with other contributors to do a good job of it instead of excusing
yourself because you are volunteer just like the majority in this community.
If you read the guidelines, they are very simple common sense items that
package maintainers have been expected to follow all along. I am merely
documenting them for everybody's benefit especially new maintainers.
Of course we're here to meet users needs, but WE are those users as
well... and we're putting ourselves in a bad spot when we forget that.
I'm not sure what this "if you don't even want to try" bit is about,
since this isn't about me, it's about imposing another manual task on
our maintainers. Arguing against that isn't not working "together
with other contributors", it's discussing how we can make use of those
limited resources. Every little thing may seem reasonable, but then,
that's also what they thought about the DMV.
I do read the guidelines, and while there are MANY of them, they tend
to make sense, and where I don't think they do, I still respect them.
I don't think you're "merely documenting them" here, however; this is
_clearly_ a new task being discussed.
-Chris
--
Chris Weyl
Ex astris, scientia
3:10 p.m.
Chris Weyl wrote:
Of course we're here to meet users needs, but WE are those users
as
well... and we're putting ourselves in a bad spot when we forget that.
We are largely meeting needs other than ourselves though. Volunteer or
not has nothing to do with it.
I'm not sure what this "if you don't even want to
try" bit is about,
since this isn't about me, it's about imposing another manual task on
our maintainers.
I do read the guidelines, and while there are MANY of them, they
tend
to make sense, and where I don't think they do, I still respect them.
No. Don't do that. If you don't think anything doesn't make sense, ask
questions. We don't need to blindly respect anything.
I don't think you're "merely documenting them"
here, however; this is
_clearly_ a new task being discussed.
I don't think so. Bodhi description fields have been considered
mandatory and filling them has always been a manual task. People just
assumed, everyone would know what to fill it with. That hasn't worked
out very well for us and has been a common question as well in
#fedora-devel. By documenting them, we get that knowledge more easily
preserved.
Rahul
4:22 p.m.
On Tue, Jan 27, 2009 at 1:10 PM, Rahul Sundaram
<sundaram(a)fedoraproject.org> wrote:
Chris Weyl wrote:
> Of course we're here to meet users needs, but WE are those users as
> well... and we're putting ourselves in a bad spot when we forget that.
We are largely meeting needs other than ourselves though. Volunteer or not
has nothing to do with it.
Really? If your management came to you and said that it's a condition
of employment that you fill out daily TPS reports in blood while
standing on your head, with the economy the way it is they could
probably do it. Try that with a volunteer.
> I'm not sure what this "if you don't even want to
try" bit is about,
> since this isn't about me, it's about imposing another manual task on
> our maintainers.
> I do read the guidelines, and while there are MANY of them, they tend
> to make sense, and where I don't think they do, I still respect them.
No. Don't do that. If you don't think anything doesn't make sense, ask
questions. We don't need to blindly respect anything.
I ... I'm not even going to respond to that.
> I don't think you're "merely documenting them"
here, however; this is
> _clearly_ a new task being discussed.
I don't think so. Bodhi description fields have been considered mandatory
and filling them has always been a manual task. People just assumed,
everyone would know what to fill it with. That hasn't worked out very well
for us and has been a common question as well in #fedora-devel. By
documenting them, we get that knowledge more easily preserved.
Really? Filling in that field has always been manual? hm. Funny this
works then:
bodhi -n -c "`cat clog`" -r F-X -t enhancement -R testing `make verrel`
-Chris
--
Chris Weyl
Ex astris, scientia
4:31 p.m.
On Tue, 2009-01-27 at 14:22 -0800, Chris Weyl wrote:
Really? Filling in that field has always been manual? hm. Funny
this
works then:
bodhi -n -c "`cat clog`" -r F-X -t enhancement -R testing `make
verrel`
You're just being difficult to be difficult. You could also come up
with a way to script against the web interface, but at the end of the
day, the contents of the notes section have to be generated somewhere.
Bodhi doesn't generate them itself. That's the point that rahul was
making.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
4:38 p.m.
2009/1/27 Jesse Keating <jkeating(a)redhat.com>:
On Tue, 2009-01-27 at 14:22 -0800, Chris Weyl wrote:
> Really? Filling in that field has always been manual? hm. Funny this
> works then:
>
> bodhi -n -c "`cat clog`" -r F-X -t enhancement -R testing `make
> verrel`
You're just being difficult to be difficult. You could also come up
with a way to script against the web interface, but at the end of the
day, the contents of the notes section have to be generated somewhere.
Bodhi doesn't generate them itself. That's the point that rahul was
making.
If "being difficult to be difficult" means "showing a counter-example
to something stated as fact", then, alright, that's me.
Bodhi doesn't generate them itself, but neither does it have to be a
manual task. Reusing existing information through automation
effectively negates that; much like pointing at existing upstream
changelogs would negate having to regurgiate them somewhere else.
-Chris
--
Chris Weyl
Ex astris, scientia
4:41 p.m.
On Tue, 2009-01-27 at 14:38 -0800, Chris Weyl wrote:
If "being difficult to be difficult" means "showing a
counter-example
to something stated as fact", then, alright, that's me.
Bodhi doesn't generate them itself, but neither does it have to be a
manual task. Reusing existing information through automation
effectively negates that; much like pointing at existing upstream
changelogs would negate having to regurgiate them somewhere else.
You're just nit-picking raul's use of the term 'manual'. Rahul meant
(correct me if I'm wrong here rahul) that bodhi doesn't self generate
that information. Period. Do you dispute that?
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
6:18 p.m.
2009/1/27 Jesse Keating <jkeating(a)redhat.com>:
On Tue, 2009-01-27 at 14:38 -0800, Chris Weyl wrote:
> If "being difficult to be difficult" means "showing a
counter-example
> to something stated as fact", then, alright, that's me.
>
> Bodhi doesn't generate them itself, but neither does it have to be a
> manual task. Reusing existing information through automation
> effectively negates that; much like pointing at existing upstream
> changelogs would negate having to regurgiate them somewhere else.
You're just nit-picking raul's use of the term 'manual'. Rahul meant
(correct me if I'm wrong here rahul) that bodhi doesn't self generate
that information. Period. Do you dispute that?
"Bodhi description fields have been considered mandatory and filling
them has always been a manual task."
I'm pretty sure the plain meaning of "manual task" is "manual
task".
As I can't read minds, I can't tell you what he meant, but I can read
what he wrote.
-Chris
--
Chris Weyl
Ex astris, scientia
1:43 a.m.
Jesse Keating wrote:
On Tue, 2009-01-27 at 14:38 -0800, Chris Weyl wrote:
> If "being difficult to be difficult" means "showing a
counter-example
> to something stated as fact", then, alright, that's me.
>
> Bodhi doesn't generate them itself, but neither does it have to be a
> manual task. Reusing existing information through automation
> effectively negates that; much like pointing at existing upstream
> changelogs would negate having to regurgiate them somewhere else.
You're just nit-picking raul's use of the term 'manual'. Rahul meant
(correct me if I'm wrong here rahul) that bodhi doesn't self generate
that information. Period.
Correct. Scripting doesn't change that. It just makes it easier.
Rahul
12:32 p.m.
Chris Weyl wrote:
Really? Filling in that field has always been manual? hm. Funny
this
works then:
bodhi -n -c "`cat clog`" -r F-X -t enhancement -R testing `make
verrel`
And this is usually a horrible thing to fill in, unless "clog" already
contains a rationale why the update is being pushed and a short summary of
changes rather than a long FSF-style changelog with things like:
2009-01-28 John Doe <foo(a)example.com>
* version.c (VERSION): Bump version.
* main.c (main): Likewise.
* foo.c (bar): Likewise.
2009-01-01 Luke Pedant <pedant(a)example.com>
* a.c: Bump copyright date.
* b.c: Likewise.
* c.c: Likewise.
* foo.c: Likewise.
* main.c: Likewise.
* version.c: Likewise.
* x.c: Likewise.
etc.
Kevin Kofler
5:29 p.m.
Rahul Sundaram wrote:
Chris Weyl wrote:
> It's hardly a "small additional cost", especially when looked at in
> aggregate; this would be an additional non-automateable step required
> for every update release that is of very questionable value/utility to
> the vast majority of our users.
I wouldn't say that. Currently it is of questionable value currently but
it would be much more valuable without just version bumping and more
careful thought put into justifying the need for updates. Every update
adds to a large cost in terms of build time, bandwidth, potential
regressions etc.
There are distros for people that feel that way. I don't think any of
them are named "Fedora".
Then there are distros that believe in following upstream and shipping
their bug-fixes and feature enhancements. I'm using my favorite one of
those :-). Such distros, incidentally, are great for developers (/me
waves) who need to follow upstream (due to dependencies, or just desire
to watch upstream) but who need something more stable than rawhide.
Should we not release any updates without a Fedora bug being filed
asking to upgrade to the latest upstream?
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
find / -user your -name base -print0 | xargs -0 chown us:cats -- Unknown
5:48 p.m.
On Mon, 2009-01-26 at 17:29 -0600, Matthew Woehlke wrote:
Then there are distros that believe in following upstream and shipping
their bug-fixes and feature enhancements. I'm using my favorite one of
those :-). Such distros, incidentally, are great for developers (/me
waves) who need to follow upstream (due to dependencies, or just desire
to watch upstream) but who need something more stable than rawhide.
If everybody is just throwing the latest from upstream in whatever the
feel like it, what keeps a release from being more stable than rawhide?
Should we not release any updates without a Fedora bug being filed
asking to upgrade to the latest upstream?
That's actually not unreasonable. The update process should be user
driven, as in a user needs or wants something specific from the new
upstream code, we don't just install a bot to throw whatever falls out
of upstream directly at our users whether they want/need it or not.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
6:05 p.m.
Jesse Keating wrote:
If everybody is just throwing the latest from upstream in whatever
the
feel like it, what keeps a release from being more stable than rawhide?
Aside from upstream (hopefully) not being a mess, there is a difference
between "this seems to work" and "what justification, besides that
upstream has fixed bugs and added features, can I give to push this update"?
If a package seems to be non-broken and fixes bugs, that's good enough
for me to update. (Of course, I'm also not in a limited-bandwidth
situation, but...) Just because I haven't been bitten by a particular
bug /yet/ doesn't make updating useless; maybe it saves me from being
bit tomorrow.
Also, notice I didn't actually object to asking for better "what's
changed" information. I objected to putting bureaucracy in the way of
what Fedora currently is; a distro that tends to closely track upstream.
On Mon, 2009-01-26 at 17:29 -0600, Matthew Woehlke wrote:
> Should we not release any updates without a Fedora bug being filed
> asking to upgrade to the latest upstream?
That's actually not unreasonable. The update process should be user
driven, as in a user needs or wants something specific from the new
upstream code, we don't just install a bot to throw whatever falls out
of upstream directly at our users whether they want/need it or not.
...except now I have to run around opening a ticket every time KDE bumps
its requirement on CMake version, or libical version, or...
No, thanks.
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
find / -user your -name base -print0 | xargs -0 chown us:cats -- Unknown
6:07 p.m.
On Mon, 2009-01-26 at 18:05 -0600, Matthew Woehlke wrote:
Aside from upstream (hopefully) not being a mess, there is a difference
between "this seems to work" and "what justification, besides that
upstream has fixed bugs and added features, can I give to push this update"?
If a package seems to be non-broken and fixes bugs, that's good enough
for me to update. (Of course, I'm also not in a limited-bandwidth
situation, but...) Just because I haven't been bitten by a particular
bug /yet/ doesn't make updating useless; maybe it saves me from being
bit tomorrow.
Also, notice I didn't actually object to asking for better "what's
changed" information. I objected to putting bureaucracy in the way of
what Fedora currently is; a distro that tends to closely track upstream.
> On Mon, 2009-01-26 at 17:29 -0600, Matthew Woehlke wrote:
>> Should we not release any updates without a Fedora bug being filed
>> asking to upgrade to the latest upstream?
>
> That's actually not unreasonable. The update process should be user
> driven, as in a user needs or wants something specific from the new
> upstream code, we don't just install a bot to throw whatever falls out
> of upstream directly at our users whether they want/need it or not.
...except now I have to run around opening a ticket every time KDE bumps
its requirement on CMake version, or libical version, or...
But Fedora /releases/ aren't your personal rawhide. We're providing
releases that are supposed to stay somewhat stable, not to just be a
dumping ground for whatever upstream chooses to drop the day before. We
have a developmental stream for that, and it makes releases fairly
often. I just don't understand why we want to treat our /release/
branches as if they were just another rawhide.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
6:32 p.m.
Jesse Keating wrote:
On Mon, 2009-01-26 at 18:05 -0600, Matthew Woehlke wrote:
>> On Mon, 2009-01-26 at 17:29 -0600, Matthew Woehlke wrote:
>>> Should we not release any updates without a Fedora bug being filed
>>> asking to upgrade to the latest upstream?
>> That's actually not unreasonable. The update process should be user
>> driven, as in a user needs or wants something specific from the new
>> upstream code, we don't just install a bot to throw whatever falls out
>> of upstream directly at our users whether they want/need it or not.
> ...except now I have to run around opening a ticket every time KDE bumps
> its requirement on CMake version, or libical version, or...
But Fedora /releases/ aren't your personal rawhide. We're providing
releases that are supposed to stay somewhat stable, not to just be a
dumping ground for whatever upstream chooses to drop the day before. We
have a developmental stream for that, and it makes releases fairly
often. I just don't understand why we want to treat our /release/
branches as if they were just another rawhide.
Where did I say that? If you read what I said above, I said that
releases should be for tested packages that the maintainer considers
sand to push to a release. I also said that "sane to push to a release"
should not mandate a bug report being filed.
The current update rate works well for me and has a lot to do with why I
chose Fedora (particularly over RH, which I was using before, which is
absolutely horrible at being out of date, and for which I had to either
roll all sorts of packages by hand or else pull in half of Fedora
anyway). Do you consider what we currently have to be no different from
rawhide?
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
find / -user your -name base -print0 | xargs -0 chown us:cats -- Unknown
6:54 p.m.
On Mon, 2009-01-26 at 18:32 -0600, Matthew Woehlke wrote:
The current update rate works well for me and has a lot to do with why I
chose Fedora (particularly over RH, which I was using before, which is
absolutely horrible at being out of date, and for which I had to either
roll all sorts of packages by hand or else pull in half of Fedora
anyway).
There is a big gap between RH(EL) which is extremely stable, new
releases every few years, and Fedora which has a new release out every 6
months. There are also differences with what and why updates are
pushed, and how they are done. Primarily RHEL fixes bugs by back
porting fixes to shipped releases to keep further stable, whereas in
Fedora we're free to pull in new upstream releases to fix bugs. I'd
just prefer that we spend more time pulling things in when necessary,
rather than whenever we can.
Do you consider what we currently have to be no different from
rawhide?
I think the only thing keeping it from being like rawhide is the bodhi
hurdle. If bodhi wasn't as much of a process as it is, I don't think
there would be much difference, except that for some key packages the
maintainers choose to not just do every new release everywhere, and tend
to treat our releases as just that, stable releases not to be trifled
with unless there is darn good reason.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
8:27 p.m.
2009/1/26 Jesse Keating <jkeating(a)redhat.com>:
But Fedora /releases/ aren't your personal rawhide. We're
providing
releases that are supposed to stay somewhat stable, not to just be a
dumping ground for whatever upstream chooses to drop the day before. We
have a developmental stream for that, and it makes releases fairly
often. I just don't understand why we want to treat our /release/
branches as if they were just another rawhide.
I doubt anyone here intentionally treats a release in the same way
it's acceptable to beat up rawhide with. There's a _huge_ difference
in sanely tracking upstream in a release and injecting potentially
massively unstable stuff in rawhide.
-Chris
--
Chris Weyl
Ex astris, scientia
11:36 a.m.
On Mon, 2009-01-26 at 18:27 -0800, Chris Weyl wrote:
2009/1/26 Jesse Keating <jkeating(a)redhat.com>:
> But Fedora /releases/ aren't your personal rawhide. We're providing
> releases that are supposed to stay somewhat stable, not to just be a
> dumping ground for whatever upstream chooses to drop the day before. We
> have a developmental stream for that, and it makes releases fairly
> often. I just don't understand why we want to treat our /release/
> branches as if they were just another rawhide.
I doubt anyone here intentionally treats a release in the same way
it's acceptable to beat up rawhide with. There's a _huge_ difference
in sanely tracking upstream in a release and injecting potentially
massively unstable stuff in rawhide.
YOU may see it that way, however given some of the updates I've seen
tossed at Fedora, spammed to every release including rawhide at the same
time, with extremely little (often no) information about what the update
is, and why users should process that update, I have a hard time
believing that the maintainer base as a whole agrees with you. So yeah,
I want to introduce a step where the maintainer actually has to think
about why they are issuing this update, what value it brings to users,
and what they should test for in order to help the maintainer know if
the intended value was met or not.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
2:10 a.m.
On Mon, 2009-01-26 at 16:07 -0800, Jesse Keating wrote:
But Fedora /releases/ aren't your personal rawhide. We're
providing
releases that are supposed to stay somewhat stable, not to just be a
dumping ground for whatever upstream chooses to drop the day before. We
have a developmental stream for that, and it makes releases fairly
often. I just don't understand why we want to treat our /release/
branches as if they were just another rawhide.
Agree completely.
Another worrying sentiment I heard lately was that it makes sense to
push a new, untested upstream release into updates-testing so that it
actually gets testing because "no-one runs rawhide".
The idea being that if you disable the bodhi-karma-auto-push thing, then
it won't hit updates until all the wrinkles have been ironed out.
To me that's just wrong - if someone enables updates-testing, they
shouldn't be immediately exposed to new upstream release. IMHO, the
process should be:
a) push to rawhide and let stew
b) if there's some serious bug fix or important user feature requested
that can't be trivially backported, then push to updates-testing
c) push to updates
Cheers,
Mark.
6:22 p.m.
Jesse Keating wrote:
On Mon, 2009-01-26 at 17:29 -0600, Matthew Woehlke wrote:
> Should we not release any updates without a Fedora bug being filed
> asking to upgrade to the latest upstream?
That's actually not unreasonable. The update process should be user
driven, as in a user needs or wants something specific from the new
upstream code, we don't just install a bot to throw whatever falls out
of upstream directly at our users whether they want/need it or not.
Reality is: In most cases, updates are upstream driven, because Fedora is
just a small subset of an upstream's user-base. Also upstreams typically
happen to habe
the better insights in issue/bugs/defects a package might suffer from.
Therefore, if upstreams are doing a reasonable job (many do), keeping in
close sync to upstream releases means "preventive bug fixing".
The problem with this: Users don't notice the cases in which upgrades
"simply work" - They only notice the case, something already has gone wrong.
Ralf
6:55 p.m.
On Tue, 2009-01-27 at 01:22 +0100, Ralf Corsepius wrote:
The problem with this: Users don't notice the cases in which
upgrades
"simply work" - They only notice the case, something already has gone wrong.
Many users notice a plethora of updates for unknown reasons that chew up
their bandwidth, cpu, and disk time while they're just trying to get
work done. So much so that many opt out of applying updates at all,
because there are so many of them, which hurts our abilities to deliver
security updates.
People in bandwidth rich situations and with new expensive fast hardware
may not see a problem. Those without certainly do.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
8:11 p.m.
Jesse Keating wrote:
On Tue, 2009-01-27 at 01:22 +0100, Ralf Corsepius wrote:
> The problem with this: Users don't notice the cases in which upgrades
> "simply work" - They only notice the case, something already has gone
wrong.
Many users notice a plethora of updates for unknown reasons that chew up
their bandwidth, cpu, and disk time while they're just trying to get
work done. So much so that many opt out of applying updates at all,
because there are so many of them, which hurts our abilities to deliver
security updates.
These problems do not originate from the number of upgrades/update, they
originate from the _size_ of updates few packages introduce.
People in bandwidth rich situations
Correct.
and with new expensive fast hardware
may not see a problem.
Well, I would label this an urban legend - Updating recent Fedoras using
yum has not been much of a performance problem, even on slower and older
HW (e.g. a 1GHz i686/512MB)
Admitted, on an 64MB/166MHz i586 w/Fedora 10 yum updates tend to be
"really slow".
However, wrt. to bandwidth, I see another problem: Your strategy of
pushing updates in "big batches", instead of "small chunks".
This makes a significant difference to users with limited bandwidth.
While they could easily poll "small chunks", e.g. once a day (blocking
their network for, e.g. 1 hour), the current strategy would block they
network for very much longer (e.g. 7 hours).
Another aspect related to bandwidth: Revisiting
* the sizes of rpms (e.g. different payload compressors).
* differential updates/rpms.
Seems to me as if these once "hot topics" have dropped off the Fedora
radar, in favor of "strangling/nagging the distro's contributors".
Ralf
11:41 a.m.
On Tue, 2009-01-27 at 03:11 +0100, Ralf Corsepius wrote:
Jesse Keating wrote:
> On Tue, 2009-01-27 at 01:22 +0100, Ralf Corsepius wrote:
>> The problem with this: Users don't notice the cases in which upgrades
>> "simply work" - They only notice the case, something already has gone
wrong.
>
> Many users notice a plethora of updates for unknown reasons that chew up
> their bandwidth, cpu, and disk time while they're just trying to get
> work done. So much so that many opt out of applying updates at all,
> because there are so many of them, which hurts our abilities to deliver
> security updates.
These problems do not originate from the number of upgrades/update, they
originate from the _size_ of updates few packages introduce.
Size is in direct correlation to number.
> People in bandwidth rich situations
Correct.
> and with new expensive fast hardware
> may not see a problem.
Well, I would label this an urban legend - Updating recent Fedoras using
yum has not been much of a performance problem, even on slower and older
HW (e.g. a 1GHz i686/512MB)
Admitted, on an 64MB/166MHz i586 w/Fedora 10 yum updates tend to be
"really slow".
Try doing updates on a netbook, or any other system with relatively slow
"disk" I/O, or "slow" CPU. Yum isn't really the problem here,
it's the
rpms themselves, constantly doing ldconfigs, cache updates, tonnes of
hardlinking, etc... and while people are working to correct some of
this, the fact still remains that processing updates chews up system
resources.
However, wrt. to bandwidth, I see another problem: Your strategy of
pushing updates in "big batches", instead of "small chunks".
This makes a significant difference to users with limited bandwidth.
While they could easily poll "small chunks", e.g. once a day (blocking
their network for, e.g. 1 hour), the current strategy would block they
network for very much longer (e.g. 7 hours).
If I were to push updates once a day, the mirrors would be in shambles,
constantly trying to pick up the new content and users would have a
terrible experience. Pushing updates faster doesn't magically make the
number of updates get smaller.
Another aspect related to bandwidth: Revisiting
* the sizes of rpms (e.g. different payload compressors).
* differential updates/rpms.
Seems to me as if these once "hot topics" have dropped off the Fedora
radar, in favor of "strangling/nagging the distro's contributors".
Ralf
People are working on both of the above issues. Just not me personally.
--
Jesse Keating RHCE (http://jkeating.livejournal.com)
Fedora Project (http://fedoraproject.org/wiki/JesseKeating)
GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
identi.ca (http://identi.ca/jkeating)
10:31 p.m.
Jesse Keating wrote:
On Tue, 2009-01-27 at 03:11 +0100, Ralf Corsepius wrote:
> Jesse Keating wrote:
>> On Tue, 2009-01-27 at 01:22 +0100, Ralf Corsepius wrote:
>>> The problem with this: Users don't notice the cases in which upgrades
>>> "simply work" - They only notice the case, something already has
gone wrong.
>> Many users notice a plethora of updates for unknown reasons that chew up
>> their bandwidth, cpu, and disk time while they're just trying to get
>> work done. So much so that many opt out of applying updates at all,
>> because there are so many of them, which hurts our abilities to deliver
>> security updates.
> These problems do not originate from the number of upgrades/update, they
> originate from the _size_ of updates few packages introduce.
Size is in direct correlation to number.
With all due respect, Mr. Keating, this is
non-sense.
One update to openoffice/evolution/kde/gnome/kernel or some game's data
outweighs many other packages.
>> and with new expensive fast hardware
>> may not see a problem.
> Well, I would label this an urban legend - Updating recent Fedoras using
> yum has not been much of a performance problem, even on slower and older
> HW (e.g. a 1GHz i686/512MB)
>
> Admitted, on an 64MB/166MHz i586 w/Fedora 10 yum updates tend to be
> "really slow".
Try doing updates on a netbook,
I own one - Typical "yum update" times
are in the order of "very few"
minutes at average.
Example from a couple minutes ago (comprising kernel/kernel-devel,
PackageKit, selinux-policy and some rpmfusion updates - 20 packages in
total; Using local (fast) mirrors):
# cat /proc/cpuinfo
..
model name : Intel(R) Atom(TM) CPU N270 @ 1.60GHz
..
# time yum -y update
...
real 7m48.916s
user 4m50.155s
sys 0m57.314s
Not fast, but hardly a serious problem.
On an i586, the times requires for yum updates are much higher
(typically hours), times on old i686's are in the order of several 10
minutes.
or any other system with relatively slow
"disk" I/O, or "slow" CPU.
The cases I mention are real - I do own such machines.
On these, the real yum update related problems are bandwidth and
disk-space requirements (yum-caches).
PackageKit's GUI and parsing activities adds further (quite measurable)
requirements on CPU-power and RAM.
Yum isn't really the problem here, it's the
rpms themselves, constantly doing ldconfigs, cache updates, tonnes of
hardlinking, etc...
From what I experience, SELinux policy updates are by far means the
most resource intense/most time consuming part of updating.
> However, wrt. to bandwidth, I see another problem: Your strategy
of
> pushing updates in "big batches", instead of "small chunks".
>
> This makes a significant difference to users with limited bandwidth.
> While they could easily poll "small chunks", e.g. once a day (blocking
> their network for, e.g. 1 hour), the current strategy would block they
> network for very much longer (e.g. 7 hours).
If I were to push updates once a day, the mirrors would be in shambles,
I can't
prove nor counter-prove this claim, but I doubt that this would
make much of a difference.
constantly trying to pick up the new content and users would have a
terrible experience. Pushing updates faster doesn't magically make the
number of updates get smaller.
On the end-user's side it makes a substantial difference if whether one
of your "big pushes" blocks a machine/network for the whole day,
or whether a "yum update" finishes during a "work break".
> Another aspect related to bandwidth: Revisiting
> * the sizes of rpms (e.g. different payload compressors).
> * differential updates/rpms.
>
> Seems to me as if these once "hot topics" have dropped off the Fedora
> radar, in favor of "strangling/nagging the distro's contributors".
>
> Ralf
>
People are working on both of the above issues.
Really? I doubt your claim. At
least I am not aware of any activities in
RH's rpm to change rpm's payload rsp. to perform measurements on the
impact of using modern compressors on rpm-payloads.
Ralf
10:40 p.m.
On Wed, 2009-01-28 at 05:31 +0100, Ralf Corsepius wrote:
On an i586, the times requires for yum updates are much higher
(typically hours), times on old i686's are in the order of several 10
minutes.
Any idea how much of the i586 transaction time is swapping?
>
> People are working on both of the above issues.
Really? I doubt your claim. At least I am not aware of any activities in
RH's rpm to change rpm's payload rsp. to perform measurements on the
impact of using modern compressors on rpm-payloads.
well one of the memory intensive portions of the transaction is being
worked on. The file fingerprinting. Additionally, Panu noticed an issue
when you test a transaction then turn around and run that transaction.
For odd reasons the memory size gets much bigger.
-sv
3:11 a.m.
seth vidal wrote:
On Wed, 2009-01-28 at 05:31 +0100, Ralf Corsepius wrote:
> On an i586, the times requires for yum updates are much higher
> (typically hours), times on old i686's are in the order of several 10
> minutes.
Any idea how much of the i586 transaction time is swapping?
Likely much of it,
however I have no idea on how to measure it ;)
Anyway, FWIW, here is a short protocol of a yum update session on this
machine (performed in recent hours):
* System i586MMX/166MHz, 64MB RAM, 2GB IDE HD.
# cat /proc/cpuinfo
..
vendor_id : GenuineIntel
cpu family : 5
model : 4
model name : Pentium MMX
stepping : 4
cpu MHz : 166.653
..
# cat /proc/meminfo
..
MemTotal: 59264 kB
..
SwapTotal: 131064 kB
..
* SELinux is disabled[1]
* System is running Fedora 10 in runlevel 3, with "top" in a shell on
vt1 and running "yum update" in an ssh-login from a remote machine.
* Active repos: fedora, updates.
Observations on swap and yum's memory usage:
* no swapping until yum reports "Setting up Update Process"
* During "Setting up Update Process", yum's "VIRT mem" gradually
crawls up.
* At "Transaction Summary"/"Is this OK?", yum's "VIRT
mem" has reached
ca. 64MB/ca. 40MB swap is in use.
* No substantial changes to memory/swap during "Downloading Packages"
* During "Running rpm_check_debug", yum's "VIRT mem" increases to
ca.
73MB, using ca. 44MB swap.
* During "Running Transaction Test", yum's "VIRT mem" swings in
the
70-76MB range. During all this, "swap in use" is gradually increases to
ca. 54MB.
* During "Running Transaction", yum's "VIRT mem" swings in the
same
range, "swap in use" increases to 56MB.
* When the actual installation starts, yum's "VIRT mem" stays near 74MB,
while "swap in use" swings at a +/-20MB applitude around ca. 65MB [3][4].
* During "cleanup" yum's "VIRT mem" reaches 78MB, while swap stays
near
65MB.
Observations on times being required (wall-clock measured):
* Time until "Is this OK?" had been ca. 10-15 minutes.
* "Downloading Packages" took ca. 5 minutes (using a (fast) local mirror).
* The time from "Is this OK?" to "Finished Transaction Test" was
ca. 1 hour.
* The "Running Transaction" stage took ca. 1 hour.
* The actual "update/installation" stage took ca. 1/2 hour.
* The "cleanup" stage took ca. 1/4 hour.
Total time: ca. 3 hours.
>> People are working on both of the above issues.
> Really? I doubt your claim. At least I am not aware of any activities in
> RH's rpm to change rpm's payload rsp. to perform measurements on the
> impact of using modern compressors on rpm-payloads.
well one of the memory intensive portions of the transaction is being
worked on. The file fingerprinting.
OK.
What I actually would like to know is which impact switching to e.g.
bzip2 or lzma compressed payloads would have on end-users.
I.e. answers/input related to
* disk-space requirements
Would such step shrink the isos rsp. give room on isos?
* end-user's throughput during downloads.
In the past, there have been claims, bzip2 compression would have
negative impacts on network-throughput because it would defeat low-level
compression on networks (e.g. modems, isdn). Is this claim true, can it
be verified, how about lzma and friends?
* rpm's installation times/memory requirement (time required for
decompression, memory being used during decompression).
bzip2 has quite
Ralf
[1] Kernel OOMs when SELinux is enabled.
[2] Different setup as in the netbook example. Also, the i586 had not
been updated since early January.
[3] The maximum swap space usage seems to have occurred, when the kernel
package was updated. depmod appeared to have caused the maximum of swap
space usage.
[4] Visible as time-consuming tools in "top" (in decreasing order):
mkinitrd (several minutes), gconftool-2 (several seconds), ldconfig
(frequently called; very few seconds per invocation).
1:17 p.m.
Ralf Corsepius <rc040203(a)freenet.de> wrote:
[Detailed VM/time measurements]
Thanks!
What I actually would like to know is which impact switching to
e.g. bzip2 or lzma compressed payloads would have on end-users.
I.e. answers/input related to
* disk-space requirements
Would such step shrink the isos rsp. give room on isos?
It should, but not by very much.
* end-user's throughput during downloads.
In the past, there have been claims, bzip2 compression would have
negative impacts on network-throughput because it would defeat
low-level compression on networks (e.g. modems, isdn). Is this claim
true, can it be verified, how about lzma and friends?
This is probably nonsense, modems and such use a variant of the original
compress(1), which won't be able to compress gzip(1)ed data any better than
shiny-new-compression-ed data.
* rpm's installation times/memory requirement (time required for
decompression, memory being used during decompression).
bzip2 has quite
bzip2(1) uncompression requires a lot more RAM and CPU than gzip(1).
--
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 2340000 Fax: +56 32 2797513
2:26 p.m.
On Wed, 2009-01-28 at 21:09 +0100, Kevin Kofler wrote:
Horst H. von Brand wrote:
> bzip2(1) uncompression requires a lot more RAM and CPU than gzip(1).
But LZMA doesn't and in most cases it compresses even better than bzip2.
Kevin Kofler
IIRC upstream RPM is waiting for lzma to stabilize.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:32 p.m.
Ralf Corsepius wrote:
Jesse Keating wrote:
> Try doing updates on a netbook,
I own one - Typical "yum update" times are in the order of "very few"
minutes at average.
Looking only at install times...
Asus EEE 900A (SSD): 3m40s
HP xw4400 Workstation (SATA platter): 1m25s
...and the latter did kernel-devel as well as kernel, kernel-headers and
kernel-firmware, plus it also had to remove a kmod-nvidia. (Times are
approximate.)
...so the SSD is about 3x slower or more (especially as I notice
kernel-devel took the desktop the longest).
> Yum isn't really the problem here, it's the
> rpms themselves, constantly doing ldconfigs, cache updates, tonnes of
> hardlinking, etc...
From what I experience, SELinux policy updates are by far means the
most resource intense/most time consuming part of updating.
Really? For me, it's always OOo updates... 100 MB in a single package?
(What's worse is that OOo can't be updated while running... it doesn't
crash, but it becomes unable to save; bad news if you forgot to save
first. That and Firefox are the only things I'm aware of with that
problem, but at least with FF it only breaks typing addresses into the
address bar.)
Whereas selinux is a 2.0 MB package :-).
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"It's impossible! But... do-able."
-- Robert MacDougal (Sean Connery, Entrapment)
1:12 a.m.
On Wed, Jan 28, 2009 at 10:32 PM, Matthew Woehlke
<mw_triad(a)users.sourceforge.net> wrote:
Ralf Corsepius wrote:
>
> Jesse Keating wrote:
>>
>> Try doing updates on a netbook,
>
> I own one - Typical "yum update" times are in the order of "very
few"
> minutes at average.
Looking only at install times...
Asus EEE 900A (SSD): 3m40s
HP xw4400 Workstation (SATA platter): 1m25s
...and the latter did kernel-devel as well as kernel, kernel-headers and
kernel-firmware, plus it also had to remove a kmod-nvidia. (Times are
approximate.)
...so the SSD is about 3x slower or more (especially as I notice
kernel-devel took the desktop the longest).
>> Yum isn't really the problem here, it's the
>> rpms themselves, constantly doing ldconfigs, cache updates, tonnes of
>> hardlinking, etc...
>
> From what I experience, SELinux policy updates are by far means the most
> resource intense/most time consuming part of updating.
Really? For me, it's always OOo updates... 100 MB in a single package?
(What's worse is that OOo can't be updated while running... it doesn't
crash, but it becomes unable to save; bad news if you forgot to save first.
That and Firefox are the only things I'm aware of with that problem, but at
least with FF it only breaks typing addresses into the address bar.)
Whereas selinux is a 2.0 MB package :-).
Its not about the filesize but about the scripts that run on upgrade.
3:16 a.m.
Jesse Keating wrote:
People in bandwidth rich situations and with new expensive fast
hardware
may not see a problem. Those without certainly do.
Those who do not have the bandwidth to pull Fedora updates shouldn't be
running Fedora. There are plenty of distros with few updates which would be
a lot more suitable for people with slow Internet connections.
IMHO we should add "broadband Internet connection" to Fedora's system
requirements and list it prominently on the download page.
That said, Presto would certainly help a lot there. Too bad it's still not
officially supported. :-(
Kevin Kofler
11:43 a.m.
On Tue, 2009-01-27 at 10:16 +0100, Kevin Kofler wrote:
Those who do not have the bandwidth to pull Fedora updates
shouldn't be
running Fedora. There are plenty of distros with few updates which would be
a lot more suitable for people with slow Internet connections.
IMHO we should add "broadband Internet connection" to Fedora's system
requirements and list it prominently on the download page.
That's the kind of elitist crap attitude I hate to see in Fedora.
I agree that broadband should be a requirement for using /rawhide/ where
the churn is expected to be great, however I refuse to agree that we
should treat our /stable/ releases in the same way.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
2:07 p.m.
Jesse Keating wrote:
That's the kind of elitist crap attitude I hate to see in
Fedora.
I agree that broadband should be a requirement for using /rawhide/ where
the churn is expected to be great, however I refuse to agree that we
should treat our /stable/ releases in the same way.
Guess what, people like me are using Fedora *because* of its many updates.
That's its niche. If we start pushing only minimal updates, what
distinguishes us from Ubuntu? They also release every 6 months. Having all
distros work the same way means we're all forced to use the "common
denominator" even if it doesn't fit our needs at all.
IMHO people with slow Internet connections are served much better by CentOS:
few updates (only security updates and the occasional bugfix) and no need
to upgrade to a new release (which they have to buy on media, most likely)
at least once a year.
We can try to serve those people with features like Presto (and IMHO it
should have a much higher priority, as it indeed lowers the bar for the
bandwidth requirements and it'll also help mirrors and speed up downloads
for everyone) and LZMA payloads, but dropping one of Fedora's main
distinguishing features just to accomodate low-bandwidth users is really
throwing the baby out with the bathwater!
Kevin Kofler
2:28 p.m.
On Wed, 2009-01-28 at 21:07 +0100, Kevin Kofler wrote:
Guess what, people like me are using Fedora *because* of its many
updates.
That's its niche. If we start pushing only minimal updates, what
distinguishes us from Ubuntu? They also release every 6 months. Having all
distros work the same way means we're all forced to use the "common
denominator" even if it doesn't fit our needs at all.
You know just as well as I do that there is reasonable middle ground
between every upstream release every where every time, and the slowness
that is CentOS or maybe even ubuntu.
All I ask is that updates are being made for actual reasons that benefit
the end user and are easy to explain to the end user, something other
than "well it has a higher number, thus it must be better."
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
6:07 p.m.
Rahul Sundaram wrote:
Chris Weyl wrote:
>
> It's hardly a "small additional cost", especially when looked at in
> aggregate; this would be an additional non-automateable step required
> for every update release that is of very questionable value/utility to
> the vast majority of our users.
I wouldn't say that. Currently it is of questionable value currently but
it would be much more valuable without just version bumping and more
careful thought put into justifying the need for updates. Every update
adds to a large cost in terms of build time, bandwidth, potential
regressions etc.
I find it unreasonable to ask of package maintainers to take the role of
technical writers. Anything beyond copy/pasting will widen the gap
between packages maintained by native english speakers and packages that
aren't. ChangeLog typically contains a large number of fairly detailed
technical changes that has no place in the RPM spec log or in bodhi. i
think it's unreasonable to ask anything more that a comment such as 'bug
fix release' or 'introduces some new features'.
-denis
6:18 p.m.
On Tue, 2009-01-27 at 01:07 +0100, Denis Leroy wrote:
I find it unreasonable to ask of package maintainers to take the
role of
technical writers. Anything beyond copy/pasting will widen the gap
between packages maintained by native english speakers and packages that
aren't. ChangeLog typically contains a large number of fairly detailed
technical changes that has no place in the RPM spec log or in bodhi. i
think it's unreasonable to ask anything more that a comment such as 'bug
fix release' or 'introduces some new features'.
Particularly in the case of updates-testing, if you want your users to
know what they're supposed to test for, you need to provide accurate
information about why you're putting this update out to test.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3 a.m.
Denis Leroy wrote:
I find it unreasonable to ask of package maintainers to take the role
of
technical writers. Anything beyond copy/pasting will widen the gap
between packages maintained by native english speakers and packages that
aren't. ChangeLog typically contains a large number of fairly detailed
technical changes that has no place in the RPM spec log or in bodhi. i
think it's unreasonable to ask anything more that a comment such as 'bug
fix release' or 'introduces some new features'.
Adding a reference and a sentence or two does not need any technical
writer. Besides, being a technical writer isn't that hard. I was one for
a while.
Rahul
3:20 a.m.
Denis Leroy wrote:
I find it unreasonable to ask of package maintainers to take the role
of
technical writers.
Oh come on, writing a couple of sentences to explain what's new and why it's
being pushed doesn't need a technical writer at all.
Anything beyond copy/pasting will widen the gap between packages
maintained by native english speakers and packages that aren't.
Your English is just fine. Why are the ones who speak practically perfect
English (Nicolas Mailhot and you so far) the ones who complain about
this? ;-)
ChangeLog typically contains a large number of fairly detailed
technical
changes that has no place in the RPM spec log or in bodhi.
That's clear. But that's why it would be nice to summarize it. In those
cases where it really can't be done, a link (URL) to the upstream changelog
is easy to add.
i think it's unreasonable to ask anything more that a comment
such
as 'bug fix release' or 'introduces some new features'.
I don't.
Kevin Kofler
3:47 a.m.
Le Mar 27 janvier 2009 10:20, Kevin Kofler a écrit :
> Anything beyond copy/pasting will widen the gap between packages
> maintained by native english speakers and packages that aren't.
Your English is just fine. Why are the ones who speak practically
perfect
English (Nicolas Mailhot and you so far) the ones who complain about
this? ;-)
Because the others do not have the necessary English skills to parse
or participate in a complex fedora-devel debate.
That does not mean they can't and do not do good packaging, as long as
they're not asked to write English essays. (not that I disagree with
Jesse's point people are too hasty to push updates Bodhi-side, but
this is not the correct way to stem the tide).
Again, the value of this information is limited at best and only
concerns a very small user minority that both speaks English and
understands technical jargon (ie, not a lot of people). Even those who
have some grasp of English would usually not be able to parse it!
The typical writing you Rahul asks of, even if it was perfectly filed,
would be as useful to our average user as:
« Corrigé le fripouillard qui perturbait l'ordonnancement des travaux
de mise à jour du schmilblick (inversion de priorité dans le zorglub)
»
ie something that vaguely mimics a foreign language taught as school
with enough jargon and arcane references to be totally unparsable.
--
Nicolas Mailhot
7:14 p.m.
Nicolas Mailhot <nicolas.mailhot(a)laposte.net> wrote:
[...]
Again, the value of this information is limited at best and only
concerns a very small user minority that both speaks English and
understands technical jargon (ie, not a lot of people). Even those who
have some grasp of English would usually not be able to parse it!
But those people are almost exactly the ones interested in that
information. To do anything at all in <name technical field here> today,
English (at least simple technical English) is a must.
--
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 2340000 Fax: +56 32 2797513
12:05 a.m.
Le mardi 27 janvier 2009 à 22:14 -0300, Horst H. von Brand a écrit :
Nicolas Mailhot <nicolas.mailhot(a)laposte.net> wrote:
[...]
> Again, the value of this information is limited at best and only
> concerns a very small user minority that both speaks English and
> understands technical jargon (ie, not a lot of people). Even those who
> have some grasp of English would usually not be able to parse it!
But those people are almost exactly the ones interested in that
information. To do anything at all in <name technical field here> today,
English (at least simple technical English) is a must.
You seriously need to take some distance. The kind of English you'll
find in those notifications is totally foreign and useless to the vast
majority of our user base. It's not technical English it's pure CS
jargon very few people speak.
A very small minority may be able to parse it, but a versy small
minority is not a sufficient reason to impose this burden on packagers.
--
Nicolas Mailhot
3:18 p.m.
Kevin Kofler wrote:
Denis Leroy wrote:
> I find it unreasonable to ask of package maintainers to take the role of
> technical writers.
Oh come on, writing a couple of sentences to explain what's new and why it's
being pushed doesn't need a technical writer at all.
Ok, here's a little exercise :-)
Below is the ChangeLog of gtkmm-2.15.0, which I pushed to rawhide a
while ago. How would you summarize it to Bodhi ?
---------------------------------------------------------------------------------
2.15.0:
2009-01-01 Murray Cumming <murrayc(a)murrayc.com>
* gtk/src/cellrendererpixbuf.hg: Added the icon-name and follow-state
properties, noticed by Mathias Hasselmann.
2009-01-01 Armin Burgmeier <armin(a)openismus.com>
* gtk/src/printer.ccg (SignalProxy_Custom_gtk_callback): Take a new
reference on the passed printer object, so that we don't unref it at
the end of the function (Tor Krill).
2008-12-22 Murray Cumming <murrayc(a)murrayc.com>
* gdk/src/gdk_docs_override.xml: Correct the documentation for
gdk_window_invalidate_rect() to remove C-specific text.
* gdk/src/window.ccg:
* gdk/src/window.hg: Added an invalidate() that takes no rect
parameter because it can be NULL in C.
2008-12-10 Przemysław Grzegorczyk <pgrzegorczyk(a)gmail.com>
* Cleaned up gtk includes to use only toplevel headers
Bug #564006
2008-12-08 Murray Cumming <murrayc(a)murrayc.com>
* gtk/src/treemodel.hg: set_value_impl() documentation: Mention
row_changed(), not set_row_changed().
Bug #562505 (Bohumir Zamecnik)
2008-12-06 Murray Cumming <murrayc(a)murrayc.com>
* gtk/src/container.hg:
* gtk/src/gtk_vfuncs.defs: Use GType instead of GtkType for the
child_type_vfunc() return type, because that seems to have changed in
GTK+ and GtkType is deprecated. Likewise, use GDestroyNotify in other
vfuncs instead of GtkDestroyNotify.
This should allow soure code to use gtkmm if it declares
GTK_DISABLE_DEPRECATED.
Bug #562893 (Dénes Faluvégi)
2008-11-18 Murray Cumming <murrayc(a)murrayc.com>
* configure.in:
* docs/FAQ/Makefile.am:
* docs/FAQ/gtkmm-faq.xml:
* docs/Makefile.am: Remove the FAQ because we moved it to
gtkmm-documentation months ago.
2008-11-14 Murray Cumming <murrayc(a)murrayc.com>
* gtk/src/gtk_signals.defs: Restored the GtkHandleBox::child-attached
signal definition and the GtkLinkButton::visited property definition,
so these are really put in the API. At some point in 2.14.x we lost
these.
2008-11-09 Alexander Shaduri <ashaduri(a)gmail.com>
* gtk/src/cellview.ccg:
* gtk/src/cellview.hg: Added unset_model().
* gtk/src/combobox.ccg:
* gtk/src/combobox.hg: Added unset_model().
* gtk/src/entrycompletion.ccg:
* gtk/src/entrycompletion.hg: Added unset_model().
* gtk/src/iconview.ccg:
* gtk/src/iconview.hg: Added unset_model().
* gtk/src/treeview.hg: Marked unset_model() as available since 2.8.
* gtk/src/gtk_docs_override.xml: Added overrides for
gtk_tree_view_set_model(), gtk_cell_view_set_model(),
gtk_entry_completion_set_model(), gtk_entry_completion_set_model()
and gtk_combo_box_set_model(), because their documentation
contained an incorrect method of unsetting the models.
Bug #555268
This is trunk for API additions. See also the gtkmm-2-14 branch.
3:24 p.m.
On Tue, 2009-01-27 at 22:18 +0100, Denis Leroy wrote:
Kevin Kofler wrote:
> Denis Leroy wrote:
>> I find it unreasonable to ask of package maintainers to take the role of
>> technical writers.
>
> Oh come on, writing a couple of sentences to explain what's new and why
it's
> being pushed doesn't need a technical writer at all.
Ok, here's a little exercise :-)
Below is the ChangeLog of gtkmm-2.15.0, which I pushed to rawhide a
while ago. How would you summarize it to Bodhi ?
Update to 2.15.0
:-)
On a more serious note, I tend to look at release announcements / NEWS
files when I try to collect update information for new releases. Proper
releases should have the user-relevant information about the new release
in those places, as opposed to all the minutiae in the ChangeLog...
2:30 p.m.
Denis Leroy wrote:
Below is the ChangeLog of gtkmm-2.15.0, which I pushed to rawhide a
while ago. How would you summarize it to Bodhi ?
Ugh, doesn't upstream provide a more user-readable list of changes? IMHO
they should get that complaint...
And it's true that it's particularly hard to summarize bugfixes in a library
(like that printer signal proxy fix) without knowing a concrete application
bug they fix.
In any case, try this:
Update to the latest upstream release, 2.15.0, which fixes the use of some
deprecated APIs and header files (which caused programs using gtkmm with
GTK_DISABLE_DEPRECATED to fail to build) and a bug in the printer signal
proxy which could cause application crashes (the printer object was being
unreferenced at an inappropriate place), adds some new APIs which may be
required to compile new gtkmm-using software:
* GtkHandleBox::child-attached (signal) and GtkLinkButton::visited
(property), which were accidentally missing in 2.14.x
* unset_model() methods for GtkCellView, GtkComboBox, GtkEntryCompletion,
GtkIconView and GtkTreeView
* a parameterless version of GtkWindow::invalidate()
* GtkCellRendererPixbuf::icon-name and GtkCellRendererPixbuf::follow-state
(properties)
and includes some minor documentation fixes.
But I'll admit this took me several minutes to write.
Kevin Kofler
3:38 a.m.
Kevin Kofler wrote:
Denis Leroy wrote:
> Below is the ChangeLog of gtkmm-2.15.0, which I pushed to rawhide a
> while ago. How would you summarize it to Bodhi ?
Ugh, doesn't upstream provide a more user-readable list of changes? IMHO
they should get that complaint...
They do actually, they provide the NEWS files which is a bit shorter
(although this one is unusually long, they're typically 3 to 4
bullet-point long) :
* CellRendererPixbuf: Added the icon-name and follow-state
properties, noticed by Mathias Hasselmann.
(Murray Cumming)
* Printer::enumerate_printers(): Fix a refcounting problem found by Tor
Krill.
(Armin Burgmeier)
* Gdk::Window: Added an invalidate() that takes no rect
parameter because it can be NULL in C.
(Murray Cumming)
* Cleaned up gtk includes to use only toplevel headers, as may be
required by
a future GTK+ version.
(Przemysław Grzegorczyk) Bug #564006
* Container: Use GType instead of GtkType for the child_type_vfunc()
return type
This should allow soure code to use gtkmm if it declares
GTK_DISABLE_DEPRECATED.
(Murray Cumming) Bug #562893 (Dénes Faluvégi)
* Documentation:
TreeModel: set_value_impl() documentation: Mention row_changed(),
not set_row_changed(). Bug #562505 (Bohumir Zamecnik)
* HandleBox: Restore the child-attached property, which was lost at some
point
during 2.14.
* LinkButton: Resore the visited property definition, which was lost at
some
point during 2.14.
(Murray Cumming)
* CellView, ComboBox, EntryCompletion, IconView: Added unset_model().
(Alexander Shaduri) Bug #555268
And it's true that it's particularly hard to summarize
bugfixes in a library
(like that printer signal proxy fix) without knowing a concrete application
bug they fix.
In any case, try this:
Update to the latest upstream release, 2.15.0, which fixes the use of some
deprecated APIs and header files (which caused programs using gtkmm with
GTK_DISABLE_DEPRECATED to fail to build) and a bug in the printer signal
proxy which could cause application crashes (the printer object was being
unreferenced at an inappropriate place), adds some new APIs which may be
required to compile new gtkmm-using software:
* GtkHandleBox::child-attached (signal) and GtkLinkButton::visited
(property), which were accidentally missing in 2.14.x
* unset_model() methods for GtkCellView, GtkComboBox, GtkEntryCompletion,
GtkIconView and GtkTreeView
* a parameterless version of GtkWindow::invalidate()
* GtkCellRendererPixbuf::icon-name and GtkCellRendererPixbuf::follow-state
(properties)
and includes some minor documentation fixes.
But I'll admit this took me several minutes to write.
Good job :-) But this whole exercise is futile. We DO ALREADY ship both
the ChangeLog and the NEWS files in the documentation directory, either
with the library or development package. How is repeating or summarizing
these internal changes *on Bodhi* useful to anyone ?
- If you're a gtkmm developper, you will not read the Bodhi information
as you probably already know about the update already, you'll go
straight to the NEWS or ChangeLog file shipped with the RPM (or on the
GNOME FTP site) to see if any of the changes impact your work.
- If you're not a gtkmm developper, the information above is impossible
to understand and not useful at all. At best you want to know if the
update is a bugfix update, or what ? not a bugfix update ? new features
? how is that useful ? If a library update maybe fixes an occasional
crash in an application that uses it, how can you tell that the problem
was fixed by "Printer::enumerate_printers(): Fix a refcounting problem"
? As a Fedora user, how is that information going to affect your
decision making ? Are you going to decline a package update if the
summary doesn't include some key words ? (I call BS on anyone answering
yes to that).
So the concept of summarizing the ChangeLog for Bodhi imposes a heavy
burden on packagers for little added value.
Don't get me wrong, I'm not saying the "Notes" field in Bodhi is
useless. First, linking Bodhi updates with bugzilla entries is extremely
useful to start with. And if you're pushing a user-visible application,
I'd want to know if this adds some interesting new features to it, no
doubt. But it'd be easier to have a Bodhi field where one can paste a
URL pointing to the "News" or "Changes" section of the upstream
webiste,
or linking with the Gnome FTP NEWS file...
-denis
4:08 a.m.
On Thu, 2009-01-29 at 10:38 +0100, Denis Leroy wrote:
...
> a bug in the printer signal
> proxy which could cause application crashes (the printer object was being
> unreferenced at an inappropriate place),
...
Good job :-) But this whole exercise is futile. We DO ALREADY ship
both
the ChangeLog and the NEWS files in the documentation directory, either
with the library or development package. How is repeating or summarizing
these internal changes *on Bodhi* useful to anyone ?
Kevin's summary does something the NEWS file does not - it calls out a
particular crasher bug that could affect user applications. IMHO, that
is the only truly compelling reason a user has to apply this update and
it is the most user relevant part of Kevin's description.
As a Fedora user, how is that information going to affect your
decision making ? Are you going to decline a package update if the
summary doesn't include some key words ? (I call BS on anyone
answering yes to that).
It's a fair point that not many users would decline the update just
because it doesn't fix a bug which affects them. It's not so much about
decision making, it's about having some explanation as to why the update
is important.
If PackageKit pops up tells you there are 50 updates pending, it's much
nicer if you can scan through the descriptions and come away with the
conclusion that "oh, there's a bunch of important fixes in there" rather
than "this is just a bunch of gratuitous updates, but if I don't apply
them all I might miss something important".
Cheers,
Mark.
4:25 a.m.
Mark McLoughlin wrote:
It's a fair point that not many users would decline the update
just
because it doesn't fix a bug which affects them. It's not so much about
decision making, it's about having some explanation as to why the update
is important.
If it's a bugfix release, it's important. period. Bodhi has a combobox
that specifies that. Whether the bug fix will affect a particular user
or not if nearly impossible to determine.
If PackageKit pops up tells you there are 50 updates pending,
it's much
nicer if you can scan through the descriptions and come away with the
conclusion that "oh, there's a bunch of important fixes in there" rather
than "this is just a bunch of gratuitous updates, but if I don't apply
them all I might miss something important".
The necessary vs unnecessary update is a completely different problem,
although it's also addressed by the draft and that's causing an
overreaction on the documentation side. I'm pretty sure everyone agrees
that updates to stable releases should be picked carefully by packagers.
-denis
2:20 p.m.
On Thu, Jan 29, 2009 at 2:08 AM, Mark McLoughlin <markmc(a)redhat.com> wrote:
On Thu, 2009-01-29 at 10:38 +0100, Denis Leroy wrote:
> Good job :-) But this whole exercise is futile. We DO ALREADY ship both
> the ChangeLog and the NEWS files in the documentation directory, either
> with the library or development package. How is repeating or summarizing
> these internal changes *on Bodhi* useful to anyone ?
Kevin's summary does something the NEWS file does not - it calls out a
particular crasher bug that could affect user applications. IMHO, that
is the only truly compelling reason a user has to apply this update and
it is the most user relevant part of Kevin's description.
We already provide the ability to link to bugs in the update; I don't
see the logic in duplicating the information here.
-Chris
--
Chris Weyl
Ex astris, scientia
1:32 a.m.
On Thu, 2009-01-29 at 12:20 -0800, Chris Weyl wrote:
On Thu, Jan 29, 2009 at 2:08 AM, Mark McLoughlin
<markmc(a)redhat.com> wrote:
> On Thu, 2009-01-29 at 10:38 +0100, Denis Leroy wrote:
> > Good job :-) But this whole exercise is futile. We DO ALREADY ship both
> > the ChangeLog and the NEWS files in the documentation directory, either
> > with the library or development package. How is repeating or summarizing
> > these internal changes *on Bodhi* useful to anyone ?
>
> Kevin's summary does something the NEWS file does not - it calls out a
> particular crasher bug that could affect user applications. IMHO, that
> is the only truly compelling reason a user has to apply this update and
> it is the most user relevant part of Kevin's description.
We already provide the ability to link to bugs in the update; I don't
see the logic in duplicating the information here.
Agreed, if a bug fix update includes the bugs it fixes in the Bugs
field, it is in good shape already.
Updated the text to read:
Fedora users who do not update automatically may review the
descriptions attached to updates before choosing whether they should
apply them.
Package maintainers should bear this in mind when preparing updates
in bodhi and try to help their users make as informed decisions as
possible. The Bugs and Notes fields are all the information which
users have available when reviewing updates in the PackageKit UI (and
not e.g. the RPM %changelog entries).
Some suggestions on what to include in an update:
1. For bug fixes, the appropriate bug numbers in the Bugs field
2. For security issues, links to the appropriate CVEs
3. For new upstream releases, a summary of the important changes
and/or a link to the upstream changelog
4. Any other information that might be important to users
Good judgement is required, though. Overly verbose descriptions can
be almost as useless as overly terse descriptions.
Thanks,
Mark.
12:41 p.m.
Denis Leroy wrote:
They do actually, they provide the NEWS files which is a bit shorter
(although this one is unusually long, they're typically 3 to 4
bullet-point long) :
OK, so they're trying to make a nice summary, but in this case they weren't
all that successful. :-(
Kevin Kofler
4:02 p.m.
Chris Weyl wrote:
It's hardly a "small additional cost", especially when
looked at in
aggregate; this would be an additional non-automateable step required
for every update release that is of very questionable value/utility to
the vast majority of our users. I realize it would make your life
easier, but is it worth an additional imposition on our already
highly-regulated maintainers just to make your life easier? I stand
by my earlier assessment that the vast bulk of our users could care
less, and those that do care would know how to find a package's
changelog. If this is important, we should find some way of
automatically including a pointer to upstream's changelog in the
update tool itself.
As one of those maintainers who always fill in useful update notes, I'll say
that:
* Updates should include at least one sentence of rationale why they're
being pushed, and either a summary of the changes or the URL of such a
summary from upstream. (And in some cases the rationale and the summary of
changes are the same thing - if the update fixes some critical bug, that's
an obvious reason to push it.) IMHO updates with empty update details
should get rejected by Bodhi outright, and there should also be a policy
that "update to 1.2.3" is not sufficient.
* It takes almost no time to fill that in. You have to fill in a form for
the update anyway, typing a sentence or two and copying&pasting a URL into
it isn't going to hurt your fingers.
* I'm not a fan of selective updates at all (they tend not to work
properly), but as a user I still want to know *what* I'm getting in the
update. Each time I see an update with blank update notes or just "new
upstream version", I feel an urge to kick the maintainer in the rear.
You can see my updates for examples of how I'd expect update details to look
like:
https://admin.fedoraproject.org/updates/user/kkofler
They're not always perfect (for example, I should have tried to figure out
what changed in the latest qt-copy patches included in that qt-4.4.3-6.fc10
update - I did give the rationale for pushing it though (fixing the upgrade
path from F9)), but if you can do as good as me, that'd already be
great. ;-) And it isn't that much work.
So in case it wasn't obvious I'm in favor of a policy for useful update
details.
Kevin Kofler
2:35 p.m.
Le mardi 27 janvier 2009 à 01:17 +0530, Rahul Sundaram a écrit :
Chris Weyl wrote:
> Let's not make anything more difficult for the package maintainers,
> eh?
In general, I certainly agree but policies weren't introduced in the
last to make life harder for maintainers but easier for end users and
for a small additional cost to maintainers,
A lot of policies are introduced to make maintainer life easier and help
them avoid known pitfalls. If they all added a new layer, the whole
distribution would become unmaintainable.
I believe the reason rpm has so far avoided triaging upstream-provided
doc and puts it all indiscriminately in %doc, is that the packager
triaging cost is just too high.
Before more English writing is asked of packagers (most of whom are not
native English speakers), in an area the average non-techie user doesn't
consult, and which is useless to a lot of people since it's not
translated, it would be great if some editors did review, fix and
improve of all our package summaries and descriptions, which is
something that *would* have high user impact, and *would* make packager
life easier, by relieving them of a shore which has nothing to do with
technical packaging.
And I'm sure all the localization teams that have to translate the
pidgin English some of us use would cheer too.
--
Nicolas Mailhot
4:11 p.m.
Nicolas Mailhot wrote:
Before more English writing is asked of packagers (most of whom are
not
native English speakers), in an area the average non-techie user doesn't
consult, and which is useless to a lot of people since it's not
translated, it would be great if some editors did review, fix and
improve of all our package summaries and descriptions, which is
something that *would* have high user impact, and *would* make packager
life easier, by relieving them of a shore which has nothing to do with
technical packaging.
IMHO update details are at least as important as the summaries and
descriptions.
They're not translated, but that's the nature of current information.
There's just no time to translate it. In fact, I think our process of
freezing release notes early so they can get translated is harmful, I'd
rather have current information in English (which is only my 4th language!)
than old translated information.
And I'm sure all the localization teams that have to translate
the
pidgin English some of us use would cheer too.
Your English is just fine, in fact I didn't notice a single error in your
entire mail. Most if not all Fedora maintainers are writing decent to
flawless English.
Kevin Kofler
6:13 p.m.
Patrice Dumas <pertusus(a)free.fr> wrote:
[...]
... The only thing I see that could be made
mandatory,
would be to associate it with the fedora bugs that were solved by this
update.
It has happened more than one time to me that my bugs were fixed without
the packager noticing/being able to tell.
--
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 2340000 Fax: +56 32 2797513
8:38 a.m.
Is rpm still this other-worldly tool which we're not allowed to
change, even for blindingly obvious stuff like needing an identical
%clean section in every RPM in the world?
Anyway, _if_ we are allowed to change rpm, then we could have
%doc(changelog) ChangeLog
which would be the upstream changelog, and other tools could pull this
out and display it to end users to their hearts' content.
And it would involve only minimal extra effort for packagers.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
8:54 a.m.
Richard W.M. Jones wrote:
Is rpm still this other-worldly tool which we're not allowed to
change, even for blindingly obvious stuff like needing an identical
%clean section in every RPM in the world?
Anyway, _if_ we are allowed to change rpm, then we could have
%doc(changelog) ChangeLog
which would be the upstream changelog, and other tools could pull this
out and display it to end users to their hearts' content.
And it would involve only minimal extra effort for packagers.
rpm.org is pretty active now and still focused on bug fixes and solving
common issues like these, primarily. If you have RFE's please file them
at http://rpm.org trac.
Rahul
10:27 a.m.
On Mon, Jan 26, 2009 at 08:24:57PM +0530, Rahul Sundaram wrote:
rpm.org is pretty active now and still focused on bug fixes and
solving
common issues like these, primarily. If you have RFE's please file them
at http://rpm.org trac.
Added:
http://rpm.org/ticket/24
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
10:28 a.m.
On Mon, 26 Jan 2009, Richard W.M. Jones wrote:
Is rpm still this other-worldly tool which we're not allowed to
change, even for blindingly obvious stuff like needing an identical
%clean section in every RPM in the world?
Heh, too bad names like "Plan-9" and "alien" are already taken ;)
Sure we can and do change rpm, but changes in rpm world tend to take ages
to get actually deployed & used. Yes, even in Fedora.
Anyway, _if_ we are allowed to change rpm, then we could have
%doc(changelog) ChangeLog
which would be the upstream changelog, and other tools could pull this
out and display it to end users to their hearts' content.
And it would involve only minimal extra effort for packagers.
But what exactly would that solve? The ChangeLog file would be in the rpm
payload, so the contents are only accessible after the package has already
been installed. The intended audience here seems to be "end users", to
whom the raw upstream SCM changelogs aren't often that useful. Somebody
has to actually write the nice end-user friendly executive summaries for
packages, they unfortunately don't come to existence by wishing :)
If it's the Bodhi update messages we're primarily talking about here, then
how about just adding an optional field for a link to the upstream release
notes/summary for the upstreams that happen to provide nice end-user
friendly release summaries?
- Panu -
11:43 a.m.
On Mon, Jan 26, 2009 at 06:28:43PM +0200, Panu Matilainen wrote:
But what exactly would that solve? The ChangeLog file would be in the
rpm
payload, so the contents are only accessible after the package has
already been installed.
Yum already pulls out lots of meta-info from the RPMs and stores it in
its own database, eg:
$ zless repodata/primary.xml.gz
[...]
<package type="rpm">
<name>mingw32-portablexdr</name>
<arch>noarch</arch>
<version epoch="0" ver="4.0.11" rel="1.fc10"/>
[...]
<summary>MinGW Windows PortableXDR XDR / RPC library</summary>
<description>MinGW Windows PortableXDR XDR / RPC library.</description>
<packager></packager>
<url>http://et.redhat.com/~rjones/portablexdr/</url>
<time file="1227118253" build="1227118253"/>
<size package="33005" installed="104342"
archive="105656"/>
<location href="RPMS/mingw32-portablexdr-4.0.11-1.fc10.noarch.rpm"/>
<format>
<rpm:license>LGPLv2+</rpm:license>
<rpm:vendor/>
<rpm:group>Development/Libraries</rpm:group>
<rpm:buildhost>intel-mb</rpm:buildhost>
[...]
It can equally pull out the changelog file (or part of it) if required.
The intended audience here seems to be "end
users", to whom the raw upstream SCM changelogs aren't often that useful.
The stereotypical grandmum end user won't care about any of this
stuff. Giving people detailed changelogs is useful if you're trying
to find out what *really* changed in the package.
Additionally the metadata is useful for other tools, eg. rpm2html
which generates sites like http://rpmfind.net/
To be honest I can't see a downside to adding extra metadata to RPMs,
except that someone has to write the code to do it.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
11:45 a.m.
On Mon, 2009-01-26 at 17:43 +0000, Richard W.M. Jones wrote:
On Mon, Jan 26, 2009 at 06:28:43PM +0200, Panu Matilainen wrote:
> But what exactly would that solve? The ChangeLog file would be in the rpm
> payload, so the contents are only accessible after the package has
> already been installed.
Yum already pulls out lots of meta-info from the RPMs and stores it in
its own database, eg:
It can equally pull out the changelog file (or part of it) if required.
> The intended audience here seems to be "end
> users", to whom the raw upstream SCM changelogs aren't often that useful.
The stereotypical grandmum end user won't care about any of this
stuff. Giving people detailed changelogs is useful if you're trying
to find out what *really* changed in the package.
Additionally the metadata is useful for other tools, eg. rpm2html
which generates sites like http://rpmfind.net/
To be honest I can't see a downside to adding extra metadata to RPMs,
except that someone has to write the code to do it.
And we potentially have to change the sqlite db format and the repodata
formats to accommodate them.
So, it better be an important change.
-sv
11:50 a.m.
On Mon, Jan 26, 2009 at 12:45:12PM -0500, seth vidal wrote:
On Mon, 2009-01-26 at 17:43 +0000, Richard W.M. Jones wrote:
> On Mon, Jan 26, 2009 at 06:28:43PM +0200, Panu Matilainen wrote:
> > But what exactly would that solve? The ChangeLog file would be in the rpm
> > payload, so the contents are only accessible after the package has
> > already been installed.
>
> Yum already pulls out lots of meta-info from the RPMs and stores it in
> its own database, eg:
>
> It can equally pull out the changelog file (or part of it) if required.
>
> > The intended audience here seems to be "end
> > users", to whom the raw upstream SCM changelogs aren't often that
useful.
>
> The stereotypical grandmum end user won't care about any of this
> stuff. Giving people detailed changelogs is useful if you're trying
> to find out what *really* changed in the package.
>
> Additionally the metadata is useful for other tools, eg. rpm2html
> which generates sites like http://rpmfind.net/
>
> To be honest I can't see a downside to adding extra metadata to RPMs,
> except that someone has to write the code to do it.
And we potentially have to change the sqlite db format and the repodata
formats to accommodate them.
The repodata is in XML where the X stands for eXtensible. Extra
fields should be ignored if not used.
Typical SQL databases don't mind at all if you add extra columns to
tables. Whether this is true of the on-disk binary(?) format used by
sqlite I have no idea, but if the sqlite format cannot handle such
changes, then it surely must be the wrong format for the task.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
11:57 a.m.
On Mon, 2009-01-26 at 17:50 +0000, Richard W.M. Jones wrote:
On Mon, Jan 26, 2009 at 12:45:12PM -0500, seth vidal wrote:
> On Mon, 2009-01-26 at 17:43 +0000, Richard W.M. Jones wrote:
> > On Mon, Jan 26, 2009 at 06:28:43PM +0200, Panu Matilainen wrote:
> > > But what exactly would that solve? The ChangeLog file would be in the rpm
> > > payload, so the contents are only accessible after the package has
> > > already been installed.
> >
> > Yum already pulls out lots of meta-info from the RPMs and stores it in
> > its own database, eg:
> >
> > It can equally pull out the changelog file (or part of it) if required.
> >
> > > The intended audience here seems to be "end
> > > users", to whom the raw upstream SCM changelogs aren't often that
useful.
> >
> > The stereotypical grandmum end user won't care about any of this
> > stuff. Giving people detailed changelogs is useful if you're trying
> > to find out what *really* changed in the package.
> >
> > Additionally the metadata is useful for other tools, eg. rpm2html
> > which generates sites like http://rpmfind.net/
> >
> > To be honest I can't see a downside to adding extra metadata to RPMs,
> > except that someone has to write the code to do it.
>
> And we potentially have to change the sqlite db format and the repodata
> formats to accommodate them.
The repodata is in XML where the X stands for eXtensible. Extra
fields should be ignored if not used.
heh, that's quaint.
Typical SQL databases don't mind at all if you add extra columns to
tables. Whether this is true of the on-disk binary(?) format used by
sqlite I have no idea, but if the sqlite format cannot handle such
changes, then it surely must be the wrong format for the task.
I never said it couldn't be extended. But if we do add to it we should
have a good reason. That's all I said.
-sv
11:51 a.m.
On Mon, Jan 26, 2009 at 12:48:49PM -0500, Bill Nottingham wrote:
Richard W.M. Jones (rjones(a)redhat.com) said:
> Yum already pulls out lots of meta-info from the RPMs and stores it in
> its own database, eg:
>
> $ zless repodata/primary.xml.gz
...
*All* of that is in the RPM header. It's not pulling anything out of the
file payload.
So? createrepo would need to parse a bit more of the RPM.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
11:59 a.m.
On Mon, 2009-01-26 at 17:51 +0000, Richard W.M. Jones wrote:
On Mon, Jan 26, 2009 at 12:48:49PM -0500, Bill Nottingham wrote:
> Richard W.M. Jones (rjones(a)redhat.com) said:
> > Yum already pulls out lots of meta-info from the RPMs and stores it in
> > its own database, eg:
> >
> > $ zless repodata/primary.xml.gz
> ...
>
> *All* of that is in the RPM header. It's not pulling anything out of the
> file payload.
So? createrepo would need to parse a bit more of the RPM.
Please, lets not make createrepo any slower. A lot of hard work has
gone into getting it as fast as it is today, I don't want to see that
move the other direction.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
12:17 p.m.
Richard W.M. Jones (rjones(a)redhat.com) said:
> *All* of that is in the RPM header. It's not pulling
anything out of the
> file payload.
So? createrepo would need to parse a bit more of the RPM.
1) Having createrepo have to parse the entire cpio metadata to
look for a particular file would be insanely slow
2) I just picked a random package I maintain. The ChangeLog is
1.4MB uncompressed, 326k compressed. Even if that's larger than
typical, imagine scaling that out across 7000 source packages,
and then the size of the resulting XML to download...
Bill
12:28 p.m.
On Mon, 2009-01-26 at 13:17 -0500, Bill Nottingham wrote:
1) Having createrepo have to parse the entire cpio metadata to
look for a particular file would be insanely slow
2) I just picked a random package I maintain. The ChangeLog is
1.4MB uncompressed, 326k compressed. Even if that's larger than
typical, imagine scaling that out across 7000 source packages,
and then the size of the resulting XML to download...
Not to mention that the CHANGELOG is typically in the -docs package,
whereas the repo being generated may not /have/ the -docs package.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
12:30 p.m.
On Mon, Jan 26, 2009 at 01:17:40PM -0500, Bill Nottingham wrote:
Richard W.M. Jones (rjones(a)redhat.com) said:
> > *All* of that is in the RPM header. It's not pulling anything out of the
> > file payload.
>
> So? createrepo would need to parse a bit more of the RPM.
1) Having createrepo have to parse the entire cpio metadata to
look for a particular file would be insanely slow
2) I just picked a random package I maintain. The ChangeLog is
1.4MB uncompressed, 326k compressed. Even if that's larger than
typical, imagine scaling that out across 7000 source packages,
and then the size of the resulting XML to download...
In gcc ChangeLogs are 5.2MB bzip2 -9ed, glibc has 6.5MB of uncompressed
ChangeLogs (haven't checked how big they are compressed). Putting that
all into metadata is going to grow it a lot.
Jakub
1:05 p.m.
On Mon, 26 Jan 2009, Jakub Jelinek wrote:
On Mon, Jan 26, 2009 at 01:17:40PM -0500, Bill Nottingham wrote:
> Richard W.M. Jones (rjones(a)redhat.com) said:
>>> *All* of that is in the RPM header. It's not pulling anything out of the
>>> file payload.
>>
>> So? createrepo would need to parse a bit more of the RPM.
>
> 1) Having createrepo have to parse the entire cpio metadata to
> look for a particular file would be insanely slow
> 2) I just picked a random package I maintain. The ChangeLog is
> 1.4MB uncompressed, 326k compressed. Even if that's larger than
> typical, imagine scaling that out across 7000 source packages,
> and then the size of the resulting XML to download...
In gcc ChangeLogs are 5.2MB bzip2 -9ed, glibc has 6.5MB of uncompressed
ChangeLogs (haven't checked how big they are compressed). Putting that
all into metadata is going to grow it a lot.
...and the header data is not compressed whereas the payload is. It
would not only hugely bloat the download size but rpmdb size too. And
having it in metadata (ie in the header) would mean you'd have to use rpm
--someswitch to access it, whereas it's on the filesystem now. All doable,
but I *really* dont see the average upstream ChangeLog available as
metadata worth all this.
Adding a "news" or "changelog" file attribute would cost exactly one
bit
of a bitfield, that would be quite another story. Except .. well, rpm
already supports %readme and %license "file attributes", but nothing at
all uses them for anything. Part of that is probably that they aren't
compatible with %doc so they're pretty cumbersome to use in a spec. Maybe
that'd be worth fixing, and at least licenses are something that would
want special treatment anyway (ie get installed even with --nodocs)
- Panu -
1:13 p.m.
On Mon, 26 Jan 2009, Panu Matilainen wrote:
Adding a "news" or "changelog" file attribute
would cost exactly one bit of a
bitfield, that would be quite another story. Except .. well, rpm already
supports %readme and %license "file attributes", but nothing at all uses them
for anything. Part of that is probably that they aren't compatible with %doc
so they're pretty cumbersome to use in a spec. Maybe that'd be worth fixing,
and at least licenses are something that would want special treatment anyway
(ie get installed even with --nodocs)
...and of course, this is what the original request was about. Only then
you're back to the point that the file contents are in the payload, and
accessing it is way too expensive to do in createrepo. And still you'd get
this *huge* blob of xml/sqlite that you'd have to download to access the
data...
- Panu -
4:34 p.m.
On Mon, Jan 26, 2009 at 01:17:40PM -0500, Bill Nottingham wrote:
Richard W.M. Jones (rjones(a)redhat.com) said:
> > *All* of that is in the RPM header. It's not pulling anything out of the
> > file payload.
>
> So? createrepo would need to parse a bit more of the RPM.
1) Having createrepo have to parse the entire cpio metadata to
look for a particular file would be insanely slow
2) I just picked a random package I maintain. The ChangeLog is
1.4MB uncompressed, 326k compressed. Even if that's larger than
typical, imagine scaling that out across 7000 source packages,
and then the size of the resulting XML to download...
Perhaps this idea of including changelogs in the metdata is addressing
the issue with the wrong hammer. When getting a set of 50 updates, very
few users are likely to want or need the changelogs to all of them
prior to install. More likely, they'll just want to occassionaly read
a changelog for an ad-hoc package to find out some info.
This suggests that rather than including the full changelog for each
package in the createrepo metadata, just include a URL linking to the
changlog on a static webserver. It'd be easy enough to extract changelogs
for each newly built package somewhere easily linkable (and mirrorable if
neccessary). So on a rare occassion when a tool processing repodata does
want the changelog it can quickly download it on demand.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
5566
days inactive
5570
days old
123 comments
28 participants
participants (28)
-
Bill Nottingham -
Chris Weyl -
Dan Horák -
Daniel P. Berrange -
Denis Leroy -
drago01 -
Horst H. von Brand -
Jakub Jelinek -
James Antill -
Jef Spaleta -
Jesse Keating -
Jesse Keating -
Julian Sikorski -
Kevin Kofler -
Luke Macken -
Mark McLoughlin -
Mathieu Bridon -
Matthew Woehlke -
Matthias Clasen -
Nicolas Mailhot -
Panu Matilainen -
Patrice Dumas -
Rahul Sundaram -
Ralf Corsepius -
Richard Hughes -
Richard W.M. Jones -
Robert Scheck -
Seth Vidal