Hi,
I just pushed a version 0.7.5 of bodhi into production. This release
contains the following notable changes:
proventesters & strict critical path update handling
----------------------------------------------------
Critical path package[0] updates now require positive karma from two
proventesters[1], and a single +1 from one other community member.
You can get a list of critical path updates using the bodhi web interface:
https://admin.fedoraproject.org/updates/critpath?release=F13untested=True
You can optionally pass in a specific 'release' or an 'untested' flag,
which will return a list of critical path updates that have yet to be
approved. I have not added these links to the main interface yet,
because at the moment they are fairly expensive calls. This will be
addressed in an upcoming release.
The latest command-line client also supports these options as well:
$ bodhi --critpath --untested --release F13
Auto-obsoletion re-enabled
--------------------------
I re-enabled the auto-obsoletion code in bodhi. This means that new
updates will automatically obsolete older testing updates containing the
same packages. The new update will also inherit all of the old updates
bugs and notes. This code had been disabled for a while now, due to
some nasty edge cases, but those have since been resolved.
If you experience any problems, please file tickets here:
https://fedorahosted.org/bodhi/newticket
Thanks,
luke
[0]: https://fedoraproject.org/wiki/Critical_Path_Packages
[1]: https://fedoraproject.org/wiki/QA/JoinProvenTesters
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Critical path package[0] updates now require positive karma from two
proventesters[1], and a single +1 from one other community member.

Even for security updates? My experience says that this requirement
will prevent me from *ever* pushing updates. Case in point: libtiff,
which is a critpath package, has been in testing with a significant
security update for a week now. Its karma is still zero. When I get
the "old package" warning in another week, I am going to push it stable
... and if bodhi won't let me, I am going to come looking for a neck to
wring.
The proposed policy might be workable if we had a surplus of
proventester manpower available, but we obviously have not got that.
I would suggest a timeout: once the package has been in testing for two
weeks, the maintainer may push it stable regardless of whether
proventesters have fallen down on the job. Or if you really think
maintainers of critpath packages cannot be trusted to make these
decisions, I would be willing to accept *negative* karma from more than
one proventester as being an override. But it is utterly unacceptable
for inaction to represent a veto.
regards, tom lane

Even for security updates? My experience says that this requirement
will prevent me from*ever* pushing updates. Case in point: libtiff,
which is a critpath package, has been in testing with a significant
security update for a week now. Its karma is still zero. When I get
the "old package" warning in another week, I am going to push it stable
... and if bodhi won't let me, I am going to come looking for a neck to
wring.
The proposed policy might be workable if we had a surplus of
proventester manpower available, but we obviously have not got that.

If you follow the test list, there are many new proventester applications.

I would suggest a timeout: once the package has been in testing for two
weeks, the maintainer may push it stable regardless of whether
proventesters have fallen down on the job. Or if you really think
maintainers of critpath packages cannot be trusted to make these
decisions, I would be willing to accept*negative* karma from more than
one proventester as being an override. But it is utterly unacceptable
for inaction to represent a veto.

Time isn't the issue. It's man power. Updates that stay in testing for
months with no one looking at them and then get pushed to stable have
broken things before.
Should the bodhi whine mail be CC'd to the test mailing list in a
digest-type mail like the updates-testing pushes? Then all proventesters
(and non-proventesters) are informed that there is a critpath pkg that
is needing some TLC?

Luke Macken <lmacken(a)redhat.com&gt; writes:
> Critical path package[0] updates now require positive karma from two
> proventesters[1], and a single +1 from one other community member.
Even for security updates? My experience says that this requirement
will prevent me from *ever* pushing updates. Case in point: libtiff,
which is a critpath package, has been in testing with a significant
security update for a week now. Its karma is still zero.

We have not been doing proventesters testing since F13 release, because
there has been no need for it. Additionally, because the critpath karma
requirement has been disabled, there has been no convenient mechanism
for finding critpath updates. Now both of these have changed; QA
activated the proventesters yesterday, and Bodhi now has several ways to
find critpath packages (and fedora-easy-karma hopefully soon will). All
of this should result in rather more karma arriving.

On 06/30/2010 06:18 PM, Adam Williamson wrote:
> On Wed, 2010-06-30 at 11:35 -0400, Tom Lane wrote:
>> The proposed policy might be workable if we had a surplus of
>> proventester manpower available, but we obviously have not got that.
And you think re-allocating the already scarce manpower to this process
will help?
I am having very strong doubts on this.

One of the big reasons the manpower was "scarce" is we did not have a
proper system to locate, train, and promote new people into this
"manpower". The QA team has made great strides into fixing that and we
do now have a process in place, and a good stream of incoming people
willing to donate some time and effort to help the project. We are not
just "hoping" that people will show up and test, we're actively building
a community of people who will be dedicated to testing these things.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 6/30/10 9:31 AM, Ralf Corsepius wrote:
> On 06/30/2010 06:18 PM, Adam Williamson wrote:
>> On Wed, 2010-06-30 at 11:35 -0400, Tom Lane wrote:
>
>>> The proposed policy might be workable if we had a surplus of
>>> proventester manpower available, but we obviously have not got that.
> And you think re-allocating the already scarce manpower to this process
> will help?
> I am having very strong doubts on this.
>
>
One of the big reasons the manpower was "scarce" is we did not have a
proper system to locate, train, and promote new people into this
"manpower". The QA team has made great strides into fixing that and we
do now have a process in place, and a good stream of incoming people
willing to donate some time and effort to help the project.

My perception is:
"marketing" has directed into a direction which drains
away man-power into an uncertain process whose only immediate effect is
bureaucracy, whose long term outcome is uncertain and who foundations
are very questionable, to say the least.

My perception is: "marketing" has directed into a direction
which drains
away man-power into an uncertain process whose only immediate effect is
bureaucracy, whose long term outcome is uncertain and who foundations
are very questionable, to say the least.

Well yes, you always can be relied upon for the cheery optimistic outlook :)
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 6/30/10 10:48 AM, Ralf Corsepius wrote:
> My perception is: "marketing" has directed into a direction which drains
> away man-power into an uncertain process whose only immediate effect is
> bureaucracy, whose long term outcome is uncertain and who foundations
> are very questionable, to say the least.
Well yes, you always can be relied upon for the cheery optimistic outlook :)

If I were perceiving competence in Fedora's leadership, my comments
would sound differently.

On 06/30/2010 07:58 PM, Jesse Keating wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 6/30/10 10:48 AM, Ralf Corsepius wrote:
>> My perception is: "marketing" has directed into a direction which
drains
>> away man-power into an uncertain process whose only immediate effect is
>> bureaucracy, whose long term outcome is uncertain and who foundations
>> are very questionable, to say the least.
>
> Well yes, you always can be relied upon for the cheery optimistic
> outlook :)
If I were perceiving competence in Fedora's leadership, my comments
would sound differently.

>> Well yes, you always can be relied upon for the cheery
optimistic
>> outlook :)
>
> If I were perceiving competence in Fedora's leadership, my comments
> would sound differently.
You're welcome to try your hand at leadership, or find a project with
different leadership.

...or convince enough others of your position that they will vote for
the candidates you favour in our leadership elections. Since there've
been several of these since you first stated you don't approve of
Fedora's leadership, it seems the electorate doesn't agree with you...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

...or convince enough others of your position that they will vote
for
the candidates you favour in our leadership elections. Since there've
been several of these since you first stated you don't approve of
Fedora's leadership, it seems the electorate doesn't agree with you...

No. It means there haven't been enough such candidates. People did vote for
me. But alone against 8 people who didn't agree with me, I wasn't able to
achieve anything.
If you give people ballots with only Evil Dictator on them, of course Evil
Dictator will win. It doesn't say anything about the electorate.
Kevin Kofler

Adam Williamson wrote:
> ...or convince enough others of your position that they will vote for
> the candidates you favour in our leadership elections. Since there've
> been several of these since you first stated you don't approve of
> Fedora's leadership, it seems the electorate doesn't agree with you...
No. It means there haven't been enough such candidates. People did vote for
me. But alone against 8 people who didn't agree with me, I wasn't able to
achieve anything.
If you give people ballots with only Evil Dictator on them, of course Evil
Dictator will win. It doesn't say anything about the electorate.

So in your mind, there is a majority of people on your side, but they
are just too lazy to stand for election and take over the board?
Not that you are in a minority?
Twisted.
Dave.

So in your mind, there is a majority of people on your side, but
they
are just too lazy to stand for election and take over the board?

s/too lazy/too busy doing actual work/
(as opposed to wasting their time with politics or bureaucracy)
Have you noticed that all the people who are complaining about the policies
are highly experienced packagers?
And there are actually many more people disagreeing with those broken
policies than the ones you notice on the ML, they just don't have the time
to write mails to complain about them. (For example, rumors are that several
people in the Brno RH office share my concerns.)
Kevin Kofler

Dave Airlie wrote:
> So in your mind, there is a majority of people on your side, but they
> are just too lazy to stand for election and take over the board?
s/too lazy/too busy doing actual work/
(as opposed to wasting their time with politics or bureaucracy)
Have you noticed that all the people who are complaining about the policies
are highly experienced packagers?
And there are actually many more people disagreeing with those broken
policies than the ones you notice on the ML, they just don't have the time
to write mails to complain about them. (For example, rumors are that several
people in the Brno RH office share my concerns.)

but these people are still in a minority. you are living in a fallacy.
There is also a large percentage of people who agree with the changes
are also "too busy doing actual work", I agree with them, I don't run
for the board, I barely vote, I am an "experienced packager". Like I can
totally handle you being anti-everything anyone does around here, I
can't handle you thinking you are in a majority.
I also work in Brisbane RH office, and I have lots of examples of people
who don't share your concerns.
I've seen surveys before where side A says, I have 100 scientists who
agree with my POV, and you get the other side saying I have 100
scientists all called Dave, who agree with mine.
Dave.

On Thu, 2010-07-01 at 07:00 +0200, Kevin Kofler wrote:
> Dave Airlie wrote:
> > So in your mind, there is a majority of people on your side, but they
> > are just too lazy to stand for election and take over the board?
>
> s/too lazy/too busy doing actual work/
> (as opposed to wasting their time with politics or bureaucracy)
>
> Have you noticed that all the people who are complaining about the policies
> are highly experienced packagers?
>
> And there are actually many more people disagreeing with those broken
> policies than the ones you notice on the ML, they just don't have the time
> to write mails to complain about them. (For example, rumors are that several
> people in the Brno RH office share my concerns.)
but these people are still in a minority. you are living in a fallacy.

How do you know who is a minority and who is not? I still wonder why
there are so many claims that the majority of Fedora maintainers or
users want to manually test all updates, but still the majority is not
involved in testing the updates. When the discussion started, it was
claimed that submitting karma was too complicated and took too much
time. This is not the case for several months, but still there are
updates that do not receive any karma for more than a month. The last
Bodhi statistics showed 595 unique karma submitters for F13 and there
seem to be 1035 approved packagers currently in Fedora. So if only
packagers submitted karma, it would be the majority. But since there are
a lotsmore users and also dedicated testers for Fedora, it does not look
like a majority anymore.
Regards
Till

How do you know who is a minority and who is not? I still wonder why
there are so many claims that the majority of Fedora maintainers or
users want to manually test all updates, but still the majority is not
involved in testing the updates. When the discussion started, it was
claimed that submitting karma was too complicated and took too much
time. This is not the case for several months, but still there are
updates that do not receive any karma for more than a month. The last
Bodhi statistics showed 595 unique karma submitters for F13 and there
seem to be 1035 approved packagers currently in Fedora. So if only
packagers submitted karma, it would be the majority. But since there are
a lotsmore users and also dedicated testers for Fedora, it does not look
like a majority anymore.

Simply, if it's not mandatory, it's too easy to be lazy and not do it.
But when it is mandatory, more people participate.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

On 7/1/10 2:48 AM, Till Maas wrote:
> How do you know who is a minority and who is not? I still wonder why
> there are so many claims that the majority of Fedora maintainers or
> users want to manually test all updates, but still the majority is not
> involved in testing the updates. When the discussion started, it was
> claimed that submitting karma was too complicated and took too much
> time. This is not the case for several months, but still there are
> updates that do not receive any karma for more than a month. The last
> Bodhi statistics showed 595 unique karma submitters for F13 and there
> seem to be 1035 approved packagers currently in Fedora. So if only
> packagers submitted karma, it would be the majority. But since there are
> a lotsmore users and also dedicated testers for Fedora, it does not look
> like a majority anymore.
>
Simply, if it's not mandatory, it's too easy to be lazy and not do it.
But when it is mandatory, more people participate.

