Discussion:
182 pending F11 stable updates. WTF?
(too old to reply)
Jesse Keating
2009-05-07 17:41:37 UTC
Permalink
How is it we have 182 stable updates pending for F11 already? How have
these seen any testing by a wider audience? Are we really just not
bothering with updates-testing anymore? Do we not care about distro
stability?

I know that many of these are newpackages, but many aren't though.
</frustrated>
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090507/cb7dc300/attachment.bin
Till Maas
2009-05-07 17:59:06 UTC
Permalink
Post by Jesse Keating
How is it we have 182 stable updates pending for F11 already? How have
these seen any testing by a wider audience? Are we really just not
bothering with updates-testing anymore? Do we not care about distro
stability?
Afaik, requests to updates-testing were not processed for F11, e.g. for one or
two of my new packages I requested updates-testing for F9, F10 and F11 at the
same time, got positive feedback / no negative feedback for F9 or F10 and then
moved them all to stable at the same time, resp. canceled the testing request
for F11 and made it to a stable one. I guess this affects also other packages,
that were updated in F9 or F10 and F11, to have a working update path from FX
with updates to FX+1 with updates.

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090507/07ec91a0/attachment.bin
Jesse Keating
2009-05-07 18:25:28 UTC
Permalink
Post by Till Maas
Afaik, requests to updates-testing were not processed for F11, e.g. for one or
two of my new packages I requested updates-testing for F9, F10 and F11 at the
same time, got positive feedback / no negative feedback for F9 or F10 and then
moved them all to stable at the same time, resp. canceled the testing request
for F11 and made it to a stable one. I guess this affects also other packages,
that were updated in F9 or F10 and F11, to have a working update path from FX
with updates to FX+1 with updates.
Upgrade paths are a concern yes, however our upgrade path stuff is so
busted anyway when doing upgrades to the next release that... well...
*sigh*. Perhaps this is just a case of too many streams, and trying to
let people do things ahead of time.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090507/d6148abe/attachment.bin
Jerry James
2009-05-07 17:59:38 UTC
Permalink
How is it we have 182 stable updates pending for F11 already? ?How have
these seen any testing by a wider audience? ?Are we really just not
bothering with updates-testing anymore? ?Do we not care about distro
stability?
I know that many of these are newpackages, but many aren't though.
</frustrated>
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
Speaking only for the 1 package I contributed to that 182, this was a
change in the subpackage structure that was needed in a package that
depends on mine. It was a minor change, but I pushed it to -testing
for F-10 and F-11 anyway. I tested it for a week in F-10 and in
Rawhide with no ill effects, so I pushed it to stable for F-10 and
F-11 so that the other packager can go do what he needs to do to his
package.

If this was the wrong way to address the problem, please educate me on
the correct way.
--
Jerry James
http://www.jamezone.org/
Jesse Keating
2009-05-07 18:26:18 UTC
Permalink
Post by Jerry James
Speaking only for the 1 package I contributed to that 182, this was a
change in the subpackage structure that was needed in a package that
depends on mine. It was a minor change, but I pushed it to -testing
for F-10 and F-11 anyway. I tested it for a week in F-10 and in
Rawhide with no ill effects, so I pushed it to stable for F-10 and
F-11 so that the other packager can go do what he needs to do to his
package.
If this was the wrong way to address the problem, please educate me on
the correct way.
For F11 it could have been done as a buildroot override so that the
other packager could build against your change, and then the two
packages could be pushed to testing/stable together as one update
request.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090507/d7ece17a/attachment.bin
Ray Van Dolson
2009-05-07 18:02:19 UTC
Permalink
Post by Jesse Keating
How is it we have 182 stable updates pending for F11 already? How have
these seen any testing by a wider audience? Are we really just not
bothering with updates-testing anymore? Do we not care about distro
stability?
I know that many of these are newpackages, but many aren't though.
</frustrated>
I had tagged one of mine for testing, but it sat there for a couple
weeks and nothing happened.... so I requested stable instead.

Maybe I should have waited longer or re-requested testing.

Ray
Jesse Keating
2009-05-07 18:26:44 UTC
Permalink
Post by Ray Van Dolson
I had tagged one of mine for testing, but it sat there for a couple
weeks and nothing happened.... so I requested stable instead.
Maybe I should have waited longer or re-requested testing.
F11 testing updates aren't going anywhere yet, so there isn't really any
possibility of getting feedback on them yet.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090507/a32b3d5e/attachment.bin
Ray Van Dolson
2009-05-07 19:18:34 UTC
Permalink
Post by Jesse Keating
Post by Ray Van Dolson
I had tagged one of mine for testing, but it sat there for a couple
weeks and nothing happened.... so I requested stable instead.
Maybe I should have waited longer or re-requested testing.
F11 testing updates aren't going anywhere yet, so there isn't really any
possibility of getting feedback on them yet.
I'm happy enough to leave my update waiting in "testing" if that's the
right thing to do (until after the release I assume). Just didn't know.

For some reason I thought f11-updates could be pushed to as this
wouldn't affect what was frozen for 11.

Ray
Kevin Fenzi
2009-05-07 18:11:26 UTC
Permalink
On Thu, 07 May 2009 10:41:37 -0700
Post by Jesse Keating
How is it we have 182 stable updates pending for F11 already? How
have these seen any testing by a wider audience? Are we really just
not bothering with updates-testing anymore? Do we not care about
distro stability?
I know that many of these are newpackages, but many aren't though.
</frustrated>
Speaking for the 15 Xfce updates:

They are an update from 4.6.0 to 4.6.1.
These updates are mostly translation fixes, along with a very few minor
bug fixes.

http://mocha.xfce.org/documentation/changelogs/4.6.1

I have been running them here since the day they came out with no
problems at all. Also upstream there are not much in the way of bug
reports, so I thought they should be ok to move to stable.

I suppose I should have left them in testing for a bit, but also many
people will expect a newly released fedora to have the latest version
available, especially if they are in a locale that got updated.

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090507/6231594c/attachment.bin
Jesse Keating
2009-05-07 18:27:38 UTC
Permalink
Post by Kevin Fenzi
They are an update from 4.6.0 to 4.6.1.
These updates are mostly translation fixes, along with a very few minor
bug fixes.
http://mocha.xfce.org/documentation/changelogs/4.6.1
I have been running them here since the day they came out with no
problems at all. Also upstream there are not much in the way of bug
reports, so I thought they should be ok to move to stable.
I suppose I should have left them in testing for a bit, but also many
people will expect a newly released fedora to have the latest version
available, especially if they are in a locale that got updated.
This seems pretty reasonable. I'd be more comfortable if a few more
people on F11's rawhide tried them, but *shrug*.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090507/0b8b5ef7/attachment.bin
Bruno Wolff III
2009-05-07 19:05:46 UTC
Permalink
On Thu, May 07, 2009 at 11:27:38 -0700,
Post by Jesse Keating
This seems pretty reasonable. I'd be more comfortable if a few more
people on F11's rawhide tried them, but *shrug*.
If there was a repo set up for these I'd be running them. This time around
I felt it was more trouble than it was worth to pull the updates candidates
ahead of time. I pull kernels and graphics related stuff from koji, but
the other stuff I don't care enough to go to the extra effort for.

I still only report problems for things I was actually using or any install
conflicts that showed up. But it would get some more coverage. I don't know
if there is enough people like me to make it worth doing.
Peter Robinson
2009-05-08 07:52:00 UTC
Permalink
Post by Kevin Fenzi
They are an update from 4.6.0 to 4.6.1.
These updates are mostly translation fixes, along with a very few minor
bug fixes.
http://mocha.xfce.org/documentation/changelogs/4.6.1
I have been running them here since the day they came out with no
problems at all. Also upstream there are not much in the way of bug
reports, so I thought they should be ok to move to stable.
I suppose I should have left them in testing for a bit, but also many
people will expect a newly released fedora to have the latest version
available, especially if they are in a locale that got updated.
This seems pretty reasonable. ?I'd be more comfortable if a few more
people on F11's rawhide tried them, but *shrug*.
Surely that would be a reason to get it tagged into F11 final (the new
locale that is) if other than that its only a minor package with
little risk. That way it would be available straight up as well as not
requiring the package to be downloaded twice.

Peter
Tom Lane
2009-05-07 19:15:30 UTC
Permalink
Post by Jesse Keating
How is it we have 182 stable updates pending for F11 already?
What do you expect, when the release freeze policy essentially forbids
any noncritical updates for a month? People don't stop working just
because releng wants to simplify their own lives.

The only reason there aren't 184 is I haven't bothered to try to
push my pending updates for mysql and postgresql ... but they'll
be in the zero-day update queue just like a lot of other things.

regards, tom lane
Jesse Keating
2009-05-07 20:09:52 UTC
Permalink
Post by Tom Lane
What do you expect, when the release freeze policy essentially forbids
any noncritical updates for a month? People don't stop working just
because releng wants to simplify their own lives.
The only reason there aren't 184 is I haven't bothered to try to
push my pending updates for mysql and postgresql ... but they'll
be in the zero-day update queue just like a lot of other things.
Updates are fine, but skipping -testing and going straight to stable is
a bit irksome.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090507/e281d60f/attachment.bin
Richard W.M. Jones
2009-05-07 21:04:59 UTC
Permalink
Post by Tom Lane
Post by Jesse Keating
How is it we have 182 stable updates pending for F11 already?
What do you expect, when the release freeze policy essentially forbids
any noncritical updates for a month? People don't stop working just
because releng wants to simplify their own lives.
+1

Roll on rolling development ...

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/
Jesse Keating
2009-05-07 21:38:24 UTC
Permalink
Post by Richard W.M. Jones
Roll on rolling development ...
You're missing the point. Rolling development is fine, in rawhide.
Rolling development doesn't mean throw every build at a stable release
as an update, before the release is even made!
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090507/87a0c390/attachment.bin
Jonathan Underwood
2009-05-07 21:52:00 UTC
Permalink
Post by Tom Lane
Post by Jesse Keating
How is it we have 182 stable updates pending for F11 already?
What do you expect, when the release freeze policy essentially forbids
any noncritical updates for a month? ?People don't stop working just
because releng wants to simplify their own lives.
The only reason there aren't 184 is I haven't bothered to try to
push my pending updates for mysql and postgresql ... but they'll
be in the zero-day update queue just like a lot of other things.
Related to that, the release freeze essentially prevents bugfix
package updates to previous releases, since pushing an updated package
with a later version number to eg. F-10 will then break the update
path to F-11. Is there a recommended way around this problem I am
missing?

