Kevin Kofler | 1 Jul 2010 06:23
Picon

Re: Bodhi 0.7.5 release

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

Why two? The policy FESCo voted said one (plus one other community member, 
giving a total karma of 2).

        Kevin Kofler

--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

James Antill | 1 Jul 2010 06:25
Favicon

Re: How to lure me to updates-testing

 Some of these require yum/yum-utils from rawhide...

On Wed, 2010-06-30 at 14:59 -0600, Nathanael Noblet wrote:

> #1) Easy way to know where a package came from.
> 
> 	For example, as far as I am aware, I cannot query anything that tells
> me X packages are from Y repo. If I were to become a 100% always
> enabled updates-testing, most of my packages would be from that repo,
> however if I only do it occasionally I'd just have to remember

 If you just want a summary, you can do (depending on what you want to
know):

 repoquery --installed -a --qf '%{ui_from_repo}' | sort | uniq -c
 repoquery --installed -a --qf '%{yumdb_info.from_repo}' | sort | uniq -c

...or the easier to type/remember but maybe less likely what you want:

 yum version -v nogroups

...if you could give us a better idea of what you are trying to do we
might be able to make something more usable.

> #2 ) Easy way to downgrade if I were to run into problems
> 
> 	I understand that this isn't foolproof, and that for some issues (some huge glibc error) my system could
conceivably require advanced knowledge to boot into a rescue mode, download packages and force the
downgrade. However some way to view the updates-testing packages I have installed, and downgrade to the
'released' version would be awesome.
(Continue reading)

Kevin Kofler | 1 Jul 2010 06:29
Picon

Re: Bodhi 0.7.5 release

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.

        Kevin Kofler

--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

James Antill | 1 Jul 2010 06:31
Favicon

Re: Bodhi 0.7.5 release

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?

-- 
James Antill - james <at> fedoraproject.org
http://yum.baseurl.org/wiki/whatsnew/3.2.28
http://yum.baseurl.org/wiki/YumBenchmarks
http://yum.baseurl.org/wiki/YumHistory
--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Dave Airlie | 1 Jul 2010 06:34
Picon
Favicon

Re: Bodhi 0.7.5 release

On Thu, 2010-07-01 at 06:29 +0200, Kevin Kofler wrote:
> 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.

--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

(Continue reading)

Kevin Kofler | 1 Jul 2010 06:33
Picon

Re: Bodhi 0.7.5 release

Jesse Keating wrote:
> 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

--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Kevin Kofler | 1 Jul 2010 06:37
Picon

Re: Bodhi 0.7.5 release

Adam Williamson wrote:
> 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

--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Kevin Kofler | 1 Jul 2010 06:47
Picon

Re: Bodhi 0.7.5 release

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

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

--

-- 
devel mailing list
(Continue reading)

Kevin Kofler | 1 Jul 2010 06:52
Picon

Re: Bodhi 0.7.5 release

Tom Lane wrote:
> 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

--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Kevin Kofler | 1 Jul 2010 06:55
Picon

Re: Bodhi 0.7.5 release

I wrote:
> Why two? The policy FESCo voted said one (plus one other community member,
> giving a total karma of 2).

Nevermind, I just noticed the later mail from Luke correcting this.

        Kevin Kofler

--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Gmane