Do the participate because they care or because they have to to get the
things they care about done, when it is mandatory? I am very convinced
that people who care about something will do it nonetheless, even if it
is not mandatory and people who do something only because it is
mandatory will perform not as good as convinced people, i.e. "bend" the
rules to achieve what needs to be achieved with as little effort as
possible instead of trying to be as good as one can be. I also found
some other interesting number. According to
http://fedoraproject.org/wiki/File:Accounts_2010-02.jpg there are more
than 25.000 active Fedora Accounts. So for a majority there would be
more than 12.500 people wanting manual testings and only about 5% of this
interested people care enough to submit at least one karma comment in
Bodhi for Fedora 13. And
http://fedoraproject.org/wiki/Statistics#Who_uses_Fedora.3F claims that
even millions of people use Fedora. But I guess somehow it boils down to
"the majority wants that other people to work for them", which might
even be true. But in a FOSS community I doubt it is very healthy to
follow this too much.
Regards
Till

On 7/1/10 2:55 PM, Till Maas wrote:
> But I guess somehow it boils down to
> "the majority wants that other people to work for them", which might
> even be true. But in a FOSS community I doubt it is very healthy to
> follow this too much.
>
I bet if we stopped making package reviews mandatory, none would get
done. This follows the same.

This is an interesting comparison, because there are still not enough
reviewers even though it is mandatory. Also everyone directly benefits
from the reviews, because there are clear statements what is checked and
there are more often issues to be fixed in reviews, than there are
updates that are bad. And in addition people who care already extra
review packages and catch issues that were not found in the official
review or check packages after guidelines changed, like there are checks
for the static libs guidelines.
So there is non mandatory action to fix brokenness and I am very sure
that there would be more if more packages were when reviews were not
mandatory, as long as the Guidelines make sense and help the packages to
interact. There are even people catching mistakes in commits currently,
which is also completely non mandatory.
Regards
Till

On Thu, Jul 01, 2010 at 05:23:06PM +1000, Dave Airlie wrote:
> On Thu, 2010-07-01 at 07:00 +0200, Kevin Kofler wrote:
> > Dave Airlie wrote:
> > > So in your mind, there is a majority of people on your side, but they
> > > are just too lazy to stand for election and take over the board?
> >
> > s/too lazy/too busy doing actual work/
> > (as opposed to wasting their time with politics or bureaucracy)
> >
> > Have you noticed that all the people who are complaining about the policies
> > are highly experienced packagers?
> >
> > And there are actually many more people disagreeing with those broken
> > policies than the ones you notice on the ML, they just don't have the time
> > to write mails to complain about them. (For example, rumors are that several
> > people in the Brno RH office share my concerns.)
>
> but these people are still in a minority. you are living in a fallacy.
How do you know who is a minority and who is not? I still wonder why

I think the fact that there is about x:1 people standing for the
board/fesco with one view vs the other. The same reasons Kevin gives for
nobody who shares his view as having motiviation for running for the
board, can just as easily be applied to everyone who doesn't share his
view. As one of the people who is too "busy doing actual work" to run
for the board I see my views reflected by the x members of the
board/fesco as opposed to the one. So it probably stacks up like a the
majority of people don't care, the next sizeable minority agree with the
decision, and the final group disagree and make most noise, and hence
seem to imply they are largest.
Dave.

No. It means there haven't been enough such candidates. People
did vote for
me. But alone against 8 people who didn't agree with me, I wasn't able to
achieve anything.
If you give people ballots with only Evil Dictator on them, of course Evil
Dictator will win. It doesn't say anything about the electorate.

Why do you continue to hang around in a group you believe has a silent
majority that agrees with you (but doesn't show up for elections) and
that you think is run by Evil Dictators? That's really an insult to the
people putting in effort to make Fedora better.
--
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Adam Williamson wrote:
> ...or convince enough others of your position that they will vote for
> the candidates you favour in our leadership elections. Since there've
> been several of these since you first stated you don't approve of
> Fedora's leadership, it seems the electorate doesn't agree with you...
No. It means there haven't been enough such candidates. People did vote for
me. But alone against 8 people who didn't agree with me, I wasn't able to
achieve anything.

I voted for you, but given how you behaved when actually a member of
FESCo, I kind of came to regret it. I think your assessment is not
entirely correct. It wasn't because (or not entirely because) it was You
Versus 8, but because of how you conducted yourself in meetings and
discussions. Essentially, you were a large part of *making* it You
Versus 8, rather than nine people with various different opinions but
also some broad common ground.
This time I again made a point of voting for people who are not in 'the
cabal' (which doesn't exist, of course), but tried to pick ones who I
thought would work in productive and co-operative ways within FESCo.

If you give people ballots with only Evil Dictator on them, of course
Evil
Dictator will win. It doesn't say anything about the electorate.

I realize you're just drawing a rather shaky analogy and not suggesting
the other FESCo candidates were Evil Dictators, but even still, I don't
think this is an appropriate illustration of the process.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

One of the big reasons the manpower was "scarce" is we did
not have a
proper system to locate, train, and promote new people into this
"manpower". The QA team has made great strides into fixing that and we
do now have a process in place, and a good stream of incoming people
willing to donate some time and effort to help the project. We are not
just "hoping" that people will show up and test, we're actively building
a community of people who will be dedicated to testing these things.

Fedora Legacy has shown how well this works… not!
I completely agree with Ralf Corsepius and Tom Lane on this subject: this
policy is very unhelpful, and applying it to security updates is just
totally insane. We're going to see machines compromised because critical
fixes are getting delayed by brainless technobureaucracy.
You have seen Fedora Legacy fail, why are you forcing your personal ideas
which DID NOT WORK onto all of us?
Kevin Kofler

Fedora Legacy has shown how well this works… not!
I completely agree with Ralf Corsepius and Tom Lane on this subject: this
policy is very unhelpful, and applying it to security updates is just
totally insane. We're going to see machines compromised because critical
fixes are getting delayed by brainless technobureaucracy.

Let's put aside the needless, inflammatory rhetoric for just a brief
moment, and actually try to think about ways to solve problems, shall
we?
The main reasons we want to perform testing are things like: to avoid
pushing updates with broken dependencies, or updates that cause serious
regressions requiring manual intervention / emergency update
replacements. That sort of thing.
But your assertion seems to be something like: "This is obviously going
to fail horribly and therefore any testing is a waste of time". Various
reasons for this have been bandied about - "there isn't enough manpower"
and "it's going to slow down updates and make people vulnerable for
longer" are the most prominent ones, as I see it.
Now. For each of these reasons - pro and con - there should be some
things we can actually measure. Turnaround time on security updates, for
instance.
Given measurements of some agreed-upon metrics over time, we can
actually quantify whether or not this policy is a "failure", rather than
just SHOUTING and WAVING OUR ARMS and PREDICTING DOOM and QUOTING
WAYNE'S WORLD at one another.
Therefore: I propose that we choose a few metrics ("turnaround time on
security updates", "average number of live updates with broken
dependencies per day", etc.). Then we begin measuring them (and, if
possible, collect historical, pre-critpath data to compare that to).
I'm willing to bet that these metrics have improved since we started the
critpath policies before F13 release, and will continue to improve over
the course of F13's lifecycle and the F14 development cycle.
In fact, Kevin, given a set of metrics we're both happy with, I'd be
willing to stake my subscription to this list on it - for, say, 3
months. Are you willing to do the same?
-w

On 07/02/2010 06:20 PM, Will Woods wrote:
> The main reasons we want to perform testing are things like: to avoid
> pushing updates with broken dependencies, or updates that cause serious
> regressions requiring manual intervention / emergency update
> replacements. That sort of thing.
>
Should be done scripted as part of the "package push process".
No need for karmas, no need for "provenpackager"

That only handles a subset of the 'broken dependencies' problem. We've
already had an example this year of a dependency issue the proposed
autoqa depcheck test wouldn't catch, and Michael's script didn't - the
nss-softokn update (as the broken dep is only apparent if you take into
consideration multilib issues and which repositories will have which
updated packages available).
Given Murphy's Law, I am willing to bet that, even when we have an
automated dependency checker in place, someone will manage to push an
update which causes a dependency problem which the automated test
doesn't catch. Manual testing will help us catch that.
And, again, though Will mentioned two types of broken update, you only
considered one in your reply.

On Fri, 2010-07-02 at 18:24 +0200, Ralf Corsepius wrote:
> On 07/02/2010 06:20 PM, Will Woods wrote:
>
>
> > The main reasons we want to perform testing are things like: to avoid
> > pushing updates with broken dependencies, or updates that cause serious
> > regressions requiring manual intervention / emergency update
> > replacements. That sort of thing.
> >
> Should be done scripted as part of the "package push process".
> No need for karmas, no need for "provenpackager"
That only handles a subset of the 'broken dependencies' problem. We've
already had an example this year of a dependency issue the proposed
autoqa depcheck test wouldn't catch, and Michael's script didn't - the
nss-softokn update

(as the broken dep is only apparent if you take into
consideration multilib issues and which repositories will have which
updated packages available).

There are multiple problems:
* Upgrades from F12 to F13. The depcheck for F13 would need to enable F12
repos _always_ - to catch upgrade path violations that lead to dependency
problems. I only do this a few times shortly before the release of FN+1
(=F13).
* Yum depsolving behaviour on systems where multiarch packages are
installed and an update isn't multiarch anymore. For example, where Yum on
x86_64 would pull in lots of i686 packages to resolve dependencies, that
would be considered a problem by the user but not by a depchecker, because
there are no unresolvable dependencies to detect. Unless you teach the
depsolver (and depchecker) that cross-arch dependencies are something
to report as a problem. That would be more than "repository closure".
The depchecker doesn't look for file conflicts either. There could be a
dependency chain, which doesn't suffer from unresolvable deps but from
implicit file conflicts.

> That only handles a subset of the 'broken dependencies'
problem. We've
> already had an example this year of a dependency issue the proposed
> autoqa depcheck test wouldn't catch, and Michael's script didn't - the
> nss-softokn update
Which one was that?
https://bugzilla.redhat.com/596840 ?

> (as the broken dep is only apparent if you take into
> consideration multilib issues and which repositories will have which
> updated packages available).
There are multiple problems:
* Upgrades from F12 to F13. The depcheck for F13 would need to enable F12
repos _always_ - to catch upgrade path violations that lead to dependency
problems. I only do this a few times shortly before the release of FN+1
(=F13).
* Yum depsolving behaviour on systems where multiarch packages are
installed and an update isn't multiarch anymore. For example, where Yum on
x86_64 would pull in lots of i686 packages to resolve dependencies, that
would be considered a problem by the user but not by a depchecker, because
there are no unresolvable dependencies to detect. Unless you teach the
depsolver (and depchecker) that cross-arch dependencies are something
to report as a problem. That would be more than "repository closure".
The depchecker doesn't look for file conflicts either. There could be a
dependency chain, which doesn't suffer from unresolvable deps but from
implicit file conflicts.

Yep, indeed. I'm really not criticising the script. I'm just pointing
out that we know there are some pretty complex scenarios out there which
we haven't yet figured out how to test in an automated way; I'm
challenging the assumption that we can write a perfect depcheck test
which will ensure there is never a dependency issue ever again.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

Broken deps in Fedora 13 + updates + updates-testing when
also enabling Fedora 12 + updates + updates-testing.
One can quickly see that several (if not many) of them are due
to orphans/retired packages in Fedora 12. And due to violated upgrade
paths (e.g. compat-db):

So I guess ghc needs to add some Obsoletes for
ghc-time{,-devel,-doc,-prof}? According to dead.package it is now
included in ghc:
http://cvs.fedoraproject.org/viewvc/rpms/ghc-time/devel/dead.package?revi...
Would this be correct?
ghc:
Obsoletes: ghc-time < 1.1.2.5
Obsoletes: ghc-time-devel < 1.1.2.5
ghc-doc:
Obsoletes: ghc-time-doc < 1.1.2.5
ghc-prof:
Obsoletes: ghc-time-prof < 1.1.2.5
But what about provides, would it be
Provides: ghc-time-1.1.4-%{release} etc? Given that version 1.1.4 of
ghc-time is included in ghc?

For me it is not that easy, because the information is confusion (or not
clearly arranged) or not directly accessible, e.g. to understand the
compat-db problems one needs to look at the koji page for the list of
built rpms. So here the release of compat-db needs to be increased to
11 in F13?
Regards
Till

> It's fairly easy to verify other broken deps, too:
> http://admin.fedoraproject.org/updates/compat-db-4.7.25-3.fc13
For me it is not that easy, because the information is confusion (or not
clearly arranged) or not directly accessible, e.g. to understand the
compat-db problems one needs to look at the koji page for the list of
built rpms.