Jonathan.
Jesse Keating
2009-05-07 21:54:47 UTC
Permalink
Post by Jonathan Underwood
Related to that, the release freeze essentially prevents bugfix
package updates to previous releases, since pushing an updated package
with a later version number to eg. F-10 will then break the update
path to F-11. Is there a recommended way around this problem I am
missing?
Frankly I'd ignore it. A week after F11 goes GA the update paths will
all be broken anyway.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090507/80863e76/attachment.bin
Ralf Corsepius
2009-05-08 03:12:28 UTC
Permalink
Post by Jesse Keating
Post by Jonathan Underwood
Related to that, the release freeze essentially prevents bugfix
package updates to previous releases, since pushing an updated package
with a later version number to eg. F-10 will then break the update
path to F-11. Is there a recommended way around this problem I am
missing?
Frankly I'd ignore it.
A week after F11 goes GA the update paths will
all be broken anyway.
1. It already is
2. It doesn't have to be that way

IMO, a significant portion of such issues is caused by rel-eng's freeze
and defects in fedora's work-flow.
Jesse Keating
2009-05-08 03:42:13 UTC
Permalink
Post by Ralf Corsepius
1. It already is
2. It doesn't have to be that way
IMO, a significant portion of such issues is caused by rel-eng's freeze
and defects in fedora's work-flow.
The cut images will always remain stagnant, the rpms not changing. So
long as we allow updates to previous releases to be n-v-r higher than
the GA versions of the next release, we will always have a broken
upgrade path from N-1+updates to N.

Are you suggesting some distro release level super epoch?
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090507/6f3a219a/attachment.bin
Ralf Corsepius
2009-05-08 04:05:40 UTC
Permalink
Post by Jesse Keating
Post by Ralf Corsepius
1. It already is
2. It doesn't have to be that way
IMO, a significant portion of such issues is caused by rel-eng's freeze
and defects in fedora's work-flow.
The cut images will always remain stagnant, the rpms not changing. So
long as we allow updates to previous releases to be n-v-r higher than
the GA versions of the next release, we will always have a broken
upgrade path from N-1+updates to N.
Are you suggesting some distro release level super epoch?
I am suggesting that you implement rawhide/testing, f11/testing and
f11/updates right now and get rid of "trac" (replace buildroot overrides
with button in koji or treat "push to stable" as "buildroot overrides").


This would resolve several issues packagers have been facing (and now
hit you) at once.

In particular would it help
* to prevent packages from queuing up on the packager's side, which
would have been released very soon/immediately after GA in any case.

* to prevent NEVR issues resulting from F-9, F-10 and F-12 being open,
while F-11 is frozen.

* rawhide/testing would also help wrt. test rawhide for
experimental/unsafe stuff, which would help improving stability when
rel-eng brands a rawhide snapshot "Fedora release".


There would be one major difference: rel-eng, would have to herry-pick
and move around packages between F11 GA and F11/updates before the release.


Ralf
Jesse Keating
2009-05-08 04:19:35 UTC
Permalink
Post by Ralf Corsepius
I am suggesting that you implement rawhide/testing, f11/testing and
f11/updates right now and get rid of "trac" (replace buildroot overrides
with button in koji or treat "push to stable" as "buildroot overrides").
I eventually do want to have the ability for maintainers to self service
buildroot overrides. We just don't have the code in place, nor enough
people to work on the code while we work on other things too.

Although while we're trying to finish up a release, I would ask where we
should publish the next rawhide, or what you mean by rawhide/testing.
Post by Ralf Corsepius
This would resolve several issues packagers have been facing (and now
hit you) at once.
In particular would it help
* to prevent packages from queuing up on the packager's side, which
would have been released very soon/immediately after GA in any case.
We're going to be pushing an initial set of F11 updates in the next day
or so.
Post by Ralf Corsepius
* to prevent NEVR issues resulting from F-9, F-10 and F-12 being open,
while F-11 is frozen.
Won't help at all, as the F11 release repo doesn't change, nor do the
contents of the DVD, so F9/10 will always move ahead of the release.
Post by Ralf Corsepius
* rawhide/testing would also help wrt. test rawhide for
experimental/unsafe stuff, which would help improving stability when
rel-eng brands a rawhide snapshot "Fedora release".
So you want a rawhide, and a rawerhide?
Post by Ralf Corsepius
There would be one major difference: rel-eng, would have to herry-pick
and move around packages between F11 GA and F11/updates before the release.
We already do that based on maintainers and testers who propose and test
packages during freezes.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090507/03747b08/attachment.bin
Ralf Corsepius
2009-05-08 04:56:04 UTC
Permalink
Post by Jesse Keating
Post by Ralf Corsepius
I am suggesting that you implement rawhide/testing, f11/testing and
f11/updates right now and get rid of "trac" (replace buildroot overrides
with button in koji or treat "push to stable" as "buildroot overrides").
I eventually do want to have the ability for maintainers to self service
buildroot overrides. We just don't have the code in place, nor enough
people to work on the code while we work on other things too.
Although while we're trying to finish up a release, I would ask where we
should publish the next rawhide, or what you mean by rawhide/testing.
Post by Ralf Corsepius
This would resolve several issues packagers have been facing (and now
hit you) at once.
In particular would it help
* to prevent packages from queuing up on the packager's side, which
would have been released very soon/immediately after GA in any case.
We're going to be pushing an initial set of F11 updates in the next day
or so.
Why has this not be done earlier?

I am already facing a pretty nice package queue jam on my part because
F11 is frozen and hasn't received any update for some time. None of
these updates are critical nevertheless they contain bug fixes and are
prerequisites for future development.
Post by Jesse Keating
Post by Ralf Corsepius
* to prevent NEVR issues resulting from F-9, F-10 and F-12 being open,
while F-11 is frozen.
Won't help at all, as the F11 release repo doesn't change, nor do the
contents of the DVD, so F9/10 will always move ahead of the release.
You are missing the point: F11 updates would be open NOW!

F11 GA development would be decoupled from F11 updates!

rel-eng would cherry-pick the packages they want to put on CD/DVD, while
F11 updates would move on and would already carry what otherwise would
hit GA after "release".
Post by Jesse Keating
Post by Ralf Corsepius
* rawhide/testing would also help wrt. test rawhide for
experimental/unsafe stuff, which would help improving stability when
rel-eng brands a rawhide snapshot "Fedora release".
So you want a rawhide, and a rawerhide?
Neither, all I am saying is that your work flow _is not designed to help
stability_, but encourages prematurely shipping broken/untested "crap
stuff".

This consideration shows, when packages are being added to rawhide or
undergo substanticial changes, right before your freeze.
You end up with untested/likely broken packages in your release and
with Fedora releases which are not much more than "rawhide snapshots",
and CD/DVDs which aren't worth using.
Post by Jesse Keating
Post by Ralf Corsepius
There would be one major difference: rel-eng, would have to herry-pick
and move around packages between F11 GA and F11/updates before the release.
We already do that based on maintainers and testers who propose and test
packages during freezes.
As having been said many times before: You can't and will never be able
to so - You are cheating to yourselves, all you can do is to test for
very few, very isolated issues, on packages you are familiar with.

Ralf
Jesse Keating
2009-05-08 15:12:43 UTC
Permalink
Post by Ralf Corsepius
Post by Jesse Keating
We're going to be pushing an initial set of F11 updates in the next day
or so.
Why has this not be done earlier?
Partly due to attention spent elsewhere, and partly because we'd rather
our tester base focused on the bits we're proposing for the release,
rather than the bits we're proposing to replace the release.
Post by Ralf Corsepius
I am already facing a pretty nice package queue jam on my part because
F11 is frozen and hasn't received any update for some time. None of
these updates are critical nevertheless they contain bug fixes and are
prerequisites for future development.
Post by Jesse Keating
Post by Ralf Corsepius
* to prevent NEVR issues resulting from F-9, F-10 and F-12 being open,
while F-11 is frozen.
Won't help at all, as the F11 release repo doesn't change, nor do the
contents of the DVD, so F9/10 will always move ahead of the release.
You are missing the point: F11 updates would be open NOW!
Which doesn't help the DVD at all.
Post by Ralf Corsepius
F11 GA development would be decoupled from F11 updates!
Which doesn't help the situation where F10 updates will quickly grow NVR
higher than the F11 release.
Post by Ralf Corsepius
rel-eng would cherry-pick the packages they want to put on CD/DVD, while
F11 updates would move on and would already carry what otherwise would
hit GA after "release".
releng is a terrible place to "cherry pick". We can't watch each and
every build and decide what is good and what is bad to have in the
release. We have to rely on the informed maintainer proposing a package
break the freeze and be brought into the release.
Post by Ralf Corsepius
Post by Jesse Keating
Post by Ralf Corsepius
* rawhide/testing would also help wrt. test rawhide for
experimental/unsafe stuff, which would help improving stability when
rel-eng brands a rawhide snapshot "Fedora release".
So you want a rawhide, and a rawerhide?
Neither, all I am saying is that your work flow _is not designed to help
stability_, but encourages prematurely shipping broken/untested "crap
stuff".
That's only if maintainers don't actually take the schedule and
development effort into consideration, completely ignoring the cycle and
only having "crap" packages in rawhide at the time of the freeze. If
they actually used good development practices, the packages in rawhide
at the time of the freeze would not be "crap", they would be the
packages they want in the release, and any changes would be to fix
unexpected bugs in those packages.
Post by Ralf Corsepius
This consideration shows, when packages are being added to rawhide or
undergo substanticial changes, right before your freeze.
And how is this releng fault, when the maintainers are just plain not
following good development practices?
Post by Ralf Corsepius
You end up with untested/likely broken packages in your release and
with Fedora releases which are not much more than "rawhide snapshots",
and CD/DVDs which aren't worth using.
Untested... that's why we compose rawhide from the frozen bits, rawhide
that is used by large numbers of people who are testing the software in
their every day use... That's why we find and fix numerous bugs that
improve the release. That's why good maintainers slow down their
changes prior to the freeze to lessen the risk and to increase the
chance that the release has good quality packages.
Post by Ralf Corsepius
Post by Jesse Keating
Post by Ralf Corsepius
There would be one major difference: rel-eng, would have to herry-pick
and move around packages between F11 GA and F11/updates before the release.
We already do that based on maintainers and testers who propose and test
packages during freezes.
As having been said many times before: You can't and will never be able
to so - You are cheating to yourselves, all you can do is to test for
very few, very isolated issues, on packages you are familiar with.
Perhaps you're just not willing to use good development practices, and
are trying to find a reason to blame our development cycle when this
doesn't work out for you. I can't help but not agree with you.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090508/04884f37/attachment.bin
Richard W.M. Jones
2009-05-08 15:45:39 UTC
Permalink
Post by Jesse Keating
That's only if maintainers don't actually take the schedule and
development effort into consideration, completely ignoring the cycle and
only having "crap" packages in rawhide at the time of the freeze. If
they actually used good development practices, the packages in rawhide
at the time of the freeze would not be "crap", they would be the
packages they want in the release, and any changes would be to fix
unexpected bugs in those packages.
Yes, for gcc, the kernel, glibc and other major components I'd agree.

For new packages, it's surely better to have a new crap package than
no package at all. After all, a new crap package *might* work for
someone, but a missing package definitely won't.

