Process Change: Package Reviews with Flags

Jesse Keating jkeating at redhat.com
Wed Feb 7 18:18:19 UTC 2007


On Wednesday 07 February 2007 11:12, Dominik 'Rathann' Mierzejewski wrote:
> That won't happen THAT easily. Isn't the sign-and-push process manual?
> Aren't the people who handle it supposed to check what they sign?

It's only manual because it was chosen to be.  We could either A) go the route 
that Core does now and not sign development packages, or B) introduce a 
signing server that can sign anything that falls out of the build system.  
Core pushes to rawhide were 100% automated, just a cron job.  There is no 
reason why Extras couldn't have been for rawhide too, and once we merge, we 
should make that change so that development as a whole automatically lands 
every night.

> > or even worse, insert some small thing in a package that gets pulled into
> > most buildroots that will further taint any more builds.  Could be hard
> > to detect until it is far far too late.
>
> It would be stopped at the sign-and-push stage at worst. I'm sure there are
> many eyes following the cvs commits list. It would be spotted quite fast
> IMHO.

You can prevent messages from being posted to cvs commits.

> >  With proper barriers in place,
> > the most damage a rouge user can do is to their own
> > package, or to any packages foolishly left wide open.
>
> I don't really mind the ACLs as much as I do mind having to go through
> another approval (for CVS import) after my package has ALREADY been
> APPROVED.

You don't.  Once your package is approved, appropriate people are notified and 
setup the location so that you can do your import and build.  What is so 
difficult about this?

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20070207/f7061938/attachment.sig>


More information about the Fedora-maintainers mailing list