Hmmm ... most of the broken deps are of the form
something requires something-unavailable
where "something-unavailable" either has never existed before or is gone
because of an update.
One could attempt at writing code to automate checks that help with
interpreting other results in the broken deps report.
1) Is "something" the newest (EVR)? If not, it would be an old multiarch
package that is no longer multiarch. (Else, the repositories are broken
and a later build of "something" is missing.) [1]
2) If "something-unavailable" is of the form "key = value", does
anything
still provide "key"? If so, show latest EVR, and "something" will need
an
update, or is a missing obsolete, or is an old multiarch build that is
missing a multiarch update.
3) If "something-unavailable" is a SONAME, try to find a similar SONAME
and inform the library packager. This is not 100%, but is done already
as in the Rawhide broken deps report.
| Broken packages in fedora-updates-13-i386:
|
| compat-db-4.7.25-3.fc13.i686 requires compat-db46(x86-32) = 0:4.6.21-3.fc13
| compat-db-4.7.25-3.fc13.i686 requires compat-db45(x86-32) = 0:4.5.20-3.fc13

-12.fc13, because compat-db45 and compat-db46 for F12 updates are -11.fc12
and newer than -3.fc13
[1] Some multiarch broken deps in F12 exist for a long time without
the packagers showing interest in fixing them. That isn't anything like
encouraging.

On Sun, 04 Jul 2010 14:40:20 +0200, Till wrote:
> > It's fairly easy to verify other broken deps, too:
> > http://admin.fedoraproject.org/updates/compat-db-4.7.25-3.fc13
>
> For me it is not that easy, because the information is confusion (or not
> clearly arranged) or not directly accessible, e.g. to understand the
> compat-db problems one needs to look at the koji page for the list of
> built rpms.
Hmmm ... most of the broken deps are of the form
something requires something-unavailable
where "something-unavailable" either has never existed before or is gone
because of an update.
One could attempt at writing code to automate checks that help with
interpreting other results in the broken deps report.
1) Is "something" the newest (EVR)? If not, it would be an old multiarch
package that is no longer multiarch. (Else, the repositories are broken
and a later build of "something" is missing.) [1]
2) If "something-unavailable" is of the form "key = value", does
anything
still provide "key"? If so, show latest EVR, and "something" will
need an
update, or is a missing obsolete, or is an old multiarch build that is
missing a multiarch update.
3) If "something-unavailable" is a SONAME, try to find a similar SONAME
and inform the library packager. This is not 100%, but is done already
as in the Rawhide broken deps report.

For the non F13 repos:
4) something is retired, if it is renamed or merged into something else,
obsoletes are missing, else it is not a problem afaik. In case something
is retired, the script could e.g. show the contents of the respective
dead.package.
5) if something is not retired, there is a upgrade path problem that
should be fixed before it's called broken deps.
Additionally the script could also tell if an affected package has been
orphaned to show that nobody is taking care of it and maybe whether
there is a newer version in CVS and whether it is built. This and maybe
even more needs to be done manually anyhow.

These are multilib problems. koffice-kivio and kdeedu-math are no longer
multilib. But people should not have those installed as multilib anyway,
since they're leaf packages. This just shows how the "install everything as
multilib" option is harmful and we should finally stop supporting that
nonsense completely (it stopped being the default in F9, thankfully).
On all architectures:

Therefore: I propose that we choose a few metrics ("turnaround
time on
security updates", "average number of live updates with broken
dependencies per day", etc.). Then we begin measuring them (and, if
possible, collect historical, pre-critpath data to compare that to).
I'm willing to bet that these metrics have improved since we started the
critpath policies before F13 release, and will continue to improve over
the course of F13's lifecycle and the F14 development cycle.

I am interested in these metrics, too. Afaik it will be the first time
in the update testing discussion that there will be metrics that can be
used to evaluate it. But imho the turnaround time is not only
interesting for security updates, but for all updates that fix bugs, so
probably most non-newpackage updates.
Btw. on a related issue:How do provenpackagers properly test for broken
deps manually? The case where two updates in updates-testing are
required to update one of them seems to me hard to ensure manually. But
when only one of both updates is pushed to stable, there will be a
broken dependency. I know that the fix is to bundle the builds of both
updates into one, but how is this tested?
Regards
Till

On 07/02/2010 08:12 PM, Till Maas wrote:
> Btw. on a related issue:How do provenpackagers properly test for broken
> deps manually?
Like ordinary packagers should do ;)
The only difference between provenpackagers and "ordinary packagers" is
them having write access to packages they do not own.

The only way I know is pushing the update to testing and then the broken
dep checker will kick in, because only at push time the package set for
the next stable is known.
Regards
Till

Btw. on a related issue:How do provenpackagers properly test for
broken
deps manually?

Every packager can [configure and] run repoclosure from yum-utils.
Enable updates-testing, and optionally add a local repo for your own
candidate builds. It should work with the default Yum configuration.

The case where two updates in updates-testing are
required to update one of them seems to me hard to ensure manually. But
when only one of both updates is pushed to stable, there will be a
broken dependency. I know that the fix is to bundle the builds of both
updates into one, but how is this tested?

(I don't understand the question.) Ordinary test-updates cannot break
other test-updates unless a koji buildroot override is involved.
For updates without a koji buildroot override, only when an incompatible
test-update is pushed to stable, it breaks dependencies of released
packages outside updates-testing and also becomes available in the koji
buildroot.
So, you don't have anything like "only one of both updates is pushed to
stable", because with a proper announcement of an incompatible update
*and* communication about a koji buildroot override, all needed rebuilds
should be known. Whether you let one packager put them all into the same
bodhi ticket or have one packager push multiple tickets at once, is a
process/documentation issue. There is no need to create bodhi tickets
before all rebuilds are available, btw.
For any update that isn't tested by the packager for incompatibilities
with previous releases (e.g. using tools from the "rpmdevtools" package),
so far it's important to not skip updates-testing and give me at least 24
hours to run extras-repoclosure (with stable test-updates entering nirvana
until they become available in the updates repo, there is a window during
which some packages are missing). For any incompatible test-update, the
package dependencies it will break will be discovered.
[About automating this during the push process, it is possible to have
a depchecker simulate a --skip-broken and exclude packages which break
dependencies. There are different strategies. However, the procedure
must be backed up by strong policies, or else we will see broken deps
whenever somebody skips the automated depchecking to push "something
important".]

On Fri, 02 Jul 2010 20:12:26 +0200, Till wrote:
> Btw. on a related issue:How do provenpackagers properly test for broken
> deps manually?
Every packager can [configure and] run repoclosure from yum-utils.
Enable updates-testing, and optionally add a local repo for your own
candidate builds. It should work with the default Yum configuration.
> The case where two updates in updates-testing are
> required to update one of them seems to me hard to ensure manually. But
> when only one of both updates is pushed to stable, there will be a
> broken dependency. I know that the fix is to bundle the builds of both
> updates into one, but how is this tested?
(I don't understand the question.) Ordinary test-updates cannot break
other test-updates unless a koji buildroot override is involved.
For updates without a koji buildroot override, only when an incompatible
test-update is pushed to stable, it breaks dependencies of released
packages outside updates-testing and also becomes available in the koji
buildroot.

This is not true, because there can be runtime dependencies on another
update in -testing that is not build dependency, e.g. if an python app
requires a newer version of a python module.

So, you don't have anything like "only one of both updates
is pushed to
stable", because with a proper announcement of an incompatible update
*and* communication about a koji buildroot override, all needed rebuilds
should be known. Whether you let one packager put them all into the same
bodhi ticket or have one packager push multiple tickets at once, is a
process/documentation issue. There is no need to create bodhi tickets
before all rebuilds are available, btw.

Just requiring proper communication will lead to failure, because e.g.
new maintainers might not know some of these problems and autokarma
pushes one of the dependent updates to stable but not the other. And
this already happened with a highly used package.
Also Bodhi does not allow to fix updates by other people than the update
submitter afaik. Also it is not possible to e.g. add my new package to
some other update to ensure atomicity. E.g. when I wrote
fedora-easy-karma, it needed a version of python-fedora that was only in
updates-testing. But there was no easy way for me to ensure in Bodhi
that f-e-k will only be pushed to stable after the python-fedora update.
The only supported way other than ensuring it manually is to ask the
python-fedora update submitter to include the f-e-k build. But then all
changes wrt to the f-e-k build need to be proxied through the
python-fedora submitter, which just means double work. And it also means
that for the manually method I need to ensure that autokarma is off, but
it also tries to re-activate itself with every update edit.
Regards
Till

This is not true, because there can be runtime dependencies on
another
update in -testing that is not build dependency, e.g. if an python app
requires a newer version of a python module.

1) To make such run-time deps BuildRequires would be helpful (because it
doesn't make much sense to build something for a target that is missing
something). Several broken deps in old dist branches have been because
of a discrepancy between Requires and BuildRequires.
2) You don't need to push your python app before the python module.
It would be good to test the python module first, give feedback in bodhi,
and then you also receive the notification when it's pushed to
stable. Then you can push the app. IOW, wait for the new python module
version to be released.

Just requiring proper communication will lead to failure, because
e.g.
new maintainers might not know some of these problems and autokarma
pushes one of the dependent updates to stable but not the other. And
this already happened with a highly used package.

Then don't rush. If you are aware of a strict dependency, you either need
to communicate or wait for the require piece to be pushed first.

Bodhi ought to meet the package maintainers' requirements, not vice versa.
If you determine a problem with the typical work-flow, how about talking
to the bodhi developer and/or the people who decide on the release policies.

On Sat, 03 Jul 2010 12:50:15 +0200, Till wrote:
> This is not true, because there can be runtime dependencies on another
> update in -testing that is not build dependency, e.g. if an python app
> requires a newer version of a python module.
1) To make such run-time deps BuildRequires would be helpful (because it
doesn't make much sense to build something for a target that is missing
something). Several broken deps in old dist branches have been because
of a discrepancy between Requires and BuildRequires.

If this should be normal, then IMHO rpmbuild should be changed to
use all explicit Requires also as BuildRequires.

> Just requiring proper communication will lead to failure,
because e.g.
> new maintainers might not know some of these problems and autokarma
> pushes one of the dependent updates to stable but not the other. And
> this already happened with a highly used package.
Then don't rush. If you are aware of a strict dependency, you either need
to communicate or wait for the require piece to be pushed first.

Yes, but this is something that might happen, which is what mistakes
are and testing is there to prevent.

> Also Bodhi does not allow to [...]
Bodhi ought to meet the package maintainers' requirements, not vice versa.
If you determine a problem with the typical work-flow, how about talking
to the bodhi developer and/or the people who decide on the release policies.

Except that Bodhi never met this requirement and development is too slow
to catch up here. And there seems also be a lack of effort to test
changes to Bodhi before they go stable, which is somehow ironic since
the changes made to Bodhi are there intended to ensure better package
quality but not better Bodhi quality. Btw. the autokarma issue is
already reported in Bodhi:
https://fedorahosted.org/bodhi/ticket/396
And a broken deps detection ticket exists for 3 years:
https://fedorahosted.org/bodhi/ticket/79
Regards
Till

> 1) To make such run-time deps BuildRequires would be helpful
(because it
> doesn't make much sense to build something for a target that is missing
> something). Several broken deps in old dist branches have been because
> of a discrepancy between Requires and BuildRequires.
If this should be normal, then IMHO rpmbuild should be changed to
use all explicit Requires also as BuildRequires.

It is normal for several automatic dependencies, e.g. for a run-time
library dep you have the corresponding -devel BR in the spec file.
Creating BR for run-time deps can also be helpful in situations where
rpmbuild could not assist you. E.g. an app dlopens an optional libfoo.so.1
at run-time. If you wanted to check for availability of libfoo.so.1 in
the dist at pkg build-time, you would add a BR for the library pkg [and a
guard in %prep or %check].
Along the same line, if you have an explicit Req, possibly even a
versioned one, checking for the required stuff in a BR ensures that
everything you need at run-time, is available in the target dist.
For Python modules there are no automatic deps set by rpmbuild yet,
however. Except for the python(abi) dep.
And there would be drawbacks, too, for a hardcoded "Req => BR" rule.
It would make circular deps impossible: Pkg A requires Pkg A-extras,
and Pkg A-extras BR Pkg A. It would make bootstrapping a dist more
complicated. For some pkgs (e.g. leaf pkgs) it is fine if they are
not available in the buildroot when building a pkg that requires the
leaf pkg at run-time. For other pkgs it is fine if you build them
with an old build tool for a target env that is build upon a newer tool.