For packages that not many people use, and the sort of packages I'm
doing (which are for developers who really should know what's what), a
6-month cycle of organized around delivery of a circular piece of
plastic is fairly irrelevant.

Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
Jesse Keating
2009-05-08 15:59:17 UTC
Permalink
Post by Richard W.M. Jones
Yes, for gcc, the kernel, glibc and other major components I'd agree.
For new packages, it's surely better to have a new crap package than
no package at all. After all, a new crap package *might* work for
someone, but a missing package definitely won't.
For packages that not many people use, and the sort of packages I'm
doing (which are for developers who really should know what's what), a
6-month cycle of organized around delivery of a circular piece of
plastic is fairly irrelevant.
I agree to an extent. However no matter how fringe the package, an
improper requires or inadvertent provides can wreak havoc. I'd rather
not see those go directly into the pending release.

If these packages really don't care about the release, then perhaps the
answer is to somehow figure out a way to have two rawhide streams. The
rawhide of the pending release, and the rawhide of next, just like we do
with CVS branches. That way your work can continue on the next rawhide,
just ignoring the release all together.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090508/f50b4c05/attachment.bin
Richard W.M. Jones
2009-05-08 17:29:42 UTC
Permalink
Post by Jesse Keating
Post by Richard W.M. Jones
Yes, for gcc, the kernel, glibc and other major components I'd agree.
For new packages, it's surely better to have a new crap package than
no package at all. After all, a new crap package *might* work for
someone, but a missing package definitely won't.
For packages that not many people use, and the sort of packages I'm
doing (which are for developers who really should know what's what), a
6-month cycle of organized around delivery of a circular piece of
plastic is fairly irrelevant.
I agree to an extent. However no matter how fringe the package, an
improper requires or inadvertent provides can wreak havoc. I'd rather
not see those go directly into the pending release.
Yes, this is a problem, a rogue package that has 'Provides: glibc',
but I tend to think this is a problem with RPM or Fedora itself, which
should (somehow!) prevent that.

Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
Jesse Keating
2009-05-08 18:23:56 UTC
Permalink
Post by Richard W.M. Jones
Yes, this is a problem, a rogue package that has 'Provides: glibc',
but I tend to think this is a problem with RPM or Fedora itself, which
should (somehow!) prevent that.
In the future, we could be running post-build tests that would catch
something like this and prevent the build from being tagged without
maintainer forcing it.

However we don't have that right now, so suggestions on how to
accomplish your goal with today's resources?
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090508/d9d5a2d8/attachment.bin
Tim Waugh
2009-05-08 16:14:08 UTC
Permalink
Post by Richard W.M. Jones
For new packages, it's surely better to have a new crap package than
no package at all.
When a package claims to do something but is actually no good at it, it
can cause real frustration to those who just want to use the computer
and not develop for it.

I would much rather the software that goes into a Fedora release be of
release quality, starting from the time the package review is finished,
or not be in it at all.

Is it just me?

Tim.
*/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090508/989667cf/attachment.bin
Ray Van Dolson
2009-05-08 16:46:13 UTC
Permalink
Post by Tim Waugh
Post by Richard W.M. Jones
For new packages, it's surely better to have a new crap package than
no package at all.
When a package claims to do something but is actually no good at it, it
can cause real frustration to those who just want to use the computer
and not develop for it.
I would much rather the software that goes into a Fedora release be of
release quality, starting from the time the package review is finished,
or not be in it at all.
Is it just me?
I think there should be enough trust in the packagers to make the
decision as to whether or not a "new" package is ready or not for
consumption.

Ray
Rahul Sundaram
2009-05-08 16:52:04 UTC
Permalink
Post by Tim Waugh
Post by Richard W.M. Jones
For new packages, it's surely better to have a new crap package than
no package at all.
When a package claims to do something but is actually no good at it, it
can cause real frustration to those who just want to use the computer
and not develop for it.
I would much rather the software that goes into a Fedora release be of
release quality, starting from the time the package review is finished,
or not be in it at all.
Is it just me?
Not just you.

Rahul
Jesse Keating
2009-05-08 16:47:20 UTC
Permalink
Post by Tim Waugh
Is it just me?
No, it's not just you. However I think many will disagree on the
definition of "release quality".
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090508/007ac1f0/attachment.bin
Till Maas
2009-05-08 17:12:21 UTC
Permalink
Post by Tim Waugh
Post by Richard W.M. Jones
For new packages, it's surely better to have a new crap package than
no package at all.
When a package claims to do something but is actually no good at it, it
can cause real frustration to those who just want to use the computer
and not develop for it.
I would much rather the software that goes into a Fedora release be of
release quality, starting from the time the package review is finished,
or not be in it at all.
Is it just me?
If some software has a unique feature that I need to use right now, then it is
always more frustating to have to create a rpm by myself than to just install
it with yum from Fedora. But in general it is always nicer to already have a
package, than to have to create on by myself, especially if I find the
software not useful enough after I tried it.

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090508/2bdd97ec/attachment.bin
Ralf Corsepius
2009-05-09 00:50:24 UTC
Permalink
Post by Jesse Keating
Post by Ralf Corsepius
Post by Jesse Keating
We're going to be pushing an initial set of F11 updates in the next day
or so.
Why has this not be done earlier?
Partly due to attention spent elsewhere, and partly because we'd rather
our tester base focused on the bits we're proposing for the release,
rather than the bits we're proposing to replace the release.
Post by Ralf Corsepius
I am already facing a pretty nice package queue jam on my part because
F11 is frozen and hasn't received any update for some time. None of
these updates are critical nevertheless they contain bug fixes and are
prerequisites for future development.
Post by Jesse Keating
Post by Ralf Corsepius
* to prevent NEVR issues resulting from F-9, F-10 and F-12 being open,
while F-11 is frozen.
Won't help at all, as the F11 release repo doesn't change, nor do the
contents of the DVD, so F9/10 will always move ahead of the release.
You are missing the point: F11 updates would be open NOW!
Which doesn't help the DVD at all.
Pardon, but composing the DVD is solely YOUR problem, YOU need to find a
solution for.
Post by Jesse Keating
Post by Ralf Corsepius
F11 GA development would be decoupled from F11 updates!
Which doesn't help the situation where F10 updates will quickly grow NVR
higher than the F11 release.
Post by Ralf Corsepius
rel-eng would cherry-pick the packages they want to put on CD/DVD, while
F11 updates would move on and would already carry what otherwise would
hit GA after "release".
releng is a terrible place to "cherry pick". We can't watch each and
every build and decide what is good and what is bad to have in the
release. We have to rely on the informed maintainer proposing a package
break the freeze and be brought into the release.
... the informed "maintainers" did "submit packages through koji/bodhi" ...
Post by Jesse Keating
Post by Ralf Corsepius
Post by Jesse Keating
Post by Ralf Corsepius
* rawhide/testing would also help wrt. test rawhide for
experimental/unsafe stuff, which would help improving stability when
rel-eng brands a rawhide snapshot "Fedora release".
So you want a rawhide, and a rawerhide?
Neither, all I am saying is that your work flow _is not designed to help
stability_, but encourages prematurely shipping broken/untested "crap
stuff".
That's only if maintainers don't actually take the schedule and
development effort into consideration, completely ignoring the cycle and
only having "crap" packages in rawhide at the time of the freeze. If
they actually used good development practices, the packages in rawhide
at the time of the freeze would not be "crap", they would be the
packages they want in the release, and any changes would be to fix
unexpected bugs in those packages.
Post by Ralf Corsepius
This consideration shows, when packages are being added to rawhide or
undergo substanticial changes, right before your freeze.
And how is this releng fault, when the maintainers are just plain not
following good development practices?
Quite simple: Your schedules and practices are widely irrelevant to
contributors.

It's you who needs to synchronize your job with what contributors,
upstreams and the rest of the worlds provides to you. It's naive of you
to expect the rest of the world to synchronize with you!
Post by Jesse Keating
Post by Ralf Corsepius
You end up with untested/likely broken packages in your release and
with Fedora releases which are not much more than "rawhide snapshots",
and CD/DVDs which aren't worth using.
Untested... that's why we compose rawhide from the frozen bits, rawhide
that is used by large numbers of people who are testing the software in
their every day use... That's why we find and fix numerous bugs that
improve the release. That's why good maintainers slow down their
changes prior to the freeze to lessen the risk and to increase the
chance that the release has good quality packages.
Well, F11-Preview spoke a different language.

Even elementary key features were/are simply plain "unusable" and didn't
even survive basic test.

Examples: anaconda, preupgrade, dbus, ...
Post by Jesse Keating
Post by Ralf Corsepius
Post by Jesse Keating
Post by Ralf Corsepius
There would be one major difference: rel-eng, would have to herry-pick
and move around packages between F11 GA and F11/updates before the release.
We already do that based on maintainers and testers who propose and test
packages during freezes.
As having been said many times before: You can't and will never be able
to so - You are cheating to yourselves, all you can do is to test for
very few, very isolated issues, on packages you are familiar with.
Perhaps you're just not willing to use good development practices,
Rubbish - Perhaps your development practices are far from being "good"?
Perhaps you're too close to be able to comprehend this? Perhaps your ego
is in your way to comprehend?
Post by Jesse Keating
and
are trying to find a reason to blame our development cycle when this
doesn't work out for you. I can't help but not agree with you.
No, I want you to understand that there are other demands but yours and
that your are better off taking them into account.

Ralf
Jonathan Underwood
2009-05-08 11:17:17 UTC
Permalink
Post by Ralf Corsepius
1. It already is
2. It doesn't have to be that way
IMO, a significant portion of such issues is caused by rel-eng's freeze
and defects in fedora's work-flow.
The cut images will always remain stagnant, the rpms not changing. ?So
long as we allow updates to previous releases to be n-v-r higher than
the GA versions of the next release, we will always have a broken
upgrade path from N-1+updates to N.
I've always assumed that we're supposed to try and not break the
upgrade path for (N-1+updatesForN-1) to (N+updatesForN). Is that not
the case?
Are you suggesting some distro release level super epoch?
I've often wondered why we don't have such a thing, but I've always
noticed that discussions around these sorts of ideas usually become a
bit of a flame fest.

J.
Jesse Keating
2009-05-08 15:14:40 UTC
Permalink
Post by Jonathan Underwood
I've always assumed that we're supposed to try and not break the
upgrade path for (N-1+updatesForN-1) to (N+updatesForN). Is that not
the case?
It's the only case we can realistically try for.
Post by Jonathan Underwood
Post by Jesse Keating
Are you suggesting some distro release level super epoch?
I've often wondered why we don't have such a thing, but I've always
noticed that discussions around these sorts of ideas usually become a
bit of a flame fest.
Yeah, I haven't put a lot of effort into such a thing myself. It'd be
far easier if we didn't have multiple active releases at any time, or
didn't allow version bumps in N-* releases. Of course, those are even
more "flamey" topics.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090508/3625e8e1/attachment.bin
Rahul Sundaram
2009-05-08 15:34:05 UTC
Permalink
Post by Jesse Keating
Yeah, I haven't put a lot of effort into such a thing myself. It'd be
far easier if we didn't have multiple active releases at any time, or
didn't allow version bumps in N-* releases. Of course, those are even
more "flamey" topics.
If we don't maintain two general releases in parallel, we are cutting
short to a six month release *and* update cycle instead of a release
cycle of six months and update cycle of 13 months, approx. Do you have
an alternative?

Rahul
Jesse Keating
2009-05-08 16:01:29 UTC
Permalink
Post by Rahul Sundaram
If we don't maintain two general releases in parallel, we are cutting
short to a six month release *and* update cycle instead of a release
cycle of six months and update cycle of 13 months, approx. Do you have
an alternative?
Not really, I just said it would be easier. No matter how long our
development or support cycle is, I don't think we'd ever be able to
"shut down" N-1 as soon as N is released. Too many people will want
more time to move from N-1 to N so we'll always have multiple streams
going. Things would be easier if we could enforce that no N-1(+updates)
package is NVR higher than the packages in N, but that involves doing
some unsavory things to package n-v-rs or epochs.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090508/cc6f5f98/attachment.bin
Kevin Kofler
2009-05-09 00:11:19 UTC
Permalink
Post by Jonathan Underwood
Related to that, the release freeze essentially prevents bugfix
package updates to previous releases, since pushing an updated package
with a later version number to eg. F-10 will then break the update
path to F-11. Is there a recommended way around this problem I am
missing?
Well, you can try getting the package tagged if it's really a bugfix.

Where that doesn't make sense, just queue it as a 0-day update for F11, it's
the best you can do.

Kevin Kofler
Ralf Corsepius
2009-05-08 02:30:37 UTC
Permalink
Post by Tom Lane
Post by Jesse Keating
How is it we have 182 stable updates pending for F11 already?
What do you expect, when the release freeze policy essentially forbids
any noncritical updates for a month? People don't stop working just
because releng wants to simplify their own lives.
The only reason there aren't 184 is I haven't bothered to try to
push my pending updates for mysql and postgresql ... but they'll
be in the zero-day update queue just like a lot of other things.
Exactly, ... Keating's complaint is just a side-effect of the Fedora
bureaucracy and the freezes.

Unlike before, when the nasty side-effects of the freezes solely hit the
packagers they now are hitting him ...

One work-around seems obivous to me: Launch updates/f11 and testing/f11
repos now.

Ralf
Michal Hlavinka
2009-05-08 08:59:19 UTC
Permalink
Post by Tom Lane
Post by Jesse Keating
How is it we have 182 stable updates pending for F11 already?
What do you expect, when the release freeze policy essentially forbids
any noncritical updates for a month? People don't stop working just
because releng wants to simplify their own lives.
The only reason there aren't 184 is I haven't bothered to try to
push my pending updates for mysql and postgresql ... but they'll
be in the zero-day update queue just like a lot of other things.
regards, tom lane
I really agree with this. I think we need F11/updates and F11/updates-testing
soon after devel freeze. You get bugs reported for snapshots, previews,... but
fixing these bugs and especially delivering them to users is too much difficult
imho.

In my dreamworld we have rawhide -> F11, F11/updates, F11/updates-testing in a
few days after devel freeze. I think at least F11/updates-testing (without
F11/updates available before day or two ago F11 GA) would be really
appreciated by developers.

Regards,
Michal Hlavinka
Michal Hlavinka
2009-05-08 09:19:23 UTC
Permalink
Post by Michal Hlavinka
Post by Tom Lane
Post by Jesse Keating
How is it we have 182 stable updates pending for F11 already?
What do you expect, when the release freeze policy essentially forbids
any noncritical updates for a month? People don't stop working just
because releng wants to simplify their own lives.
The only reason there aren't 184 is I haven't bothered to try to
push my pending updates for mysql and postgresql ... but they'll
be in the zero-day update queue just like a lot of other things.
regards, tom lane
I really agree with this. I think we need F11/updates and
F11/updates-testing soon after devel freeze. You get bugs reported for
snapshots, previews,... but fixing these bugs and especially delivering
them to users is too much difficult imho.
In my dreamworld we have rawhide -> F11, F11/updates, F11/updates-testing
in a few days after devel freeze. I think at least F11/updates-testing
(without F11/updates available before day or two ago F11 GA) would be
really appreciated by developers.
Regards,
Michal Hlavinka
and one real life experience:
I'd like to upgrade to F11 snapshost / preview /... but when I'll found some
bug, it'll be fixed in F10 sooner than in F11. Not only this, but I'll have to
wait *one month* before I get these fixes! (Yes, I can download them from koji,
but I'd like to have fixed also bugs reported by other users/testers.)

/me thinks there is something wrong here...
Jesse Keating
2009-05-08 15:18:58 UTC
Permalink
Post by Michal Hlavinka
I'd like to upgrade to F11 snapshost / preview /... but when I'll found some
bug, it'll be fixed in F10 sooner than in F11. Not only this, but I'll have to
wait *one month* before I get these fixes! (Yes, I can download them from koji,
but I'd like to have fixed also bugs reported by other users/testers.)
/me thinks there is something wrong here...
If you find a bug and it's bad enough, why can't you ask the maintainer
to request a freeze break for the bug fix?
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090508/f138f877/attachment.bin
Michal Hlavinka
2009-05-08 20:48:11 UTC
Permalink
Post by Jesse Keating
Post by Michal Hlavinka
I'd like to upgrade to F11 snapshost / preview /... but when I'll found
some bug, it'll be fixed in F10 sooner than in F11. Not only this, but
I'll have to wait *one month* before I get these fixes! (Yes, I can
download them from koji, but I'd like to have fixed also bugs reported by
other users/testers.)
/me thinks there is something wrong here...
If you find a bug and it's bad enough, why can't you ask the maintainer
to request a freeze break for the bug fix?
yes,but even if you have ten not bad enough bugs in ten packages, it's still
really annoying... and I don't think maintainers are willing to ask releng for
pushing that not bad enough bug fix
Jesse Keating
2009-05-08 20:58:01 UTC
Permalink
Post by Michal Hlavinka
yes,but even if you have ten not bad enough bugs in ten packages, it's still
really annoying... and I don't think maintainers are willing to ask releng for
pushing that not bad enough bug fix
It's easier to get it into a freeze than it is to issue an update to the
release... if they won't go through the effort of a freeze request, why
would they push an update?
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090508/4c952bf3/attachment.bin
Kevin Kofler
2009-05-09 00:23:48 UTC
Permalink
Post by Jesse Keating
It's easier to get it into a freeze than it is to issue an update to the
release...
From a maintainer's perspective, it's actually not, and this is probably one
of the issues with our processes at hand here.

Freeze break: file a ticket with rel-eng, in an interface not explicitly
designed for package updates (which makes it clear you're talking to actual
humans and requires you to actually explain what you want in some form of
sentence), justify the change, explain why it doesn't break anything, wait
for 2 rel-eng members to explicitly approve it, and expect to be questioned
if your justifications are insufficient.

Update: fill it in in Bodhi, no explanation required at all (people file
updates even with blank descriptions and get away with it!), wait for the
next push. Only occasionally you or mschwendt will ask what the point of
the update is, or somebody (often mschwendt) will point out some broken
dependencies, and even in those cases it often ends up getting pushed
anyway. If nobody notices, it gets pushed by default (quite the opposite as
for the freeze breaks).

And no, I don't think requiring the same amount of bureaucracy for updates
as for freeze breaks will scale. (Updates already take too long to go out,
and I also think the workload would be too high for rel-eng.) I do think
blank or uninformative (e.g. "new upstream release") descriptions ought to
be banned though. Most likely a common process with some sort of middle
ground is needed, though I'm not sure how exactly it should look.

Kevin Kofler
Ralf Corsepius
2009-05-09 01:25:33 UTC
Permalink
Post by Jesse Keating
Post by Michal Hlavinka
I'd like to upgrade to F11 snapshost / preview /... but when I'll found some
bug, it'll be fixed in F10 sooner than in F11. Not only this, but I'll have to
wait *one month* before I get these fixes! (Yes, I can download them from koji,
but I'd like to have fixed also bugs reported by other users/testers.)
/me thinks there is something wrong here...
If you find a bug and it's bad enough, why can't you ask the maintainer
to request a freeze break for the bug fix?
That's the wrong question.

From maintainer's view a more accurate question would be: Why do I have
to request a freeze break?
Jesse Keating
2009-05-08 15:17:58 UTC
Permalink
Post by Michal Hlavinka
I really agree with this. I think we need F11/updates and F11/updates-testing
soon after devel freeze. You get bugs reported for snapshots, previews,... but
fixing these bugs and especially delivering them to users is too much difficult
imho.
Erm, it's too hard to do the build, then propose a freeze break to fix
the bug? If the bug is important enough that you're getting reports on
it, why not propose that the final release has the bug fixed?
Post by Michal Hlavinka
In my dreamworld we have rawhide -> F11, F11/updates, F11/updates-testing in a
few days after devel freeze. I think at least F11/updates-testing (without
F11/updates available before day or two ago F11 GA) would be really
appreciated by developers.
I'm not sure what you mean by rawhide -> F11, however you do bring up an
interesting idea. Shortly after the freeze, if we did start releasing
updates-testing, then the things that pass -testing could indeed go to
the release rather than updates. That's not a terrible idea, I'll have
to think some on it and talk with the bodhi developer.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090508/084c83d0/attachment.bin
Ray Van Dolson
2009-05-08 15:31:02 UTC
Permalink
Post by Jesse Keating
Post by Michal Hlavinka
I really agree with this. I think we need F11/updates and F11/updates-testing
soon after devel freeze. You get bugs reported for snapshots, previews,... but
fixing these bugs and especially delivering them to users is too much difficult
imho.
Erm, it's too hard to do the build, then propose a freeze break to fix
the bug? If the bug is important enough that you're getting reports on
it, why not propose that the final release has the bug fixed?
Many bugs are not worth breaking the freeze for, but nor should the
freeze bring development to a standstill. If upstream releases a new
package, adds features or what-not (not necessarily fixing some
critical bug) should I delay releasing an update for F10 because I
don't want to conflict with the EVR of the package that was frozen for
F11?

I don't think you guys would be too happy if we all started requesting
exceptions to the freeze for feature enhancements, etc.
Post by Jesse Keating
Post by Michal Hlavinka
In my dreamworld we have rawhide -> F11, F11/updates, F11/updates-testing in a
few days after devel freeze. I think at least F11/updates-testing (without
F11/updates available before day or two ago F11 GA) would be really
appreciated by developers.
I'm not sure what you mean by rawhide -> F11, however you do bring up an
interesting idea. Shortly after the freeze, if we did start releasing
updates-testing, then the things that pass -testing could indeed go to
the release rather than updates. That's not a terrible idea, I'll have
to think some on it and talk with the bodhi developer.
Ray
Rudolf Kastl
2009-05-08 15:53:14 UTC
Permalink
i do not understand how this is sane anyways:

actually why not just draw a baseline and continue to upgrade rawhide.
why does it have to be frozen? the freeze is all about making sure
installation works properly and that is beeing tested with using the
released betas/rcs of the installer.
there is no sane way currently to test the f11 updates and that means
while we keep on freezing and testing an old state we are also pushing
out updates on releaseday that have seen no real testing at all. ->
process problem
in my eyes a sane approach would be to atleast have a seperate
updates-f11-prelease repo that is going to be moved to f11-updates
once the final is released. those that want to coverage check the
blocker bugs can actually do so while others can actually test the
updates in a sane way. is there any problem with that? seems pretty
trivial to me actually.
anyone from rel-eng going to comment on that? why is it done that way
when above issues are rather obvious and present since a whole while

kind regards,
Rudolf Kastl
Jesse Keating
2009-05-08 16:04:07 UTC
Permalink
Post by Ray Van Dolson
Many bugs are not worth breaking the freeze for, but nor should the
freeze bring development to a standstill. If upstream releases a new
package, adds features or what-not (not necessarily fixing some
critical bug) should I delay releasing an update for F10 because I
don't want to conflict with the EVR of the package that was frozen for
F11?
There is no reason to delay the F10 update. Trying to avoid NVR
breakage is a lost cause, it'll be broken between F10 updates and F11 GA
almost immediately. So push the F10 updates.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090508/0a7450ab/attachment.bin
Ralf Corsepius
2009-05-09 01:00:10 UTC
Permalink
Post by Jesse Keating
Post by Ray Van Dolson
Many bugs are not worth breaking the freeze for, but nor should the
freeze bring development to a standstill. If upstream releases a new
package, adds features or what-not (not necessarily fixing some
critical bug) should I delay releasing an update for F10 because I
don't want to conflict with the EVR of the package that was frozen for
F11?
There is no reason to delay the F10 update. Trying to avoid NVR
breakage is a lost cause, it'll be broken between F10 updates and F11 GA
almost immediately.
They are only broken, because your practices force them to be broken.

This is a defect of your approach to preparing Fedora releases.
Adam Williamson
2009-05-09 01:13:41 UTC
Permalink
Post by Ralf Corsepius
Post by Jesse Keating
There is no reason to delay the F10 update. Trying to avoid NVR
breakage is a lost cause, it'll be broken between F10 updates and F11 GA
almost immediately.
They are only broken, because your practices force them to be broken.
This is a defect of your approach to preparing Fedora releases.
Please explain how Jesse could possibly build the release discs such
that it would ever work to upgrade from F10+updates to F11 GA. This has
nothing to do with the release prep process, but how we version update
packages (we version them in such a way that an update shipped for
Fedora N-1 can often become versioned higher than the version of that
package in Fedora N release repos, and that's not a problem you can ever
'fix' in the ISO generation process).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
Ralf Corsepius
2009-05-09 01:32:32 UTC
Permalink
Post by Adam Williamson
Post by Ralf Corsepius
Post by Jesse Keating
There is no reason to delay the F10 update. Trying to avoid NVR
breakage is a lost cause, it'll be broken between F10 updates and F11 GA
almost immediately.
They are only broken, because your practices force them to be broken.
This is a defect of your approach to preparing Fedora releases.
Please explain how Jesse could possibly build the release discs such
that it would ever work to upgrade from F10+updates to F11 GA.
I did so on many occastion (last time previous mails within this thread)
Post by Adam Williamson
This has
nothing to do with the release prep process, but how we version update
packages (we version them in such a way that an update shipped for
Fedora N-1 can often become versioned higher than the version of that
package in Fedora N release repos, and that's not a problem you can ever
'fix' in the ISO generation process).
The trick would be to decouple "DVD-preparations" from "F11-release".

One way to achieve this would be rel-eng to start with a copy/snapshot
of rawhide, but to let F11-release "roll on", e.g. by spawning
"F11-updates".

When encountering issues with their set of packages, they would have to
try fixing their issues by adding packages from "updates" to their set
of packages.

Ralf

Michal Hlavinka
2009-05-08 20:58:30 UTC
Permalink
Post by Jesse Keating
Post by Michal Hlavinka
I really agree with this. I think we need F11/updates and
F11/updates-testing soon after devel freeze. You get bugs reported for
snapshots, previews,... but fixing these bugs and especially delivering
them to users is too much difficult imho.
Erm, it's too hard to do the build, then propose a freeze break to fix
the bug? If the bug is important enough that you're getting reports on
it, why not propose that the final release has the bug fixed?
Yes, but it doesn't have to be just one really important bug. What is more
important? One bad bug in one package or twenty small bugs in twenty packages?
If I want to try rawhide, sometimes I have no other way than just upgrade my
system. For one bug I can use alternative app or apply update from koji, but I
don't want to do this for twenty or more packages.
Post by Jesse Keating
Post by Michal Hlavinka
In my dreamworld we have rawhide -> F11, F11/updates, F11/updates-testing
in a few days after devel freeze. I think at least F11/updates-testing
(without F11/updates available before day or two ago F11 GA) would be
really appreciated by developers.
I'm not sure what you mean by rawhide -> F11, however you do bring up an
interesting idea. Shortly after the freeze, if we did start releasing
updates-testing, then the things that pass -testing could indeed go to
the release rather than updates. That's not a terrible idea, I'll have
to think some on it and talk with the bodhi developer.
rawhide -> F11 = just create branch in the cvs (development for next rawhide
can continue, developers are not affected by freeze). This already happens, but
it could be sooner.

and with F11/updates-testing users will still be able to test the release, but
they'd be able to receive some updates.
Denis Leroy
2009-05-07 19:34:37 UTC
Permalink
Post by Jesse Keating
How is it we have 182 stable updates pending for F11 already? How have
these seen any testing by a wider audience? Are we really just not
bothering with updates-testing anymore? Do we not care about distro
stability?
I know that many of these are newpackages, but many aren't though.
</frustrated>
The automated testing->stable bodhi upgrades should really be disabled
during release freeze.

Can we move all 182 pending updates back to testing until F-11 is released ?
David Cantrell
2009-05-07 19:48:07 UTC
Permalink
Post by Jesse Keating
How is it we have 182 stable updates pending for F11 already? How have
these seen any testing by a wider audience? Are we really just not
bothering with updates-testing anymore? Do we not care about distro
stability?
I know that many of these are newpackages, but many aren't though.
</frustrated>
I do care about Fedora stability, but it's hard to force users to report
bugs and help you test out fixes within the Fedora development schedule.

I wish we had slightly longer release cycles, but that could just be me.

And I'm no koji expert, but:

$ koji list-pkgs --tag=f11-final --quiet | wc -l
7622

So, 2.39% of our packages have pending F-11 updates?
--
David Cantrell <dcantrell at redhat.com>
Red Hat / Honolulu, HI
Michael DeHaan
2009-05-07 19:50:23 UTC
Permalink
Post by Jesse Keating
How is it we have 182 stable updates pending for F11 already? How have
these seen any testing by a wider audience? Are we really just not
bothering with updates-testing anymore? Do we not care about distro
stability?
I know that many of these are newpackages, but many aren't though.
</frustrated>
My experience is that most commercial users do not bother with logging
into Bhodi or even know it exists.

Another problem is that EPEL doesn't /yet/ use bhodi, so it has a
different workflow -- meaning EPEL-testing doesn't really test anything,
it means "rolls every 30-40 days", and that's about it.
So testing has to happen manually, Fedora is the minority use case.

Having a way to vote/comment without FAS would probably be enormously
helpful in getting more users to use the system, once EPEL uses the same
system.

--Michael
David Cantrell
2009-05-07 19:50:47 UTC
Permalink
Post by Michael DeHaan
How is it we have 182 stable updates pending for F11 already? How have
these seen any testing by a wider audience? Are we really just not
bothering with updates-testing anymore? Do we not care about distro
stability?
I know that many of these are newpackages, but many aren't though.
</frustrated>
My experience is that most commercial users do not bother with logging
into Bhodi or even know it exists.
Another problem is that EPEL doesn't /yet/ use bhodi, so it has a
different workflow -- meaning EPEL-testing doesn't really test anything,
it means "rolls every 30-40 days", and that's about it.
So testing has to happen manually, Fedora is the minority use case.
Having a way to vote/comment without FAS would probably be enormously
helpful in getting more users to use the system, once EPEL uses the same
system.
Definitely. Whenever I ask users to test an update and then comment in
bodhi, the latter never happens. They test the update and 2 weeks later
I get a nag mail from bodhi about updates still sitting around. I move
them to stable since I at least had the original reporter test it and
verify it worked.
--
David Cantrell <dcantrell at redhat.com>
Red Hat / Honolulu, HI
Seth Vidal
2009-05-07 19:53:15 UTC
Permalink
Post by David Cantrell
Post by Michael DeHaan
How is it we have 182 stable updates pending for F11 already? How have
these seen any testing by a wider audience? Are we really just not
bothering with updates-testing anymore? Do we not care about distro
stability?
I know that many of these are newpackages, but many aren't though.
</frustrated>
My experience is that most commercial users do not bother with logging
into Bhodi or even know it exists.
Another problem is that EPEL doesn't /yet/ use bhodi, so it has a
different workflow -- meaning EPEL-testing doesn't really test anything,
it means "rolls every 30-40 days", and that's about it.
So testing has to happen manually, Fedora is the minority use case.
Having a way to vote/comment without FAS would probably be enormously
helpful in getting more users to use the system, once EPEL uses the same
system.
Definitely. Whenever I ask users to test an update and then comment in
bodhi, the latter never happens. They test the update and 2 weeks later I
get a nag mail from bodhi about updates still sitting around. I move them to
stable since I at least had the original reporter test it and verify it
worked.
I frequently have the same experience.

-sv
Jesse Keating
2009-05-07 20:11:01 UTC
Permalink
Post by Seth Vidal
Post by David Cantrell
Definitely. Whenever I ask users to test an update and then comment in
bodhi, the latter never happens. They test the update and 2 weeks later I
get a nag mail from bodhi about updates still sitting around. I move them to
stable since I at least had the original reporter test it and verify it
worked.
I frequently have the same experience.
I don't see anything wrong with this, as you're getting somebody to test
it before you move it. The thing that bothered me was how many packages
were going straight into updates without passing -testing.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090507/b0ff571a/attachment.bin
Adam Miller
2009-05-07 20:14:24 UTC
Permalink
In respect to the xfce packages, Kevin put up a repo real quick
earlier upon my request so that I may test and everything looks quite
good and I think the packages are deserving of a +1 if they were in
testing, hopefully that helps a little with your level of "irk" :)

-Adam
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
Tom Lane
2009-05-07 20:21:57 UTC
Permalink
Post by Jesse Keating
I don't see anything wrong with this, as you're getting somebody to test
it before you move it. The thing that bothered me was how many packages
were going straight into updates without passing -testing.
Well, as you just pointed out yourself, F11 testing is nonfunctional as
yet. But the bigger problem is that putting stuff into -testing seldom
accomplishes anything, at least for my packages. I think I might
possibly have gotten one bodhi comment across all the times I let stuff
sit in -testing until nagged; I have certainly *never* seen anything
pushed by the karma mechanism. If maintainers decide it's a waste of
time, there is not a lot you can say against them.

regards, tom lane
Jeff Spaleta
2009-05-07 20:32:00 UTC
Permalink
Post by Tom Lane
Well, as you just pointed out yourself, F11 testing is nonfunctional as
yet. ?But the bigger problem is that putting stuff into -testing seldom
accomplishes anything, at least for my packages. ?I think I might
possibly have gotten one bodhi comment across all the times I let stuff
sit in -testing until nagged; I have certainly *never* seen anything
pushed by the karma mechanism. ?If maintainers decide it's a waste of
time, there is not a lot you can say against them.
I eat testing religiously. I eat so much testing in fact, that I
can't easily sort through all the associated bug reports that I could
be testing for all the packages that I don't commonly "actively" use.
To know what is currently from testing on my system I have to run my
own yum/repoqueries with testing disabled looking for packages not
from regular updates. That's a real pain..and it still doesn't help me
figure out what I should be testing and reporting back on
specifically. So basically I end up reporting regressions if
anything.

What I need to be more helpful is a way for my system to inform me of
the current testing packages I have installed...and the specific
things I should be testing with regard to them. I todo list of sorts.

-jef
Till Maas
2009-05-07 20:47:09 UTC
Permalink
Post by Jeff Spaleta
be testing for all the packages that I don't commonly "actively" use.
To know what is currently from testing on my system I have to run my
own yum/repoqueries with testing disabled looking for packages not
from regular updates. That's a real pain..and it still doesn't help me
If your Fedora certificates are in place for the current unix user, you can
use bodhi to get a list of testable packages afaik:

bodhi --testable

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090507/68b01f53/attachment.bin
&quot;Jóhann B. Guðmundsson&quot;
2009-05-07 21:00:16 UTC
Permalink
Post by Jeff Spaleta
Post by Tom Lane
Well, as you just pointed out yourself, F11 testing is nonfunctional as
yet. But the bigger problem is that putting stuff into -testing seldom
accomplishes anything, at least for my packages. I think I might
possibly have gotten one bodhi comment across all the times I let stuff
sit in -testing until nagged; I have certainly *never* seen anything
pushed by the karma mechanism. If maintainers decide it's a waste of
time, there is not a lot you can say against them.
I eat testing religiously. I eat so much testing in fact, that I
can't easily sort through all the associated bug reports that I could
be testing for all the packages that I don't commonly "actively" use.
To know what is currently from testing on my system I have to run my
own yum/repoqueries with testing disabled looking for packages not
from regular updates. That's a real pain..and it still doesn't help me
figure out what I should be testing and reporting back on
specifically. So basically I end up reporting regressions if
anything.
What I need to be more helpful is a way for my system to inform me of
the current testing packages I have installed...and the specific
things I should be testing with regard to them. I todo list of sorts.
Agreed But...

Given the experience from maintainers that give change log entries like
"Update to" "Upstream release" etc.. which leave's testers with ?

I'm not seeing those maintainers being able to fill in what to
specifically check or test
( Good change log entries usually gives us a good hint what to look for
or test )

JBG
--
Viking-Ice

One of my gods has a hammer your's was nailed to a cross
You do the math!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20090507/595ab01b/attachment.html
Jeff Spaleta
2009-05-07 21:30:04 UTC
Permalink
Post by &quot;Jóhann B. Guðmundsson&quot;
Agreed But...
Given the experience from maintainers that give change log entries like
"Update to" "Upstream release" etc.. which leave's testers with? ?
I'm not seeing those maintainers being able to fill in what to specifically
check or test
( Good change log entries usually gives us a good hint what to look for or
test )
zeroth order.. i just need an easy way to know what is and what is not
currently installed that is from testing and thus could use some love.

first order..i need a todo list tool that is going to nag me about
testing stuff that has been installed for a few days. Something that
is going to sit in my desktop panel and nag the hell out of me to drop
a comment in the update system. Like show my five salient annoucement
texts for testing crap I have installed and challenge me to write a
comment out of that group of 5..every day..

second order...world peace.

-jef
&quot;Jóhann B. Guðmundsson&quot;
2009-05-07 22:07:11 UTC
Permalink
Post by Jeff Spaleta
Post by &quot;Jóhann B. Guðmundsson&quot;
Agreed But...
Given the experience from maintainers that give change log entries like
"Update to" "Upstream release" etc.. which leave's testers with ?
I'm not seeing those maintainers being able to fill in what to specifically
check or test
( Good change log entries usually gives us a good hint what to look for or
test )
zeroth order.. i just need an easy way to know what is and what is not
currently installed that is from testing and thus could use some love.
first order..i need a todo list tool that is going to nag me about
testing stuff that has been installed for a few days. Something that
is going to sit in my desktop panel and nag the hell out of me to drop
a comment in the update system. Like show my five salient annoucement
texts for testing crap I have installed and challenge me to write a
comment out of that group of 5..every day..
Hum so for all the 1100+ packages that come with the default ( dvd )
install
hum mentioning the dvd is not really far so I shall just mention the 182
updates waiting!

You want a notification that nags you all day long..

Something like

"You just installed 182 updates and have yet not provided feed back for
any of them!"

End user provides 1 feed back for one component )

Receives a colorful rainbow "Thank you"

5 minutes later..

"You just installed 182 updates and have provided a feed back for 1 of
them!
This is your friendly reminder that you still have not yet providing
feedback for 181 components "

End user spents the whole day providing feed back, all the time thinking
I must make this notification STOP
Obey the notification, obey the notification is all that he can think of..

Through bloods sweat and tears he manages to go through all the
updates/components and provide feed back
finally the notification stop and he goes to sleep with a piece of mind..

The following morning...

"You got 344 updates pending!"

I say good for you :)

Hey while were at it why don't we let the notification come from a
paper clip or a puppy or a white pony on a rainbow..

For me no thanks! :)

JBG
--
Viking-Ice

One of my gods has a hammer your's was nailed to a cross
You do the math!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20090507/fb5b732c/attachment.html
Jeff Spaleta
2009-05-07 22:23:04 UTC
Permalink
Hum so for all the 1100+ packages that come with the default ( dvd ) install
hum mentioning the dvd is not really far so I shall just mention the 182
updates waiting!
You want a notification that nags you all day long..
you misread... i said give me a list of 5 out of the hundreds and nag
me to drop a comment about one of them. have the 5 differ on each
notification attempt. Once I drop at least one comment..it stops
nagging me for the day. At no point did i say his is something
everyone would want. But I know my work patterns and I know I need
help taking the pile of testing updates and turning them into
bite-sized chunks of information. Really its not that much different
than twitter alerts from people interrupting my UI...except instead of
messages from people i know..its messages about packages I've
installed.

-jef
Nathanael D. Noblet
2009-05-07 22:33:49 UTC
Permalink
Post by Jeff Spaleta
Hum so for all the 1100+ packages that come with the default ( dvd ) install
hum mentioning the dvd is not really far so I shall just mention the 182
updates waiting!
You want a notification that nags you all day long..
you misread... i said give me a list of 5 out of the hundreds and nag
me to drop a comment about one of them. have the 5 differ on each
notification attempt. Once I drop at least one comment..it stops
nagging me for the day. At no point did i say his is something
everyone would want. But I know my work patterns and I know I need
help taking the pile of testing updates and turning them into
bite-sized chunks of information. Really its not that much different
than twitter alerts from people interrupting my UI...except instead of
messages from people i know..its messages about packages I've
installed.
Yeah, I agree, I recently enabled -testing so I could get the crazy new
shiny 2.6.29 kernels which I found fixed a bunch of stuff. Also recently
a colleague of mine who has since converted to linux but is by no means
an expert, were discussing ways to contribute back (particularly because
he gets frustrated with regressions in some programs) how to help. I
mentioned, turn on the -testing repo and file bugs... If that was easy
for them (or me) to do, it would be great.

I would most definitely agree that a way to mark the list of packages in
testing I'm interested in watching/filling comments for would be great.
--
Nathanael d. Noblet
T: 403.875.4613
Chris Adams
2009-05-08 00:20:27 UTC
Permalink
Post by Nathanael D. Noblet
I would most definitely agree that a way to mark the list of packages in
testing I'm interested in watching/filling comments for would be great.
I load updates with yum, and I periodically do a run like
"--enablerepo=\*testing check-update". I then cherry-pick things I use
and might notice an issue with. There was a semi-recent xterm update
that broke the bell; I BZed it, Thomas Dickey fixed it, and voila!, no
buggy xterm when the update was released.
--
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
&quot;Jóhann B. Guðmundsson&quot;
2009-05-07 23:20:02 UTC
Permalink
Post by Jeff Spaleta
Hum so for all the 1100+ packages that come with the default ( dvd ) install
hum mentioning the dvd is not really far so I shall just mention the 182
updates waiting!
You want a notification that nags you all day long..
you misread... i said give me a list of 5 out of the hundreds and nag
me to drop a comment about one of them. have the 5 differ on each
notification attempt. Once I drop at least one comment..it stops
nagging me for the day. At no point did i say his is something
everyone would want. But I know my work patterns and I know I need
help taking the pile of testing updates and turning them into
bite-sized chunks of information. Really its not that much different
than twitter alerts from people interrupting my UI...except instead of
messages from people i know..its messages about packages I've
installed.
Ok so let's leave notification rainbow and pony's out of it
and brainstorm a little..

let's say we have an Bodhi client in Gnome ( gtk ) or
Bodhi client ( plasma ) applet in KDE or better yet a Bodhi
plugin in packagekit or kpackagekit that you could just vote
immediately after you receive the updates from updates-testing.

That application would have the thumps up thumps down on the update
along with a comment field and perhaps username and a password field
depending if we want all or just fas user vote.

We cant have maintainer flag an component in updates-testing which would
show up on
application as a component that needs testing.

It goes without saying all maintainers would flag their component hence
you end up with everything flagged
anyway.

So each updated would always ask you for a thumb up, thumb down..

Hum randomly notify just a 5 or 10 components will not work messy
algorithms that need to be come up with
to deal with various issues like updates chain effect ( updates keep
piling up and you would need to keep track of which one had already sent
notification ) etc..

This could perhaps be solved with an ignore/silent or hide button that
would hide component until the user mark it "show"
basically the user selects components which he wants to vote on.

Now this application would need to have the ability to exclude some
package from requiring voting hum but then again
if they need exclusion then the argument can be made that they simply
don't need to be in updates-testing anyway..

We would still be faced with the problem of not knowing what to test and
i'm not foreseeing that improving given some maintainers changelog track
records
Along with nobody likes paperwork...
( this is a bit of nugget on the process already )

Skeptical that this might work sound more like a "Great on paper crap
on field" idea

The biggest obstacle we are facing as I see it is getting the" how and
what to test" to the user.

/me throws the thinking ball into the air..
--
Viking-Ice

One of my gods has a hammer your's was nailed to a cross
You do the math!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20090507/531a969b/attachment.html
Jeff Spaleta
2009-05-07 23:44:42 UTC
Permalink
Post by &quot;Jóhann B. Guðmundsson&quot;
That application would have the thumps up thumps down on the update
along with a comment field and perhaps username and a password field
depending if we want all or just fas user vote.
I dont need a full bodhi client....i just need to be
reminded..sporatically that I have testing stuff installed. I have no
problem using the bodhi web interface to drop a comment...i just need
to to be reminded what I have installed that could use some love..at
some time later than the moment of installation.

Th underlying problems are simply these:

1) the only time i get notified with relevant information about
testing updates is at the time of install. After installation its
harder to know what installed packages need love. Right now I have to
be extremely proactive about review packages and noting what I want to
test..later..after installation..when I have time.

