changes are still needed

[Eric Rostetter]

Quoting Pekka Savola <pekkas at netcore.fi>:

> It would be interesting to hear what others think the direction should
> be.  If you think "just pick a direction, I don't care which", stating
> so wouldn't hurt either.

Warren Togami once said (see
http://www.redhat.com/archives/fedora-legacy-list/2003-November/msg00025.html
for details):

> fedora.us and I believe Legacy should REFUSE to publish anything that
> has not been thoroughly checked by more than one trusted person.  This
> is especially important for Legacy because far fewer people would be
> doing quality assurance and real world testing.

And I have to say, I feel we should stick with this.

He also later said (see
http://www.redhat.com/archives/fedora-legacy-list/2004-January/msg00365.html
for details):

>> C) How can we verify that the tester is really testing the package? 
>
> That is why multiple testers are needed. One of the testers should be the
> packager of course. People that have submitted good testing results and
> especially found ERRORS in the past are to be trusted more than new people.
>
>> D) Since we release the package across multiple releases, how long do we
>> wait on a specific release to be tested before releasing the rest of the
>> packages?
>
> Use best judgement. Wait for enough clearsigned feedback based upon the
> importance of a package to avoid regressions. Something like apache would need 
> far more testing than something like screen. But NEVER push it too soon.

and no on to the question at hand:

> Purely from the administrative perspective, IMHO, the package creator
> must not give PUBLISH or VERIFY votes, though such can be implicit.

I know it was discussed on list and stated that the package creator 
*may* vote, though I can't find the reference to it.  And if you read
Warren's quotes above, you can see he clearly accounts for the creator
to be able to vote.  So, past history says that yes, the creator can
vote.

> There is too much conflict of interest there, so recusing is IMHO the
> only option.

Well, if you say it only takes one vote, then I agree.  Otherwise, I
disagree.  We have two few people working on the project to eliminate
anyone.

> I'm OK with either approach, but I'd prefer a) with the interpretation
> that the creator does not do formal QA (so if you'd always count that
> as one, it would be equivalent to what you're thinking).

This would be a change of policy we'd have to bring up and get consensus on.

> As stated above, I don't think we should recommend (or even allow) the
> package creator doing QA for his/her own packages.  That's the other
> people's job, and ensures the logical separation of functions.

But historically we have allowed this, and no one has yet approved a 
change to that.
 
> Of course, we could assume that most package creators do test the
> packages they create, and implicitly include that here (i.e., require
> just one "external" verify vote to approve a package after a timeout).

See above statements by Warren, which agree with my own opinions.
 
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list
> 


-- 
Eric Rostetter