On Sat, 03 Jul 2010 13:35:20 +0200, Till wrote:
> > 1) To make such run-time deps BuildRequires would be helpful (because it
> > doesn't make much sense to build something for a target that is missing
> > something). Several broken deps in old dist branches have been because
> > of a discrepancy between Requires and BuildRequires.
>
> If this should be normal, then IMHO rpmbuild should be changed to
> use all explicit Requires also as BuildRequires.
It is normal for several automatic dependencies, e.g. for a run-time
library dep you have the corresponding -devel BR in the spec file.
Creating BR for run-time deps can also be helpful in situations where
rpmbuild could not assist you. E.g. an app dlopens an optional libfoo.so.1
at run-time. If you wanted to check for availability of libfoo.so.1 in
the dist at pkg build-time, you would add a BR for the library pkg [and a
guard in %prep or %check].
Along the same line, if you have an explicit Req, possibly even a
versioned one, checking for the required stuff in a BR ensures that
everything you need at run-time, is available in the target dist.

This is not semantically part of building, though. I see two possible solutions:
1. Koji should check the explicitly-listed Requirements and refuse to
build a package if these
are not available
2. A package undergoes an RPM test-install post-build
Regards,
--
Michel

And there would be drawbacks, too, for a hardcoded "Req =>
BR" rule.
It would make circular deps impossible: Pkg A requires Pkg A-extras,
and Pkg A-extras BR Pkg A. It would make bootstrapping a dist more
complicated.

For this example Pkg A-extras already BRs itself, how will the Req => BR
rule make it worse?

For other pkgs it is fine if you build them
with an old build tool for a target env that is build upon a newer tool.

But this has nothing to do with ensuring the run-time deps are available
at build time. Off course then the BRs are not really required then, but
this is what all this is about.
But in case this rule makes it impossible to build certain packages,
than there obviously needs to be a way to disable this rule, but it can
still be default if it usually is considered to be a benefit.
Regards
Till

On Sun, Jul 04, 2010 at 12:06:39PM +0200, Michael Schwendt wrote:
> And there would be drawbacks, too, for a hardcoded "Req => BR" rule.
> It would make circular deps impossible: Pkg A requires Pkg A-extras,
> and Pkg A-extras BR Pkg A. It would make bootstrapping a dist more
> complicated.
For this example Pkg A-extras already BRs itself, how will the Req => BR
rule make it worse?

You can build Pkg A without having Pkg A-extras in the buildroot.
If, on the contrary, Pkg A had an automatic BR Pkg A-extras because
it required Pkg A-extras at run-time, you could not build Pkg A (and
you could not build Pkg A-extras because it BR Pkg A).

> For some pkgs (e.g. leaf pkgs) it is fine if they are
> not available in the buildroot when building a pkg that requires the
> leaf pkg at run-time.
If a package is required at run-time, it is not a leaf package, because
a leaf package is a package that is not required by something else.

Dunno what the terminology is here. A leaf node is part of a dependency
tree (an end-point in a graph == a vertex with degree 1). Anything completely
optional is part of its own dependency graph, which then would be a tree
with one root node, which in turn would also be a leaf. :-)
Example: A fonts package. And an App that requires the fonts package with
an explicit Requires. If the fonts package became a BR, you could not build
the App prior to the fonts package. Could be a hindrance/annoyance.

> For other pkgs it is fine if you build them
> with an old build tool for a target env that is build upon a newer tool.
But this has nothing to do with ensuring the run-time deps are available
at build time. Off course then the BRs are not really required then, but
this is what all this is about.

It is related, because the build framework (imagine it is written in Python)
may be completely separate from what the built app will need at run-time.
One cannot mandate that the run-time deps must be available at build-time,
since then the package could only be built _after_ other packages, while
theoretically it would be fine to build it independently.

But in case this rule makes it impossible to build certain packages,
than there obviously needs to be a way to disable this rule, but it can
still be default if it usually is considered to be a benefit.

Well, I see a benefit in many scenarios. Req => BR mapping would also
have prevented bad builds for Fedora and EPEL, which simply could not be
used at all because of missing run-time dependencies. Of course, one can
let packagers build crap and rely on rel-eng to verify whether the builds
"fit into the target dist" with an ordinary depcheck. But packagers who
verify their run-time deps when preparing a build, are aided by BR and
additional guards in %prep/%check.

And there would be drawbacks, too, for a hardcoded "Req =>
BR" rule.
It would make circular deps impossible: Pkg A requires Pkg A-extras,
and Pkg A-extras BR Pkg A. It would make bootstrapping a dist more
complicated. For some pkgs (e.g. leaf pkgs) it is fine if they are
not available in the buildroot when building a pkg that requires the
leaf pkg at run-time. For other pkgs it is fine if you build them
with an old build tool for a target env that is build upon a newer tool.

Also note that we explicitly patch the build time checks for PyKDE4
(subpackage of kdebindings) out of some KDE modules which have Python-based
subpackages needing PyKDE4 at runtime because we DON'T want to BR PyKDE4,
since kdebindings is usually one of the last packages we build for a given
KDE version.
Kevin Kofler

> Also Bodhi does not allow to [...]
Bodhi ought to meet the package maintainers' requirements, not vice versa.
If you determine a problem with the typical work-flow, how about talking
to the bodhi developer and/or the people who decide on the release policies.

Btw. this was not meant as Bodhi-bashing but as an explanation why these
kind of ways to break the deps unintended are likely to happen.
Regards
Till