2)Right now the web interface doesn't present updates in a way that is
relevant to my system usage..its just a pile of updates..ordered in
time...but not personalized. I can't make good use of the most recent
test update notifications on the site and dive into testing something
from the list..because it may or may not be relevant to me. Kernels
being the exception that makes the rule. If I could register my
system somehow so that the bodhi webinterface would know to display
the lastest packages relevant to the system I'm connecting from...that
would do wonders. I could pick off one or two items from that
personalized list of latest testing updates and drop some love.

-jef
-jef
Toshio Kuratomi
2009-05-07 20:32:41 UTC
Permalink
Post by Tom Lane
Post by Jesse Keating
I don't see anything wrong with this, as you're getting somebody to test
it before you move it. The thing that bothered me was how many packages
were going straight into updates without passing -testing.
Well, as you just pointed out yourself, F11 testing is nonfunctional as
yet. But the bigger problem is that putting stuff into -testing seldom
accomplishes anything, at least for my packages. I think I might
possibly have gotten one bodhi comment across all the times I let stuff
sit in -testing until nagged; I have certainly *never* seen anything
pushed by the karma mechanism. If maintainers decide it's a waste of
time, there is not a lot you can say against them.
I use updates in -testing. And I use postgresql for development work.
So I'm a consumer of the packages you leave in -testing even though I
don't comment in bodhi.

