On Wednesday, February 17, 2016 05:34:12 PM Stanislav Ochotnicky wrote: > On Wed 17 Feb 2016 04:30:56 PM CET Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > On Wed, 17 Feb 2016 12:11:09 +0100 > > > > Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote: > >> Good morning everyone, > > > > ...snip plan to switch to async service from gitolite... > > > >> One question though, looking at our current setup, we allow people to > >> create their own branch, and not to delete it, right? > >> I am curious if anyone can create a branch on a package, I'm not > >> seeing something in the gitolite repo that would prevent me from > >> creating a branch on a package I don't maintain (assuming I am not > >> provenpackager), but maybe I've missed it. > > > > Right. Currently we allow anyone with commits to make branches, but > > then they don't have permissions to ever remove them. This is because > > we don't have a way to tell koji to only do official builds from > > specific known branches. If we could be sure that our official builds > > never get made from branches that get deleted we could I think allow > > anyone with commits to create and delete branches. > > > > It might be nice if we could fix this as part of this change. ;) > > I wonder if this is even required - even if someone *did* build official > build and then removed the branch you still have srpm after all. The > interesting content is all there I believe. You have the sources yes > It might be easier to do a verification on release/update if that hash > still exists (if really required) However people can not verify that that srpm is what is in git. Also disaster recovery senario that we lose the srpm we can recover it. Maybe being able to estable trust back to git and lookaside caache is not as important anymore. But I doubt it. You lose the abilty to even attempt to make a build reproducable if the git hash goes away. The issue we have is that we have no way to ensure that removing a branch does not remove a commit that was used in a build. We need to have that commit to reproduce a build. Dennis
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