[About automating this during the push process, it is possible to
have
a depchecker simulate a --skip-broken and exclude packages which break
dependencies. There are different strategies. However, the procedure
must be backed up by strong policies, or else we will see broken deps
whenever somebody skips the automated depchecking to push "something
important".]

This is approximately what the (in-progress) 'depcheck' test does. And
the proposed policy backing it is fairly strong: no package that fails
depcheck will be eligible for push to a live repo without rel-eng
override.
I've been meaning to write a blog post detailing the depcheck algorithm,
because getting the test right turns out to be *really* tricky. There
have been a lot of meandering discussions about how it *should* be done,
but it's complex enough that nobody's actually managed to sit down and
*do* it before now.
I'll attempt to give a brief summary here. First you need to understand
that there are three states for a package that has been built with the
hope of being pushed as an update:
* 'candidate': freshly-built packages intended for updates
* 'proposed': bodhi request filed, but not pushed live
* 'live': packages that have been pushed live by rel-eng
So. What we want to do in AutoQA is trigger a test to check dependencies
*before* the package goes live. So we trigger our test when the request
is filed (this is the 'post-bodhi-update' hook in AutoQA, which was
merged a week or two back).
It should be obvious that the goal of the test is to examine the
proposed updates and hold back the ones whose dependencies are
inconsistent with the packages in the live repos[1]. To phrase it
slightly differently: we want to look at the set of 'proposed' updates
and pass the packages whose dependencies *are* consistent with the live
repos.
As Michael correctly suggests, this is almost exactly the same as
running yum --skip-broken and seeing which packages can be installed. In
fact, we use the exact same depsolving code to determine this[2].
The first automated runs of this test should start this week - but it
may take a week or two of testing to ensure depcheck is running as
expected.
Once we're satisfied that depcheck does the right thing, we will
probably set it up to start adding automatic +1 karma from 'autoqa' when
updates pass the automated test suite (depcheck and possibly other tests
- rpmlint, rpmguard, etc.). We haven't yet decided if the autokarma will
apply to all packages or just critpath packages; it may apply
everywhere, which will make it a bit easier to get to +3 karma for
automated updates.
Once that's working we plan to add code to bodhi to show rel-eng which
updates have passed depcheck, so only those packages which won't break
the repos will get pushed. And then life will be lots nicer.
I know that's kind of a long explanation, but it's kind of a complicated
problem. Please feel free to examine the depcheck code and ask any
questions you like. If you have any "does it handle situation X"
questions, try to construct an actual test case (e.g. create some
trivial RPMs to illustrate the situation) and we'll put that into the
depcheck test suite.
If there are any other questions, feel free to ask.
-w
[1] Note that the test needs to check *all* the proposed updates, not
just the new individual update that is triggering the test. Otherwise
anything that got rejected would have to be resubmitted to re-trigger
the test (which would be annoying) and mutually dependent updates would
fail forever (which would be broken).
[2]
http://git.fedorahosted.org/git/?p=autoqa.git;a=blob;f=tests/depcheck/dep...

Once we're satisfied that depcheck does the right thing, we will
probably set it up to start adding automatic +1 karma from 'autoqa' when
updates pass the automated test suite (depcheck and possibly other tests
- rpmlint, rpmguard, etc.). We haven't yet decided if the autokarma will
apply to all packages or just critpath packages; it may apply
everywhere, which will make it a bit easier to get to +3 karma for
automated updates.

IMHO it should not be a +1 karma but some different flag that is set for
updates that passed the tests.
Regards
Till

On Tue, Jul 06, 2010 at 11:34:25AM -0400, Will Woods wrote:
> Once we're satisfied that depcheck does the right thing, we will
> probably set it up to start adding automatic +1 karma from 'autoqa' when
> updates pass the automated test suite (depcheck and possibly other tests
> - rpmlint, rpmguard, etc.). We haven't yet decided if the autokarma will
> apply to all packages or just critpath packages; it may apply
> everywhere, which will make it a bit easier to get to +3 karma for
> automated updates.
IMHO it should not be a +1 karma but some different flag that is set for
updates that passed the tests.

Using karma is viewed as the path of least resistance to getting support
in current bodhi for this. For future bodhi yes, it makes some sense to
use some different flagging mechanism.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

On 7/6/10 8:52 AM, Till Maas wrote:
> On Tue, Jul 06, 2010 at 11:34:25AM -0400, Will Woods wrote:
>
>> Once we're satisfied that depcheck does the right thing, we will
>> probably set it up to start adding automatic +1 karma from 'autoqa'
when
>> updates pass the automated test suite (depcheck and possibly other tests
>> - rpmlint, rpmguard, etc.). We haven't yet decided if the autokarma will
>> apply to all packages or just critpath packages; it may apply
>> everywhere, which will make it a bit easier to get to +3 karma for
>> automated updates.
>
> IMHO it should not be a +1 karma but some different flag that is set for
> updates that passed the tests.
>
Using karma is viewed as the path of least resistance to getting support
in current bodhi for this. For future bodhi yes, it makes some sense to
use some different flagging mechanism.

Essentially using a different flag is just re-using the code used to
flag a package as critpath-approved only with a different name.
Therefore it should not need that much more effort.
Btw. using the "path of least resistance" to implement policy
changes seems to be what makes the new workflows suck for package
maintainers, e.g. with the change in place using a auto-karma value of 1
will become 0.
Regards
Till

Btw. using the "path of least resistance" to implement policy
changes seems to be what makes the new workflows suck for package
maintainers, e.g. with the change in place using a auto-karma value of 1
will become 0.

You're welcome to contribute some design/code to make this happen, but
we felt that it was best to get something in place to prevent the broken
deps then to wait for major changes in bodhi code base.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

On 07/06/2010 10:21 AM, Till Maas wrote:
> Essentially using a different flag is just re-using the code used to
> flag a package as critpath-approved only with a different name.
> Therefore it should not need that much more effort.
critpath approved is based on karma as well, so I'm not sure what you're
suggesting here.

I thought it is its own field in the database, because according to the
current policy it is not supposed to change once it was true. But yes,
the current implementation did not help that much here, but the patch in
the other mail shows how it can be done.
Regards
Till

On Tue, Jul 06, 2010 at 09:40:01AM -0700, Jesse Keating wrote:
> On 7/6/10 8:52 AM, Till Maas wrote:
> > IMHO it should not be a +1 karma but some different flag that is set for
> > updates that passed the tests.
>
> Using karma is viewed as the path of least resistance to getting support
> in current bodhi for this. For future bodhi yes, it makes some sense to
> use some different flagging mechanism.
Essentially using a different flag is just re-using the code used to
flag a package as critpath-approved only with a different name.
Therefore it should not need that much more effort.

Btw. using the "path of least resistance" to implement
policy
changes seems to be what makes the new workflows suck for package
maintainers, e.g. with the change in place using a auto-karma value of 1
will become 0.

Well that's only one *proposed* idea. We could just as easily have
autoqa give a comment with neutral (0) karma on updates which pass, and
-1 on failed updates, which would serve all the same purposes. That
might be a better idea, actually.
-w

On Tue, 2010-07-06 at 19:21 +0200, Till Maas wrote:
> On Tue, Jul 06, 2010 at 09:40:01AM -0700, Jesse Keating wrote:
> > On 7/6/10 8:52 AM, Till Maas wrote:
> > > IMHO it should not be a +1 karma but some different flag that is set for
> > > updates that passed the tests.
> >
> > Using karma is viewed as the path of least resistance to getting support
> > in current bodhi for this. For future bodhi yes, it makes some sense to
> > use some different flagging mechanism.
>
> Essentially using a different flag is just re-using the code used to
> flag a package as critpath-approved only with a different name.
> Therefore it should not need that much more effort.
Feel free to help write the code to prove this point!
> Btw. using the "path of least resistance" to implement policy
> changes seems to be what makes the new workflows suck for package
> maintainers, e.g. with the change in place using a auto-karma value of 1
> will become 0.
Well that's only one *proposed* idea. We could just as easily have
autoqa give a comment with neutral (0) karma on updates which pass, and
-1 on failed updates, which would serve all the same purposes. That
might be a better idea, actually.

On Tue, Jul 06, 2010 at 03:06:37PM -0400, Will Woods wrote:
> On Tue, 2010-07-06 at 19:21 +0200, Till Maas wrote:
> > On Tue, Jul 06, 2010 at 09:40:01AM -0700, Jesse Keating wrote:
> > > On 7/6/10 8:52 AM, Till Maas wrote:
> > > > IMHO it should not be a +1 karma but some different flag that is set
for
> > > > updates that passed the tests.
> > >
> > > Using karma is viewed as the path of least resistance to getting support
> > > in current bodhi for this. For future bodhi yes, it makes some sense to
> > > use some different flagging mechanism.
> >
> > Essentially using a different flag is just re-using the code used to
> > flag a package as critpath-approved only with a different name.
> > Therefore it should not need that much more effort.
>
> Feel free to help write the code to prove this point!
>
> > Btw. using the "path of least resistance" to implement policy
> > changes seems to be what makes the new workflows suck for package
> > maintainers, e.g. with the change in place using a auto-karma value of 1
> > will become 0.
>
> Well that's only one *proposed* idea. We could just as easily have
> autoqa give a comment with neutral (0) karma on updates which pass, and
> -1 on failed updates, which would serve all the same purposes. That
> might be a better idea, actually.
Using karma 0 the patch could be this one:
http://till.fedorapeople.org/tmp/0001-support-passed_autoqa.patch
Tested with:
http://0.0.0.0:8084/updates/sos-2.2-0.fc13
To make it pass autoqa run in sqlite3 /var/tmp/bodhi.sqlite
update comment set author = "autoqa" where update_id = 1435;
Instead of making it a bool, it might be also a good idea to use three
values: untested, passed, failed and in case if failed a pointer to the
test results.

Also the patch is not quite correct depending on how autoqa is supposed
to provide comments. In case it really does provide a -1 comment in case
of a broken dep, it also needs to provide a +1 comment afterwards once
the dep is fixed. This is currently not implemented. But in case autoqa
only ever adds a comment in case the update is ok, which is unlikely,
because a later update might break the deps again, then it would work.
A better documentation about what autoqa actually does would help to
write a proper patch.
Regards
Till

On Tue, Jul 06, 2010 at 03:06:37PM -0400, Will Woods wrote:
> On Tue, 2010-07-06 at 19:21 +0200, Till Maas wrote:
>> On Tue, Jul 06, 2010 at 09:40:01AM -0700, Jesse Keating wrote:
>>> On 7/6/10 8:52 AM, Till Maas wrote:
>>>> IMHO it should not be a +1 karma but some different flag that is set for
>>>> updates that passed the tests.
>>>
>>> Using karma is viewed as the path of least resistance to getting support
>>> in current bodhi for this. For future bodhi yes, it makes some sense to
>>> use some different flagging mechanism.
>>
>> Essentially using a different flag is just re-using the code used to
>> flag a package as critpath-approved only with a different name.
>> Therefore it should not need that much more effort.
>
> Feel free to help write the code to prove this point!
>
>> Btw. using the "path of least resistance" to implement policy
>> changes seems to be what makes the new workflows suck for package
>> maintainers, e.g. with the change in place using a auto-karma value of 1
>> will become 0.
>
> Well that's only one *proposed* idea. We could just as easily have
> autoqa give a comment with neutral (0) karma on updates which pass, and
> -1 on failed updates, which would serve all the same purposes. That
> might be a better idea, actually.
Using karma 0 the patch could be this one:
http://till.fedorapeople.org/tmp/0001-support-passed_autoqa.patch

This patch looks good at a first glance -- it's pretty much exactly what
I was planning to do. The only tweak that is needed is to ensure that
anonymous people can't pretend to be AutoQA:
- if comment.author == "autoqa":
+ if not comment.anonymous and comment.author == "autoqa":
This patch, along with my critpath/nofrozenrawhide/epel changes, avoid
making database schema changes to bodhi. This makes it very easy to
perform upgrades. For the TurboGears2 port of bodhi that is underway,
these flags should definitely be proper columns in the db model.
Another benefit of the TG2 port is we will be able to utilize the
SQLAlchemy migration tools, which will allow us to change the schema as
we need to, instead of hacking together these "path of least resistance"
changes.
Thank you for all of your help with Bodhi, Till. Your work is much
appreciated.
luke

This patch looks good at a first glance -- it's pretty much
exactly what
I was planning to do. The only tweak that is needed is to ensure that
anonymous people can't pretend to be AutoQA:
- if comment.author == "autoqa":
+ if not comment.anonymous and comment.author == "autoqa":

Yes, I thought about this later, too and forgot it again. But now I also
remembered a second issue. If autoqa uses -1 comments to indicate that
an update is not approved (anymore), then it must use +1 comments to
indicate that they are approved (again) to not influence the karma.

This patch, along with my critpath/nofrozenrawhide/epel changes,
avoid
making database schema changes to bodhi. This makes it very easy to
perform upgrades. For the TurboGears2 port of bodhi that is underway,
these flags should definitely be proper columns in the db model.
Another benefit of the TG2 port is we will be able to utilize the
SQLAlchemy migration tools, which will allow us to change the schema as
we need to, instead of hacking together these "path of least resistance"
changes.

How long do think it will take till the TG2 port is ready? In the git
tg2 branch there has not been any activity since February. If it is a
very long term project, it might still be useful to keep the old bodhi
code cleaner for easier maintenance.

On Tue, Jul 13, 2010 at 03:55:46PM -0400, Luke Macken wrote:
> This patch looks good at a first glance -- it's pretty much exactly what
> I was planning to do. The only tweak that is needed is to ensure that
> anonymous people can't pretend to be AutoQA:
>
> - if comment.author == "autoqa":
> + if not comment.anonymous and comment.author == "autoqa":
Yes, I thought about this later, too and forgot it again. But now I also
remembered a second issue. If autoqa uses -1 comments to indicate that
an update is not approved (anymore), then it must use +1 comments to
indicate that they are approved (again) to not influence the karma.

> This patch, along with my critpath/nofrozenrawhide/epel changes,
avoid
> making database schema changes to bodhi. This makes it very easy to
> perform upgrades. For the TurboGears2 port of bodhi that is underway,
> these flags should definitely be proper columns in the db model.
> Another benefit of the TG2 port is we will be able to utilize the
> SQLAlchemy migration tools, which will allow us to change the schema as
> we need to, instead of hacking together these "path of least resistance"
> changes.
How long do think it will take till the TG2 port is ready? In the git
tg2 branch there has not been any activity since February. If it is a
very long term project, it might still be useful to keep the old bodhi
code cleaner for easier maintenance.

I'd like to have it in beta testing phase by F14, but we'll see how that
goes.
The current tg2 branch has the entire model ported to SQLAlchemy, with a
variety of improvements, and a lot of the test suite is ported over as
well. The next step is to port the controllers & templates. I've been
holding off on doing this for little while, as I have been doing a lot
of bugfixing in the current branch, and I want to avoid having two
out-of-sync code bases. However, we're pretty much at the point where
I'm about ready to freeze the current branch and start porting the
controllers over in the very near future.
luke

Essentially using a different flag is just re-using the code used to
flag a package as critpath-approved only with a different name.
Therefore it should not need that much more effort.
Btw. using the "path of least resistance" to implement policy
changes seems to be what makes the new workflows suck for package
maintainers, e.g. with the change in place using a auto-karma value of 1
will become 0.

I'm with Till, this particular bit seems to be a hack too far. I'd say
until we can get a proper mechanism in place, the most the test should
do with current Bodhi is file a comment saying the depcheck test passed,
with 0 karma (not +1).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

Btw. using the "path of least resistance" to implement
policy
changes seems to be what makes the new workflows suck for package
maintainers, e.g. with the change in place using a auto-karma value of 1
will become 0.

That would be a good thing! It'd make all those requirements of karma 1
(which is also implied in the critpath process which needs an extra karma
point IN ADDITION TO the proventesters approval, as if a proven tester could
not be trusted :-/ ) actually bearable.
Kevin Kofler

I'll attempt to give a brief summary here. First you need to
understand
that there are three states for a package that has been built with the
hope of being pushed as an update:
* 'candidate': freshly-built packages intended for updates
* 'proposed': bodhi request filed, but not pushed live
* 'live': packages that have been pushed live by rel-eng

I first thought that
live == stable and
proposed = "in testing with request for stable" and
candidate = "pending, not in tested, not requested to become testing"?
But this does not match the remainder of this e-mail.

So. What we want to do in AutoQA is trigger a test to check
dependencies
*before* the package goes live. So we trigger our test when the request
is filed (this is the 'post-bodhi-update' hook in AutoQA, which was
merged a week or two back).
It should be obvious that the goal of the test is to examine the
proposed updates and hold back the ones whose dependencies are
inconsistent with the packages in the live repos[1]. To phrase it
slightly differently: we want to look at the set of 'proposed' updates
and pass the packages whose dependencies *are* consistent with the live
repos.

Once we're satisfied that depcheck does the right thing, we will
probably set it up to start adding automatic +1 karma from 'autoqa' when
updates pass the automated test suite (depcheck and possibly other tests
- rpmlint, rpmguard, etc.). We haven't yet decided if the autokarma will
apply to all packages or just critpath packages; it may apply
everywhere, which will make it a bit easier to get to +3 karma for
automated updates.

If I interpret the terms live, proposed and candidate as above, the +1
karma will not have any effect on autokarma, because the check is only
run after there is a request to push the updates to stable and autokarma
does not matter anymore.
But if live == testing and proposed == "pending with request to
testing", there might still dep breakage happend when not all dependent
updates are pushed to stable. Therefore it seems the test needs to run
twice, once to avoid breakage in testing and once to avoid breakage in
stable. Is this intended or do I miss something?
Regards
Till

Did you get to look at the nss-softokn situation (details of which I
sent to autoqa-devel) yet? How hard would it be to catch that?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

On Tue, 2010-07-06 at 11:34 -0400, Will Woods wrote:
> If there are any other questions, feel free to ask.
>
> -w
Did you get to look at the nss-softokn situation (details of which I
sent to autoqa-devel) yet? How hard would it be to catch that?

Yes - as I understand it, the reason the nss-softokn.i686 update didn't
land in the x86_64 updates repo was a shortcoming of mash's multilib
handling algorithm.
Since depcheck will need to run mash on the set of proposed updates in
order to correctly handle multilib cases, it should (in theory)
correctly reproduce this error and thus set off alarm bells.
I'm not sure how transparent the error messages will be, though, but at
least (again, in theory) we should get notification that Something Is
Wrong.
We'll see what happens when we actually have a test case for this[1],
though.
-w
[1] Real Soon Now, of course

The main reasons we want to perform testing are things like: to
avoid
pushing updates with broken dependencies

The right way to prevent that is to get AutoQA completed, which will, if it
works as intended, automatically detect and throw out updates with broken
dependencies without needlessly delaying all those updates which don't have
broken dependencies. Once AutoQA is completed, the testing process will do
NOTHING whatsoever to prevent broken dependencies because they wouldn't make
it through AutoQA anyway.

No amount of testing is going to catch all such cases, and when it does
happen, the testing requirements actually HINDER a quick fix, increasing the
window of exposure to the bug and therefore making it affect many more users
and for longer time.

In fact, Kevin, given a set of metrics we're both happy with,
I'd be
willing to stake my subscription to this list on it - for, say, 3
months. Are you willing to do the same?

No. Metrics just encourage working to the metric to game the system, and any
improvement you measure from the new process might just be due to chance or
to factors we aren't considering at all. Plus, do we even have the
historical data to compare with, given that everything older than F12 is
deleted from Bodhi?
Kevin Kofler

Yes I can. I have two critpath packages that are in testing with
security bugs, both pretty small and easy to test, and both still have
karma zero. That seems to me to be adequate proof that there's not the
manpower out there to do this.
The right way to go about this is to ramp up proventester manpower
*first* before making it a required gating factor. If we were at the
point where any significant fraction of packages were being auto-pushed
due to +3 karma, I would be fine with the proposed policy.
regards, tom lane

Adam Williamson <awilliam(a)redhat.com&gt; writes:
> On Wed, 2010-06-30 at 11:35 -0400, Tom Lane wrote:
>> The proposed policy might be workable if we had a surplus of
>> proventester manpower available, but we obviously have not got that.
> See above, you cannot judge this on current experience.
Yes I can. I have two critpath packages that are in testing with
security bugs, both pretty small and easy to test, and both still have
karma zero. That seems to me to be adequate proof that there's not the
manpower out there to do this.

Have you actually asked anyone to test it? Or even considered
*mentioning the names of the packages* so maybe someone here could help?
You're putting way more effort into complaining about testing being
required than it would actually take to get someone to perform the
required testing. I find this to be a poor use of your time and mine.

The right way to go about this is to ramp up proventester manpower
*first* before making it a required gating factor.

Chicken-and-egg problem. It turns out nobody does testing when it's
optional. So now it's not optional.
But take heart - if both packages are small and easy to test, surely
it'll be really easy to find someone to test them both.
-w

On Wed, 2010-06-30 at 15:04 -0400, Tom Lane wrote:
> Yes I can. I have two critpath packages that are in testing with
> security bugs, both pretty small and easy to test, and both still have
> karma zero. That seems to me to be adequate proof that there's not the
> manpower out there to do this.

Have you actually asked anyone to test it? Or even considered
*mentioning the names of the packages* so maybe someone here could help?

I mentioned libtiff in my first comment in this thread. The other one
is libpng. But in any case, are maintainers supposed to have to scare
up testers on their own? Especially for packages that are supposed to
be so central as to be critpath? If there aren't testers coming out of
the woodwork, this scheme is doomed to failure.
regards, tom lane

Will Woods <wwoods(a)redhat.com&gt; writes:
> On Wed, 2010-06-30 at 15:04 -0400, Tom Lane wrote:
>> Yes I can. I have two critpath packages that are in testing with
>> security bugs, both pretty small and easy to test, and both still have
>> karma zero. That seems to me to be adequate proof that there's not the
>> manpower out there to do this.
> Have you actually asked anyone to test it? Or even considered
> *mentioning the names of the packages* so maybe someone here could help?
I mentioned libtiff in my first comment in this thread. The other one
is libpng. But in any case, are maintainers supposed to have to scare
up testers on their own? Especially for packages that are supposed to
be so central as to be critpath? If there aren't testers coming out of
the woodwork, this scheme is doomed to failure.
regards, tom lane

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/30/2010 03:29 PM, Tom Lane wrote:
> Will Woods <wwoods(a)redhat.com&gt; writes:
>> On Wed, 2010-06-30 at 15:04 -0400, Tom Lane wrote:
>>> Yes I can. I have two critpath packages that are in testing with
>>> security bugs, both pretty small and easy to test, and both still have
>>> karma zero. That seems to me to be adequate proof that there's not the
>>> manpower out there to do this.
>
>> Have you actually asked anyone to test it? Or even considered
>> *mentioning the names of the packages* so maybe someone here could help?
>
> I mentioned libtiff in my first comment in this thread. The other one
> is libpng. But in any case, are maintainers supposed to have to scare
> up testers on their own? Especially for packages that are supposed to
> be so central as to be critpath? If there aren't testers coming out of
> the woodwork, this scheme is doomed to failure.
>
> regards, tom lane
A suggestion: when critical path updates hit updates-testing, a
notification should go to both devel(a)lists.fedoraproject.org and
qa(a)lists.fedoraproject.org to encourage testing.

I think a daily digest to test@ and qa@ would be better, I'm sure the
last thing people need is more than one extra email a day. If its a
security issue maybe an individual email would be worthwhile but even
then there's only one push a day.
Peter
Peter

A suggestion: when critical path updates hit updates-testing, a
notification should go to both devel(a)lists.fedoraproject.org and
qa(a)lists.fedoraproject.org to encourage testing.

This would probably be too high traffic. We're working on making sure
there's easy processes for the proventesters to identify and quickly
provide feedback on critpath updates. fedora-easy-karma will soon sprout
options to list only critpath updates, or only critpath updates which do
not yet have sufficient feedback; I'm talking to Till about this now.
You can already view all pending critpath updates in Bodhi's web
interface and command line client, as per Luke's initial mail.
I think the updates-testing mails that get sent daily to test list (it's
not called qa) anyway could have the information on which updates are
critpath added, for sure. Or the critpath updates could even be listed
in a separate section, at the top.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

On Wed, 2010-06-30 at 15:37 -0400, Stephen Gallagher wrote:
> A suggestion: when critical path updates hit updates-testing, a
> notification should go to both devel(a)lists.fedoraproject.org and
> qa(a)lists.fedoraproject.org to encourage testing.
This would probably be too high traffic. We're working on making sure
there's easy processes for the proventesters to identify and quickly
provide feedback on critpath updates. fedora-easy-karma will soon sprout
options to list only critpath updates, or only critpath updates which do
not yet have sufficient feedback; I'm talking to Till about this now.

Just to make sure, that this is not overseen. fedora-easy-karma will
only list the critpath updates that are currently installed, not the one
that are available. For this only these options exist:

On Wed, Jun 30, 2010 at 12:50:53PM -0700, Adam Williamson wrote:
> You can already view all pending critpath updates in Bodhi's web
> interface and command line client, as per Luke's initial mail.
But a yum enhancement or plugin to restrict e.g. update or check-update
on only critpath updates might be interesting for people only interested
in critpath testing.

On Thu, 2010-07-01 at 00:20 +0200, Till Maas wrote:
> On Wed, Jun 30, 2010 at 12:50:53PM -0700, Adam Williamson wrote:
> > You can already view all pending critpath updates in Bodhi's web
> > interface and command line client, as per Luke's initial mail.
>
> But a yum enhancement or plugin to restrict e.g. update or check-update
> on only critpath updates might be interesting for people only interested
> in critpath testing.
I thought the idea was that critpath packages would be in a critpath
group in comps?

I just looked and there are two such groups:
critical-path-base
critical-path-gnome
But how can they be used for this? From the manpage I get that e.g. yum
groupupdate critical-path-base would also install all critical-path-base
packages, but the command I was looking for is "update all installed
packages that are in the group critical-path-base". Is there a way to do
this in yum?
Regards
Till

On Thu, Jul 01, 2010 at 12:31:06AM -0400, James Antill wrote:
> I thought the idea was that critpath packages would be in a critpath
> group in comps?
I just looked and there are two such groups:
critical-path-base
critical-path-gnome
But how can they be used for this? From the manpage I get that e.g. yum
groupupdate critical-path-base would also install all critical-path-base
packages, but the command I was looking for is "update all installed
packages that are in the group critical-path-base". Is there a way to do
this in yum?

There are a couple of other things you can do now:
yum groupinfo -v critical-path\*
yum --filter-groups=critical-path\* (requires yum-filter-data plugin)

On Wed, 2010-06-30 at 15:37 -0400, Stephen Gallagher wrote:
> A suggestion: when critical path updates hit updates-testing, a
> notification should go to both devel(a)lists.fedoraproject.org and
> qa(a)lists.fedoraproject.org to encourage testing.
This would probably be too high traffic. We're working on making sure
there's easy processes for the proventesters to identify and quickly
provide feedback on critpath updates. fedora-easy-karma will soon sprout
options to list only critpath updates, or only critpath updates which do
not yet have sufficient feedback; I'm talking to Till about this now.

A suggestion: when critical path updates hit updates-testing, a
notification should go to both devel(a)lists.fedoraproject.org and
qa(a)lists.fedoraproject.org to encourage testing.

The qa-list has already lost a lot of it's readability for me because of
all the trac-mails that are now being sent there (yes - I could filter
but I'm not filtering and I notice that I'm paying less attention to the
list these days).
I would suggest not doing the same for the devel@ list. Call me
old-fashioned but I prefer my mailinglist either being filled with
human or computer generated messages - not both.
--
sven === jabber/xmpp: sven(a)lankes.net

On Wed, Jun 30, 2010 at 03:37:11PM -0400, Stephen Gallagher wrote:
> A suggestion: when critical path updates hit updates-testing, a
> notification should go to both devel(a)lists.fedoraproject.org and
> qa(a)lists.fedoraproject.org to encourage testing.
The qa-list has already lost a lot of it's readability for me because of
all the trac-mails that are now being sent there (yes - I could filter
but I'm not filtering and I notice that I'm paying less attention to the
list these days).
I would suggest not doing the same for the devel@ list. Call me
old-fashioned but I prefer my mailinglist either being filled with
human or computer generated messages - not both.

Will Woods <wwoods(a)redhat.com&gt; writes:
> On Wed, 2010-06-30 at 15:04 -0400, Tom Lane wrote:
>> Yes I can. I have two critpath packages that are in testing with
>> security bugs, both pretty small and easy to test, and both still have
>> karma zero. That seems to me to be adequate proof that there's not the
>> manpower out there to do this.
> Have you actually asked anyone to test it? Or even considered
> *mentioning the names of the packages* so maybe someone here could help?
I mentioned libtiff in my first comment in this thread. The other one
is libpng. But in any case, are maintainers supposed to have to scare
up testers on their own? Especially for packages that are supposed to
be so central as to be critpath? If there aren't testers coming out of
the woodwork, this scheme is doomed to failure.

I for one hope its effective. The recent issues with the evolution
show that its needed! The fact is that people miss things or upstream
will change things they should in a stable release that isn't
expected. Life happens. Worse case if its not is a revert of the bodhi
code that enabled it if it doesn't work.
Peter

Will Woods <wwoods(a)redhat.com&gt; writes:
> On Wed, 2010-06-30 at 15:04 -0400, Tom Lane wrote:
>> Yes I can. I have two critpath packages that are in testing with
>> security bugs, both pretty small and easy to test, and both still have
>> karma zero. That seems to me to be adequate proof that there's not the
>> manpower out there to do this.
> Have you actually asked anyone to test it? Or even considered
> *mentioning the names of the packages* so maybe someone here could help?
I mentioned libtiff in my first comment in this thread. The other one
is libpng. But in any case, are maintainers supposed to have to scare
up testers on their own? Especially for packages that are supposed to
be so central as to be critpath? If there aren't testers coming out of
the woodwork, this scheme is doomed to failure.
regards, tom lane

It worked just fine when F13 branched before F13 released. We're
putting even more resources into it now, ergo it should work just as fine.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

On 6/30/10 12:29 PM, Tom Lane wrote:
> I mentioned libtiff in my first comment in this thread. The other one
> is libpng. But in any case, are maintainers supposed to have to scare
> up testers on their own? Especially for packages that are supposed to
> be so central as to be critpath? If there aren't testers coming out of
> the woodwork, this scheme is doomed to failure.

It worked just fine when F13 branched before F13 released.
We're
putting even more resources into it now, ergo it should work just as fine.

I see that libtiff.fc13 and libpng.fc13 are now showing "critical path
approved", for which I thank those who did the work. I remain a bit
unclear about a couple of things:
1. Bodhi is showing both packages as requested push-to-stable. Which
*I* certainly didn't do, and considering they are only at +2 karma,
this means that the threshold for auto-push is actually lower than it
was before, not higher. WTF? Is the idea here to remove every last
vestige of the maintainer's judgment from the process?
2. libtiff.fc12 and libpng.fc12 are still lonely with zero karma. Is the
restrictive policy in force for F-12 too? I'm even less willing to
believe that we have enough testing manpower to cover both back branches
right away.
regards, tom lane

Jesse Keating <jkeating(a)j2solutions.net&gt; writes:
> On 6/30/10 12:29 PM, Tom Lane wrote:
>> I mentioned libtiff in my first comment in this thread. The other one
>> is libpng. But in any case, are maintainers supposed to have to scare
>> up testers on their own? Especially for packages that are supposed to
>> be so central as to be critpath? If there aren't testers coming out of
>> the woodwork, this scheme is doomed to failure.
> It worked just fine when F13 branched before F13 released. We're
> putting even more resources into it now, ergo it should work just as fine.
I see that libtiff.fc13 and libpng.fc13 are now showing "critical path
approved", for which I thank those who did the work. I remain a bit
unclear about a couple of things:
1. Bodhi is showing both packages as requested push-to-stable. Which
*I* certainly didn't do, and considering they are only at +2 karma,
this means that the threshold for auto-push is actually lower than it
was before, not higher. WTF? Is the idea here to remove every last
vestige of the maintainer's judgment from the process?

That is not the idea or intent. However since we value proventester
karma above all others, it was deemed only necessary to have one
confirming karma beyond the proventester karma. This is how things
worked throughout the F13 branched phase. There is a slight wrinkle in
that right now, the bodhi code will automatically request a push of an
item that reaches this karma threshold, and I don't believe there is a
way yet to force it to wait for even greater amounts of karma. I
believe that fine grained tuning of karma automation is planned for the
next major version (and rewrite) of bodhi.

2. libtiff.fc12 and libpng.fc12 are still lonely with zero karma. Is
the
restrictive policy in force for F-12 too? I'm even less willing to
believe that we have enough testing manpower to cover both back branches
right away.

There is a slight wrinkle in that right now, the bodhi code will
automatically request a push of an item that reaches this karma threshold,
and I don't believe there is a way yet to force it to wait for even
greater amounts of karma. I believe that fine grained tuning of karma
automation is planned for the next major version (and rewrite) of bodhi.

That's not a "slight wrinkle", that's a fatal showstopper which means
this
change should never have hit production. I consider it completely
unacceptable for my updates to get promoted to stable when I didn't request
it (e.g. I disable karma automatism for all my updates).
The way the workflow should work (*) is that:
* case 1: The maintainer requests the push to stable before the promotion is
approved. Then it will get withheld until approval. Once approval is
obtained, the push is automatically requested by Bodhi.
* case 2: The approval happens before a push to stable is requested. In that
case, the update is marked as approved and the maintainer can queue it to
stable at any time.
That's the only sane way to handle such approval, everything else is just
plain broken. (And isn't that how the security team approval works now? Why
is the proventester approval implemented differently?)
(*) under the (bad) assumption that this process makes sense at all, of
course
Kevin Kofler

Jesse Keating wrote:
> There is a slight wrinkle in that right now, the bodhi code will
> automatically request a push of an item that reaches this karma threshold,
> and I don't believe there is a way yet to force it to wait for even
> greater amounts of karma. I believe that fine grained tuning of karma
> automation is planned for the next major version (and rewrite) of bodhi.
That's not a "slight wrinkle", that's a fatal showstopper which means
this
change should never have hit production. I consider it completely
unacceptable for my updates to get promoted to stable when I didn't request
it (e.g. I disable karma automatism for all my updates).

If you disable karma automatism for your updates, they will not
automatically get promoted to stable upon critpath approval.

The way the workflow should work (*) is that:
* case 1: The maintainer requests the push to stable before the promotion is
approved. Then it will get withheld until approval. Once approval is
obtained, the push is automatically requested by Bodhi.

This is the workflow that occurs by default.
All critpath updates go to testing first, even if the maintainer chooses
stable. It's tested and approved, then bodhi automatically promotes it
to stable.

* case 2: The approval happens before a push to stable is requested.
In that
case, the update is marked as approved and the maintainer can queue it to
stable at any time.
That's the only sane way to handle such approval, everything else is just
plain broken. (And isn't that how the security team approval works now? Why
is the proventester approval implemented differently?)

On 07/01/2010 12:47 AM, Kevin Kofler wrote:
> Jesse Keating wrote:
>> There is a slight wrinkle in that right now, the bodhi code will
>> automatically request a push of an item that reaches this karma threshold,
>> and I don't believe there is a way yet to force it to wait for even
>> greater amounts of karma. I believe that fine grained tuning of karma
>> automation is planned for the next major version (and rewrite) of bodhi.
>
> That's not a "slight wrinkle", that's a fatal showstopper which
means this
> change should never have hit production. I consider it completely
> unacceptable for my updates to get promoted to stable when I didn't request
> it (e.g. I disable karma automatism for all my updates).
If you disable karma automatism for your updates, they will not
automatically get promoted to stable upon critpath approval.

It would probably be good to advertise this more prominently somewhere.
I must admit I wasn't aware we still had this wrinkle - I assumed you'd
be getting it fixed this time around - and we should definitely alert
maintainers to it.

> The way the workflow should work (*) is that:
> * case 1: The maintainer requests the push to stable before the promotion is
> approved. Then it will get withheld until approval. Once approval is
> obtained, the push is automatically requested by Bodhi.
This is the workflow that occurs by default.
All critpath updates go to testing first, even if the maintainer chooses
stable. It's tested and approved, then bodhi automatically promotes it
to stable.
> * case 2: The approval happens before a push to stable is requested. In that
> case, the update is marked as approved and the maintainer can queue it to
> stable at any time.
> That's the only sane way to handle such approval, everything else is just
> plain broken. (And isn't that how the security team approval works now? Why
> is the proventester approval implemented differently?)
This is the workflow that occurs when you disable karma automatism.

Perhaps it would surprise people less if we made case 2 default for
critpath?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

I remain a bit
unclear about a couple of things:
1. Bodhi is showing both packages as requested push-to-stable. Which
*I* certainly didn't do, and considering they are only at +2 karma,
this means that the threshold for auto-push is actually lower than it
was before, not higher. WTF? Is the idea here to remove every last
vestige of the maintainer's judgment from the process?

No. Please stop assuming everything in a negative light. ;)
This looks like a bug to me... if you didn't request stable, it
shouldn't go yet. I can talk to Luke about it, perhaps you could file a
bodhi bug on it?