To me, the real value of the testing repository (or lack of value) is
not whether the update ever gets auto-pushed. It's whether showstopper
bugs get caught while still in the -testing repo before being pushed out
to -stable.

I've had a few of those caught and reported a few myself so I'm seeing
value there.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090507/7afc4ee8/attachment.bin
Tomas Mraz
2009-05-07 20:38:14 UTC
Permalink
Post by Tom Lane
Post by Jesse Keating
I don't see anything wrong with this, as you're getting somebody to test
it before you move it. The thing that bothered me was how many packages
were going straight into updates without passing -testing.
Well, as you just pointed out yourself, F11 testing is nonfunctional as
yet. But the bigger problem is that putting stuff into -testing seldom
Actually I don't see any important reason why not make F11 testing
functional as soon as F11 is frozen in rawhide.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
Ray Van Dolson
2009-05-07 20:43:07 UTC
Permalink
Post by Tomas Mraz
Post by Tom Lane
Post by Jesse Keating
I don't see anything wrong with this, as you're getting somebody to test
it before you move it. The thing that bothered me was how many packages
were going straight into updates without passing -testing.
Well, as you just pointed out yourself, F11 testing is nonfunctional as
yet. But the bigger problem is that putting stuff into -testing seldom
Actually I don't see any important reason why not make F11 testing
functional as soon as F11 is frozen in rawhide.
That would have been the least confusing thing to do (assuming it was a
feasible option to begin with). I *tried* to use -testing, but nothing
happened so I went ahead and pushed to stable because I knew my package
was fine and it'd been a couple weeks.

