governance, fesco, board, etc.

[Ralf Corsepius]

On Thu, 2007-06-14 at 09:23 -0400, Jesse Keating wrote:
> On Thursday 14 June 2007 08:01:37 Ralf Corsepius wrote:
> > > I have to call BS on this one.
> >
> > Ask yourself. Is anything about this really working?
> 
> Yes, for many things and many cases things are working quite well.  There are 
> some rough spots, nobody is saying it's perfect, but to say that it's 
> completely non-functional is just bologna.
Then let me ask directly: How could it happen that this kernel package
was released?

My interpretation of this incident: "system failure".
Whatever this system is - be it automatic, be it human.

IMO, EVR breakages and repo inconsistency are avoidable and would expect
Michael to have scripts for this.

> > Yesterday, I found a bug in your new mock release candidate ... and
> > wanted to reject this package of yours in bodhi, but I could not find
> > any means to reject this package (seemingly pending something I presume
> > to be a release queue).
> 
> FESCo / QA / rel-eng has yet to create/approve any reasonable guidance for 
> updates.  There are many like /you/ that would prefer there were no 
> roadblocks whatsoever and maintainers would be allowed to push whatever they 
> want whenever they want. 

Sorry, I've always said I would like to see "automatic EVR consistency
checks", maintainers to be equipped with means to "push releases" ("make
release") and means to withdraw freshly built packages.

I've also never questioned the usefulness of "a (public) package release
candidate queue", as a means to equip people with means to
check/review/test/approve/reject/withdraw packages (comprising
maintainers approving their own packages and maintainers to reject their
own packages == withdraw packages).

I am questioning the current implementation and the usefulness of a
"testing group", that's correct.

>  And yet now you're looking for a way to /stop/ an update?
Yes, when a package is obviously malfunctioning like in this case?

Isn't checking/testing, approval/withdrawal the core of testing?
I thought this was the primary objective of the "testing" repos, the
"testing group", bodhi and the changes to the workflow?

> Why don't you help us figure out what a reasonable work flow is for creating 
> update candidates, getting them into testing

I would expect a successful "make build" to automatically push a package
into "testing".

Then some sort of "review" should take place, until either a timeout
happens or somebody (e.g. the package's maintainer) "approves/rejects" a
package ("make release")

A package then would enter a release queue, where some further automated
rpm/packaging inspections and "repo state after push" checks, such as
automatic EVR consistence checks, should take place. 

If a "set of package to be pushed" passes them, this set would be pushed
(either manually or automatically, e.g. periodically).

> (the mock you tested wasn't even
> released to updates-testing yet, you snaked it from CVS),

Right, I picked it up from CVS and rebuilt it locally, because the
current FC7 mock doesn't work for me and was looking for an escape.

Given all the attention bodhi currently has and you having closed the PR
I was waiting for to be fixed, I first looked into bodhi, expecting to
find a "fixed package".

bodhi listed a particular version as update candidate, but I could not
find an option to download the package. I then looked into the "testing"
repo and could not find the package. 

In the end, I resorted to one of the "usual escapes" to work-around
unfixed "fixed rawhide/upstream bugs": Picking a package up from CVS.
After testing this version I informed you through bugzilla that this
versions also doesn't work for me.

My conclusion in this case: The effective situation didn't change with
bodhi.

Ralf