2. libtiff.fc12 and libpng.fc12 are still lonely with zero karma.
Is
the restrictive policy in force for F-12 too? I'm even less willing
to believe that we have enough testing manpower to cover both back
branches right away.

Yes, it does appear to be there as well.
I am just ramping up my f12 test machine now... but yeah, it's not
clear that we intended this to go live for f12 too. ;(
kevin

On Wed, 30 Jun 2010 18:38:03 -0400
Tom Lane&lt;tgl(a)redhat.com&gt; wrote:
> I see that libtiff.fc13 and libpng.fc13 are now showing "critical path
> approved", for which I thank those who did the work.
Thanks. ;)
> I remain a bit
> unclear about a couple of things:
>
> 1. Bodhi is showing both packages as requested push-to-stable. Which
> *I* certainly didn't do, and considering they are only at +2 karma,
> this means that the threshold for auto-push is actually lower than it
> was before, not higher. WTF? Is the idea here to remove every last
> vestige of the maintainer's judgment from the process?
No. Please stop assuming everything in a negative light. ;)
This looks like a bug to me... if you didn't request stable, it
shouldn't go yet. I can talk to Luke about it, perhaps you could file a
bodhi bug on it?

There /was/ a bug with the initial release that left a small window of
time where updates would have been auto-promoted even if karma
automatism was enabled. This has since been resolved.