Ray
&quot;Jóhann B. Guðmundsson&quot;
2009-05-07 20:36:40 UTC
Permalink
Post by Jesse Keating
Post by Seth Vidal
Post by David Cantrell
Definitely. Whenever I ask users to test an update and then comment in
bodhi, the latter never happens. They test the update and 2 weeks later I
get a nag mail from bodhi about updates still sitting around. I move them to
stable since I at least had the original reporter test it and verify it
worked.
I frequently have the same experience.
Reporter depended and goes both way's with regards to reports
maintainers not replying back to reporters and yes that's also depends
on which maintainer it is.

I asked for a reminder for tester to use and vote bodhi in the updates
testing reports but apparently add that simple text to the top of those
report proved to be too difficult or fell for deaf ears..
Post by Jesse Keating
I don't see anything wrong with this, as you're getting somebody to test
it before you move it. The thing that bothered me was how many packages
were going straight into updates without passing -testing.
Push this bits to the rawhide repo ( perhaps setup update-testing repo
earlier in the process ? ) to get more and wider testing of those bits....

We will never get a good enough testing for all these updates if testers
need to hand pick each update from koji.

+ that will only result in testers hand pick components they favor or
depend
on and use alot.

Anyway perhaps it's time to revisit this process see if it can be
improved or
approach differently and if solution is found it tried in next release
cycle ( F12 ).