> 2. libtiff.fc12 and libpng.fc12 are still lonely with zero karma.
Is
> the restrictive policy in force for F-12 too? I'm even less willing
> to believe that we have enough testing manpower to cover both back
> branches right away.
Yes, it does appear to be there as well.
I am just ramping up my f12 test machine now... but yeah, it's not
clear that we intended this to go live for f12 too. ;(

It also wasn't clear that this was supposed to be for F13 only :(
Right now bodhi treats *all* critical path packages the same, across all
releases.
If we only want this policy to be in place for F13, then I'm sure I
could hack around it.
luke

Adam Williamson <awilliam(a)redhat.com&gt; writes:
> On Wed, 2010-06-30 at 11:35 -0400, Tom Lane wrote:
>> The proposed policy might be workable if we had a surplus of
>> proventester manpower available, but we obviously have not got that.
> See above, you cannot judge this on current experience.
Yes I can. I have two critpath packages that are in testing with
security bugs, both pretty small and easy to test, and both still have
karma zero. That seems to me to be adequate proof that there's not the
manpower out there to do this.
The right way to go about this is to ramp up proventester manpower
*first* before making it a required gating factor. If we were at the
point where any significant fraction of packages were being auto-pushed
due to +3 karma, I would be fine with the proposed policy.

We've been doing both together. Please see the QA mailing list archives
and meeting minutes for the last few weeks. As Will mentioned, we have a
bunch (actually 14) proventester mentor requests which we have started
to accept as of this morning, and I asked existing proventesters to
start (or start again, as they were doing it during the pre-release F13
period) proactively testing critpath updates last night.
I'd remind you that we've actually already had a period of several weeks
where this system was active - before the F13 release, when critpath
package pushes required feedback from a member of qa or releng - and
that worked out fine, the packages got pushed and we did the release.
Now we have a better process with a dedicated group and more people in
it or about to be in it and fewer pushes to handle (I'd hope so, anyway;
there should be fewer pushes for a release *after* it goes out than
*before*), so it seems unlikely it would work any worse than it did
then.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

I'd remind you that we've actually already had a period of
several weeks
where this system was active - before the F13 release, when critpath
package pushes required feedback from a member of qa or releng - and
that worked out fine, the packages got pushed and we did the release.
Now we have a better process with a dedicated group and more people in
it or about to be in it and fewer pushes to handle (I'd hope so, anyway;
there should be fewer pushes for a release *after* it goes out than
*before*), so it seems unlikely it would work any worse than it did
then.

There are actually more updates after a release, especially for critical
packages. Before the release, we try hard not to break the live images,
which cannot be fixed by post-release updates. After the release, that's not
an issue, and any small issues we introduce can just be fixed with another
update (which also means less QA is needed).
Kevin Kofler

The right way to go about this is to ramp up proventester manpower
first before making it a required gating factor.

+1
Why was this implemented BEFORE proventester requests were approved? If we
don't even have the "mentoring" process defined, then that should have
happened before enabling proventester.
And why does somebody like Rex Dieter need "mentoring" to get into
proventesters at all? He has been doing rel-eng work including approval of
freeze overrides for years. I'm sure several of the other early applicants
are also people which should be just trusted and added instead of waiting
for a vaporware process.
Kevin Kofler

Luke Macken <lmacken(a)redhat.com&gt; writes:
> Critical path package[0] updates now require positive karma from two
> proventesters[1], and a single +1 from one other community member.
Even for security updates? My experience says that this requirement
will prevent me from *ever* pushing updates. Case in point: libtiff,
which is a critpath package, has been in testing with a significant
security update for a week now. Its karma is still zero. When I get
the "old package" warning in another week, I am going to push it stable
... and if bodhi won't let me, I am going to come looking for a neck to
wring.

Refrain from making threats of bodily harm on this list. It is not warranted
or wanted.
josh

I would be willing to accept *negative* karma from more than
one proventester as being an override. But it is utterly unacceptable
for inaction to represent a veto.

I would argue that it's utterly unacceptable for untested code to be
pushed to users.
Is it really so hard for you to find someone to test the thing? If so,
maybe you could use the assistance of a co-maintainer?
-w

Is it really so hard for you to find someone to test the thing? If
so,
maybe you could use the assistance of a co-maintainer?

Huh? I don't need a co-maintainer, I need testers. proventesters,
even. Or are you suggesting that the way to deal with this is to
have two maintainers who each sign up as proventesters and then bump
the karma on their own packages? Surely that's not the way to get
more eyeballs on the problem.
regards, tom lane

Will Woods <wwoods(a)redhat.com&gt; writes:
> Is it really so hard for you to find someone to test the thing? If so,
> maybe you could use the assistance of a co-maintainer?
Huh? I don't need a co-maintainer, I need testers.

I was suggesting that - since you seem to be so loath to actually
perform the minimal effort required to find a proventester (pop into
#fedora-qa, ask on test(a)lists.fedoraproject.org, etc) - maybe you could
use a co-maintainer to handle that part of the process for you?
Also: each critpath package currently only requires one proventester,
and one karma from any other registered Fedora account. So right here on
the devel list you have hundreds of people listening who could fulfill
half the requirement, if you actually were willing to ask.
You're the maintainer of something critical to the proper functioning of
the distribution. Arguing against the necessity of even minimal software
testing really does not suit that position.
-w

Luke Macken <lmacken(a)redhat.com&gt; writes:
> Critical path package[0] updates now require positive karma from two
> proventesters[1], and a single +1 from one other community member.
Even for security updates? My experience says that this requirement
will prevent me from *ever* pushing updates. Case in point: libtiff,
which is a critpath package, has been in testing with a significant
security update for a week now. Its karma is still zero. When I get
the "old package" warning in another week, I am going to push it stable
... and if bodhi won't let me, I am going to come looking for a neck to
wring.

Checks and balances are actually quite important - even if we're not
always the biggest fans of them - especially for existing shipping
distributions. I'm a big fan of letting whatever happen before you ship,
then locking it down and making it tough to screw over systems that are
not explicitly asking to be affected by a major upgrade, etc.
There's also the "if you build it..." argument. I think if it's
actually
necessary to get these ACKs then they will happen. And in the worst
case, you probably just need to email this list/IRC/etc.
Jon.

proventesters & strict critical path update handling
----------------------------------------------------
Critical path package[0] updates now require positive karma from two
proventesters[1], and a single +1 from one other community member.

Sorry, I did not convey this correctly.
For critical path updates to be approved for pushing to the stable
repository, they now require a minimum karma of 2, consisting of a +1
from a single proventester, and a +1 from another authenticated user.
luke

For critical path updates to be approved for pushing to the stable
repository, they now require a minimum karma of 2, consisting of a +1
from a single proventester, and a +1 from another authenticated user.

I am just wondering, is this some intermediate step until the Package
update acceptance criteria[0] are implemented? Because these criteria
only say that updates "require positive Bodhi karma from a defined group
of testers", so there is no need for the +1 from another authenticated
user. Also they are about the "important packages", which is a subset of
critical path. And the policy says that it is not yet live.
Regards
Till
[0] https://fedoraproject.org/wiki/Package_update_acceptance_criteria

On Wed, Jun 30, 2010 at 02:48:26PM -0400, Luke Macken wrote:
> For critical path updates to be approved for pushing to the stable
> repository, they now require a minimum karma of 2, consisting of a +1
> from a single proventester, and a +1 from another authenticated user.
I am just wondering, is this some intermediate step until the Package
update acceptance criteria[0] are implemented? Because these criteria
only say that updates "require positive Bodhi karma from a defined group
of testers", so there is no need for the +1 from another authenticated
user. Also they are about the "important packages", which is a subset of
critical path. And the policy says that it is not yet live.
Regards
Till
[0] https://fedoraproject.org/wiki/Package_update_acceptance_criteria

I believe it's a continuation of the criteria we used for F13 branched,
which came from the No Frozen Rawhide proposals.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

On Wed, Jun 30, 2010 at 02:48:26PM -0400, Luke Macken wrote:
> For critical path updates to be approved for pushing to the stable
> repository, they now require a minimum karma of 2, consisting of a
> +1 from a single proventester, and a +1 from another authenticated
> user.
I am just wondering, is this some intermediate step until the Package
update acceptance criteria[0] are implemented? Because these criteria
only say that updates "require positive Bodhi karma from a defined
group of testers", so there is no need for the +1 from another
authenticated user.

I have clarified this. This is using the same critical path setup that
branched releases use, which is: +1 from a proventester, and +1 from
any logged in user.

>Also they are about the "important packages",
> which is a subset of critical path.
Superset. :) In any case, the items mentioned there should be
implemented. Bodhi calls them all 'critical path' so perhaps we should
change to do that there too.

Yes, superset. If the important packages and critical path packages are
the same and handled the same in any way, then the term "import
packages" should imho vanish and never be used again. The inflation of
different terms for the same thing is imho a major problem in the Fedora
docs in general. :-(

Btw. does Bodhi really work the way it is said there? What happens if
there are +1 and -1 karma values for an critpath update? According to
the criteria, -1 karma does not have any impact at all except for all
other updates, because they contain a karma threshold.
And is it possible to now set the karma threshold for other updates to 1
to get it pushed to stable once someone else gives +1 or will a +1 from
the update submitter also push the update to stable?
Regards
Till

On Fri, Jul 02, 2010 at 12:48:43PM -0600, Kevin Fenzi wrote:
> I have updated the page.
>
> Does it look clear now? Re-wording or tweaks very welcome.
>
> https://fedoraproject.org/wiki/Package_update_acceptance_criteria
Btw. does Bodhi really work the way it is said there? What happens if
there are +1 and -1 karma values for an critpath update? According to
the criteria, -1 karma does not have any impact at all except for all
other updates, because they contain a karma threshold.

On Fri, Jul 02, 2010 at 10:33:04PM +0200, Till Maas wrote:
> On Fri, Jul 02, 2010 at 12:48:43PM -0600, Kevin Fenzi wrote:
>
> > I have updated the page.
> >
> > Does it look clear now? Re-wording or tweaks very welcome.
> >
> > https://fedoraproject.org/wiki/Package_update_acceptance_criteria
>
> Btw. does Bodhi really work the way it is said there? What happens
> if there are +1 and -1 karma values for an critpath update?
> According to the criteria, -1 karma does not have any impact at all
> except for all other updates, because they contain a karma
> threshold.
Interestingly the first critpath update I saw with f-e-k is not
approved but should be according to the criteria:
https://admin.fedoraproject.org/updates/F12/FEDORA-2010-9850

It doesn't have enough karma... it got:
-1, +1, +1, for a total of 1.
So, I guess it's not going to push without hitting +2.
I've asked Luke to comment here and your parent post about how things
work, as I would love to know too. ;)
kevin

On Sat, 03 Jul 2010 19:55:27 +0200
Till Maas&lt;opensource(a)till.name&gt; wrote:
> On Fri, Jul 02, 2010 at 10:33:04PM +0200, Till Maas wrote:
>> On Fri, Jul 02, 2010 at 12:48:43PM -0600, Kevin Fenzi wrote:
>>
>>> I have updated the page.
>>>
>>> Does it look clear now? Re-wording or tweaks very welcome.
>>>
>>> https://fedoraproject.org/wiki/Package_update_acceptance_criteria
>>
>> Btw. does Bodhi really work the way it is said there? What happens
>> if there are +1 and -1 karma values for an critpath update?
>> According to the criteria, -1 karma does not have any impact at all
>> except for all other updates, because they contain a karma
>> threshold.
>
> Interestingly the first critpath update I saw with f-e-k is not
> approved but should be according to the criteria:
> https://admin.fedoraproject.org/updates/F12/FEDORA-2010-9850
It doesn't have enough karma... it got:
-1, +1, +1, for a total of 1.
So, I guess it's not going to push without hitting +2.
I've asked Luke to comment here and your parent post about how things
work, as I would love to know too. ;)