JBG
--
Viking-Ice

One of my gods has a hammer your's was nailed to a cross
You do the math!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20090507/1a274076/attachment.html
Toshio Kuratomi
2009-05-07 20:47:15 UTC
Permalink
Post by Michael DeHaan
Post by Jesse Keating
How is it we have 182 stable updates pending for F11 already? How have
these seen any testing by a wider audience? Are we really just not
bothering with updates-testing anymore? Do we not care about distro
stability?
I know that many of these are newpackages, but many aren't though.
</frustrated>
My experience is that most commercial users do not bother with logging
into Bhodi or even know it exists.
Another problem is that EPEL doesn't /yet/ use bhodi, so it has a
different workflow -- meaning EPEL-testing doesn't really test anything,
it means "rolls every 30-40 days", and that's about it.
So testing has to happen manually, Fedora is the minority use case.
Having a way to vote/comment without FAS would probably be enormously
helpful in getting more users to use the system, once EPEL uses the same
system.
You haven't needed a FAS account to leave a comment in bodhi for a long
time... possibly from the get-go. Look at a potential update in bodhi
without logging in. There's an add comment link that asks you for an
email address, comment, and a captcha to fill in. (Although I have
found in testing just now that anonymous commenting is currently
broken... have to find out from lmacken what's going on there.)

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090507/8db7fac1/attachment.bin
David Cantrell
2009-05-08 01:39:31 UTC
Permalink
Post by Toshio Kuratomi
Post by Michael DeHaan
Post by Jesse Keating
How is it we have 182 stable updates pending for F11 already? How have
these seen any testing by a wider audience? Are we really just not
bothering with updates-testing anymore? Do we not care about distro
stability?
I know that many of these are newpackages, but many aren't though.
</frustrated>
My experience is that most commercial users do not bother with logging
into Bhodi or even know it exists.
Another problem is that EPEL doesn't /yet/ use bhodi, so it has a
different workflow -- meaning EPEL-testing doesn't really test anything,
it means "rolls every 30-40 days", and that's about it.
So testing has to happen manually, Fedora is the minority use case.
Having a way to vote/comment without FAS would probably be enormously
helpful in getting more users to use the system, once EPEL uses the same
system.
You haven't needed a FAS account to leave a comment in bodhi for a long
time... possibly from the get-go. Look at a potential update in bodhi
without logging in. There's an add comment link that asks you for an
email address, comment, and a captcha to fill in. (Although I have
found in testing just now that anonymous commenting is currently
broken... have to find out from lmacken what's going on there.)
That still won't make users go and leave comments in the updates system.
Once they get an update that works, my experience is they are no
longer interested in the "process" that follows or continues.

What would be nice is an integration to the bodhi comments/karma system
from bugzilla. The users already use bugzilla and read that throughout
the process of solving a problem. Having them go to an entirely
different site to leave a comment that says, "works for me" is sort of
annoying from a user's point of view. If we could make that easier for
them, maybe we'd see more automatic updates pushing.

Or perhaps a yum plugin or packagekit thing that makes it easier for
users to report that a particular update worked for them.
--
David Cantrell <dcantrell at redhat.com>
Red Hat / Honolulu, HI
Jesse Keating
2009-05-08 02:59:26 UTC
Permalink
Post by David Cantrell
What would be nice is an integration to the bodhi comments/karma system
from bugzilla. The users already use bugzilla and read that throughout
the process of solving a problem. Having them go to an entirely
different site to leave a comment that says, "works for me" is sort of
annoying from a user's point of view. If we could make that easier for
them, maybe we'd see more automatic updates pushing.
Once I get my message bus in place, interaction between the tools at
this level could be possible. A specific keyword or phrase added to a
bug that bodhi knows about could be echoed into bodhi karma.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090507/154a5095/attachment.bin
Adam Williamson
2009-05-08 18:08:33 UTC
Permalink
Post by David Cantrell
Or perhaps a yum plugin or packagekit thing that makes it easier for
users to report that a particular update worked for them.
I think PackageKit / yum integration would definitely be the way to go.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
Jeff Spaleta
2009-05-08 21:17:14 UTC
Permalink
Post by Adam Williamson
I think PackageKit / yum integration would definitely be the way to go.
Goes back to the underlying issue... how do you notify the user that
package foo came from updates-testing X number of minutes/hours/days
of testing..after system installation..so they can report back after
those X number of minutes/hourse/days of testing?

We don't record from which repository a package was installed from. To
know what maybe installed from testing you have to be clever and do
something like yum --disablerepo=updates-testing list extras diffed
against yum list extras.

-jef
Adam Williamson
2009-05-08 23:20:54 UTC
Permalink
Post by Jeff Spaleta
Post by Adam Williamson
I think PackageKit / yum integration would definitely be the way to go.
Goes back to the underlying issue... how do you notify the user that
package foo came from updates-testing X number of minutes/hours/days
of testing..after system installation..so they can report back after
those X number of minutes/hourse/days of testing?
We don't record from which repository a package was installed from. To
know what maybe installed from testing you have to be clever and do
something like yum --disablerepo=updates-testing list extras diffed
against yum list extras.
That sounds extremely ugly. I think if we want to have more metadata
about packages, we should start tracking it at the appropriate level -
rpm or yum should track that information. If we're not willing to do
that, we shouldn't try and implement ugly hacks to generate the metadata
some other way.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
Richard W.M. Jones
2009-05-07 21:09:20 UTC
Permalink
Post by Jesse Keating
How is it we have 182 stable updates pending for F11 already? How have
these seen any testing by a wider audience? Are we really just not
bothering with updates-testing anymore? Do we not care about distro
stability?
I'll tell you the three reasons I'm pushing stuff directly to stable:

(1) New package.

(2) Update to a new package that I know not many people are using.

(3) Something depends on this new package. Since I can't build
anything against the new package until it goes into stable, and I
don't to wait 2+ weeks to trigger the build of the dependent package,
I essentially am forced to push packages to stable as soon as
possible.

Of which item (3) is the most annoying.

Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
Christopher Aillon
2009-05-07 21:14:58 UTC
Permalink
Post by Richard W.M. Jones
(3) Something depends on this new package. Since I can't build
anything against the new package until it goes into stable, and I
don't to wait 2+ weeks to trigger the build of the dependent package,
I essentially am forced to push packages to stable as soon as
possible.
https://fedorahosted.org/rel-eng/newticket

Ask for your package(s) to be added to the buildroot.
Richard W.M. Jones
2009-05-07 22:01:35 UTC
Permalink
Post by Christopher Aillon
Post by Richard W.M. Jones
(3) Something depends on this new package. Since I can't build
anything against the new package until it goes into stable, and I
don't to wait 2+ weeks to trigger the build of the dependent package,
I essentially am forced to push packages to stable as soon as
possible.
https://fedorahosted.org/rel-eng/newticket
Ask for your package(s) to be added to the buildroot.
Sure, I know about this. It means getting a real person from rel-eng
involved. Why can't it be automated and/or why can't builds happen
against packages in updates-testing?

Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 75 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
Jesse Keating
2009-05-08 01:05:31 UTC
Permalink
Post by Richard W.M. Jones
Sure, I know about this. It means getting a real person from rel-eng
involved. Why can't it be automated
We're getting things in place where this could be automated.
Post by Richard W.M. Jones
and/or why can't builds happen
against packages in updates-testing?
Because things in -testing go away or get replaced with something else.
This can cause a problem if your package built against something in
testing, then you pushed stable and the -testing package went away.
This mirrors what happens in RHEL land where pending errata doesn't go
into buildroots unless otherwise requested. We could toy with letting
updates-testing builds go into buildroots, but we'd have to add a whole
lot more logic to the push system that would prevent something from
being pushed to -stable unless everything it built against is also being
pushed to stable or has already been pushed.

All it takes is code.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090507/b1b9825d/attachment.bin
Jesse Keating
2009-05-07 21:37:21 UTC
Permalink
Post by Richard W.M. Jones
(3) Something depends on this new package. Since I can't build
anything against the new package until it goes into stable, and I
don't to wait 2+ weeks to trigger the build of the dependent package,
I essentially am forced to push packages to stable as soon as
possible.
Of which item (3) is the most annoying.
I could have sworn this was documented in the package update wiki page,
but it's not (please somebody wanna throw it in there somewhere?)

You can request a buildroot override, which allows you to build your
packages against something that hasn't gone stable yet.
http://fedoraproject.org/wiki/ReleaseEngineering/SOP/BuildRootOverrides
is what releng uses to describe the task, but that's not quite
appropriate for end user documentation.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090507/36cc11a0/attachment.bin
Christopher Aillon
2009-05-07 21:40:33 UTC
Permalink
Post by Jesse Keating
Post by Richard W.M. Jones
(3) Something depends on this new package. Since I can't build
anything against the new package until it goes into stable, and I
don't to wait 2+ weeks to trigger the build of the dependent package,
I essentially am forced to push packages to stable as soon as
possible.
Of which item (3) is the most annoying.
I could have sworn this was documented in the package update wiki page,
but it's not (please somebody wanna throw it in there somewhere?)
Yeah, the only place I could find it was in
http://fedoraproject.org/wiki/PackageMaintainers/Join#Install_the_Client_Tools_.28Koji.29
but that seems like the wrong place for it.
Mark McLoughlin
2009-05-08 12:31:31 UTC
Permalink
Post by Richard W.M. Jones
Post by Jesse Keating
How is it we have 182 stable updates pending for F11 already? How have
these seen any testing by a wider audience? Are we really just not
bothering with updates-testing anymore? Do we not care about distro
stability?
(1) New package.
(2) Update to a new package that I know not many people are using.
This (2) is something we should try and figure out, IMHO. Trying to
apply the same rules and guidelines to 8k+ packages doesn't work.

There is a large set of packages which always should spend some time in
updates-testing, but there's an even larger set of packages which it
probably doesn't help at all. The same goes for the pre-GA development
freeze.

Cheers,
Mark.
Simo Sorce
2009-05-08 12:50:47 UTC
Permalink
Post by Mark McLoughlin
Post by Richard W.M. Jones
Post by Jesse Keating
How is it we have 182 stable updates pending for F11 already? How have
these seen any testing by a wider audience? Are we really just not
bothering with updates-testing anymore? Do we not care about distro
stability?
(1) New package.
(2) Update to a new package that I know not many people are using.
This (2) is something we should try and figure out, IMHO. Trying to
apply the same rules and guidelines to 8k+ packages doesn't work.
There is a large set of packages which always should spend some time in
updates-testing, but there's an even larger set of packages which it
probably doesn't help at all. The same goes for the pre-GA development
freeze.
Fedora Core vs Fedora Extras ...

Simo.
--
Simo Sorce * Red Hat, Inc * New York
Mark McLoughlin
2009-05-08 14:15:03 UTC
Permalink
Post by Simo Sorce
Post by Mark McLoughlin
Post by Richard W.M. Jones
Post by Jesse Keating
How is it we have 182 stable updates pending for F11 already? How have
these seen any testing by a wider audience? Are we really just not
bothering with updates-testing anymore? Do we not care about distro
stability?
(1) New package.
(2) Update to a new package that I know not many people are using.
This (2) is something we should try and figure out, IMHO. Trying to
apply the same rules and guidelines to 8k+ packages doesn't work.
There is a large set of packages which always should spend some time in
updates-testing, but there's an even larger set of packages which it
probably doesn't help at all. The same goes for the pre-GA development
freeze.
Fedora Core vs Fedora Extras ...
Your point?

That because we've merged Core and Extras we should never differentiate
between packages based on "coreness" for anything ever again?

Cheers,
Mark.
Seth Vidal
2009-05-08 14:16:37 UTC
Permalink
Post by Mark McLoughlin
Post by Simo Sorce
Post by Mark McLoughlin
Post by Richard W.M. Jones
Post by Jesse Keating
How is it we have 182 stable updates pending for F11 already? How have
these seen any testing by a wider audience? Are we really just not
bothering with updates-testing anymore? Do we not care about distro
stability?
(1) New package.
(2) Update to a new package that I know not many people are using.
This (2) is something we should try and figure out, IMHO. Trying to
apply the same rules and guidelines to 8k+ packages doesn't work.
There is a large set of packages which always should spend some time in
updates-testing, but there's an even larger set of packages which it
probably doesn't help at all. The same goes for the pre-GA development
freeze.
Fedora Core vs Fedora Extras ...
Your point?
That because we've merged Core and Extras we should never differentiate
between packages based on "coreness" for anything ever again?
I think we shouldn't differentiate on 'coreness' b/c of how arbitrary
that distinction is.

-sv
Tom &quot;spot&quot; Callaway
2009-05-08 14:20:11 UTC
Permalink
Post by Mark McLoughlin
Post by Simo Sorce
Fedora Core vs Fedora Extras ...
Your point?
That because we've merged Core and Extras we should never differentiate
between packages based on "coreness" for anything ever again?
No, I think he may have been suggesting that the old "line in the sand"
might be a good starting point for such differentiation.

~spot
Simo Sorce
2009-05-08 14:41:50 UTC
Permalink
Post by Tom &quot;spot&quot; Callaway
Post by Mark McLoughlin
Post by Simo Sorce
Fedora Core vs Fedora Extras ...
Your point?
That because we've merged Core and Extras we should never differentiate
between packages based on "coreness" for anything ever again?
No, I think he may have been suggesting that the old "line in the sand"
might be a good starting point for such differentiation.
Right on the "spot" :-)

Simo.
--
Simo Sorce * Red Hat, Inc * New York
Jesse Keating
2009-05-08 15:20:13 UTC
Permalink
Post by Simo Sorce
Post by Tom &quot;spot&quot; Callaway
No, I think he may have been suggesting that the old "line in the sand"
might be a good starting point for such differentiation.
Right on the "spot" :-)
Unfortunately that line was pretty darn arbitrary, and nobody has put
forth a serious effort to draw a real logical line.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090508/b670da37/attachment.bin
Adam Williamson
2009-05-08 18:27:09 UTC
Permalink
Post by Jesse Keating
Post by Simo Sorce
Post by Tom &quot;spot&quot; Callaway
No, I think he may have been suggesting that the old "line in the sand"
might be a good starting point for such differentiation.
Right on the "spot" :-)
Unfortunately that line was pretty darn arbitrary, and nobody has put
forth a serious effort to draw a real logical line.
We were kicking around, in QA, using the same definition currently used
for release-critical bugs: anything that can feasibly stop the system
booting, stop X working, stop networking working, or stop you being able
to update the system (i.e. yum+dependencies) would be 'core'.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
Jesse Keating
2009-05-08 18:36:19 UTC
Permalink
Post by Adam Williamson
We were kicking around, in QA, using the same definition currently used
for release-critical bugs: anything that can feasibly stop the system
booting, stop X working, stop networking working, or stop you being able
to update the system (i.e. yum+dependencies) would be 'core'.
And anything those depend on, both runtime and build, and
anything /those/ depend on, and anything that could disrupt one of those
things, and...
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090508/96487825/attachment.bin
Kevin Kofler
2009-05-09 01:30:42 UTC
Permalink
Post by Adam Williamson
We were kicking around, in QA, using the same definition currently used
for release-critical bugs: anything that can feasibly stop the system
booting, stop X working, stop networking working, or stop you being able
to update the system (i.e. yum+dependencies) would be 'core'.
Under that definition, everything is core.

Name: foo
Provides: glibc = 999:9
Obsoletes: glibc < 999:9
(plus some assorted fake soname provides to make the depsolving happy)
breaks your system pretty fast. ^^

Kevin Kofler
Caolán McNamara
2009-05-08 12:52:02 UTC
Permalink
Post by Mark McLoughlin
Post by Richard W.M. Jones
(2) Update to a new package that I know not many people are using.
This (2) is something we should try and figure out, IMHO. Trying to
apply the same rules and guidelines to 8k+ packages doesn't work.
A rough metric of
risk = package size * 10 * is in default install * number of packages
that depend on it * their size
would probably be good enough in most cases to get a feel for how much
misery a bad update might trigger and force over a thresh-hold into
testing before stable

C.
Loading...