Right now for a critical path update to gain approval, it must have a
net karma of at least 2, including a +1 from a proventester, and +1 from
another authenticated user. This is the behavior that was implemented
and utilized during the No Frozen Rawhide pre-release stage of F13.
If we want to change this behavior, that's fine with me. Let's discuss
alternative solutions.
luke

> I've asked Luke to comment here and your parent post about
how things
> work, as I would love to know too. ;)
Right now for a critical path update to gain approval, it must have a
net karma of at least 2, including a +1 from a proventester, and +1 from
another authenticated user. This is the behavior that was implemented
and utilized during the No Frozen Rawhide pre-release stage of F13.
If we want to change this behavior, that's fine with me. Let's discuss
alternative solutions.

That's broadly how we already agreed it should work, at FESCo level. I
have asked FESCo to consider how to handle the case where negative karma
is provided, though. Particularly negative karma from a proven tester.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

Hi,
I just pushed a version 0.7.5 of bodhi into production. This release
contains the following notable changes:
proventesters & strict critical path update handling
----------------------------------------------------
Critical path package[0] updates now require positive karma from two
proventesters[1], and a single +1 from one other community member.
You can get a list of critical path updates using the bodhi web interface:
https://admin.fedoraproject.org/updates/critpath?release=F13untested=True
You can optionally pass in a specific 'release' or an 'untested' flag,
which will return a list of critical path updates that have yet to be
approved. I have not added these links to the main interface yet,
because at the moment they are fairly expensive calls. This will be
addressed in an upcoming release.
The latest command-line client also supports these options as well:
$ bodhi --critpath --untested --release F13

Could a flag be added to only output the package names, so that I can
pipe the output directly to yum? Or even better, have that flag
automatically cause the bodhi client to invoke yum with
--enable-repo=updates-testing with the packages required.
If we need more testers, we should automate their task as much as
humanly (or, in this case, computerly :p ) possible
Thanks,
--
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
Email: salimma(a)fedoraproject.org | GPG key ID: 78884778
Jabber: hircus(a)jabber.ccc.de | IRC: hircus(a)irc.freenode.net
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

Could a flag be added to only output the package names, so that I
can
pipe the output directly to yum? Or even better, have that flag
automatically cause the bodhi client to invoke yum with
--enable-repo=updates-testing with the packages required.

You can just install all critpath updates using:
yum groupinstall --enable-repo=\*-testing critical-path\* core
and then use f-e-k from git with --critpath-only to get only asked for
the unapproved ones.
Or if you apply this patch to bodhi:
https://fedorahosted.org/bodhi/ticket/449
Then you can use:
yum install --enable-repo=\*-testing $(bodhi 2>/dev/null --critpath --untested
--release F13 | cut -d" "
-f 2) to achieve what you want.
Also according to James Antill you can use
yum install yum-filter-data plugin and then
yum --filter-groups=critical-path\* --filter-groups=core update
to install only the critpath updates that update packages on your
system. But I did not yet test this. And I do not know how the two
--filter-groups arguments behave, but unluckily "core" is currently a
critical path comps group according to
https://fedoraproject.org/wiki/Critical_Path_Packages_Proposal#When_and_h...
:-/
I objected to this on the Talk page, so hopefully this will change.
Regards
Till

On Sun, Jul 04, 2010 at 01:32:16AM +0200, Michel Alexandre Salim
wrote:
> Could a flag be added to only output the package names, so that I can
> pipe the output directly to yum? Or even better, have that flag
> automatically cause the bodhi client to invoke yum with
> --enable-repo=updates-testing with the packages required.
You can just install all critpath updates using:
yum groupinstall --enable-repo=\*-testing critical-path\* core
and then use f-e-k from git with --critpath-only to get only asked for
the unapproved ones.

Ah! Would be great if this is listed on the QA page.
Thanks,
--
Michel

On Sun, Jul 4, 2010 at 10:34 AM, Till Maas
<opensource(a)till.name&gt; wrote:
> On Sun, Jul 04, 2010 at 01:32:16AM +0200, Michel Alexandre Salim wrote:
>
>> Could a flag be added to only output the package names, so that I can
>> pipe the output directly to yum? Or even better, have that flag
>> automatically cause the bodhi client to invoke yum with
>> --enable-repo=updates-testing with the packages required.
>
> You can just install all critpath updates using:
>
> yum groupinstall --enable-repo=\*-testing critical-path\* core
>
> and then use f-e-k from git with --critpath-only to get only asked for
> the unapproved ones.
Ah! Would be great if this is listed on the QA page.

If you know on which page it fits, just add it. I did not find a
matching page when I swept through the QA pages.
Regards
Till

On Sun, Jul 04, 2010 at 12:34:59PM +0200, Michel Alexandre Salim
wrote:
> On Sun, Jul 4, 2010 at 10:34 AM, Till Maas <opensource(a)till.name&gt; wrote:
> > On Sun, Jul 04, 2010 at 01:32:16AM +0200, Michel Alexandre Salim wrote:
> >
> >> Could a flag be added to only output the package names, so that I can
> >> pipe the output directly to yum? Or even better, have that flag
> >> automatically cause the bodhi client to invoke yum with
> >> --enable-repo=updates-testing with the packages required.
> >
> > You can just install all critpath updates using:
> >
> > yum groupinstall --enable-repo=\*-testing critical-path\* core
> >
> > and then use f-e-k from git with --critpath-only to get only asked for
> > the unapproved ones.
> Ah! Would be great if this is listed on the QA page.
If you know on which page it fits, just add it. I did not find a
matching page when I swept through the QA pages.

On Sun, Jul 4, 2010 at 1:27 PM, Till Maas
<opensource(a)till.name&gt; wrote:
> On Sun, Jul 04, 2010 at 12:34:59PM +0200, Michel Alexandre Salim wrote:
>> On Sun, Jul 4, 2010 at 10:34 AM, Till Maas <opensource(a)till.name&gt; wrote:
>> > On Sun, Jul 04, 2010 at 01:32:16AM +0200, Michel Alexandre Salim wrote:
>> >
>> >> Could a flag be added to only output the package names, so that I can
>> >> pipe the output directly to yum? Or even better, have that flag
>> >> automatically cause the bodhi client to invoke yum with
>> >> --enable-repo=updates-testing with the packages required.
>> >
>> > You can just install all critpath updates using:
>> >
>> > yum groupinstall --enable-repo=\*-testing critical-path\* core
>> >
>> > and then use f-e-k from git with --critpath-only to get only asked for
>> > the unapproved ones.
>> Ah! Would be great if this is listed on the QA page.
>
> If you know on which page it fits, just add it. I did not find a
> matching page when I swept through the QA pages.
>
I don't -- Adam Williamson probably knows better. Adam?

We have a page with general instructions for testing stuff in
updates-testing:
https://fedoraproject.org/wiki/QA/Updates_Testing
and also a page of instructions for proven testers:
https://fedoraproject.org/wiki/Proven_tester
This is info that's probably useful for both, really. I certainly
intended to extend the proven_tester page with instructions on the new
functionality in f-e-k, as soon as it's available in a released f-e-k
version (I really don't want to be bothering proventesters with
suggestions to check their f-e-k out of git, so it'd be nice to have a
new version pushed with the new features). We could certainly add the
info on using yum to *install* only critpath updates too.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net