On 12/12/2009 3:04 PM, Oswald Buddenhagen wrote: > On Sat, Dec 12, 2009 at 02:46:46PM -0500, Jeff Mitchell wrote: >> On 12/12/2009 1:48 PM, Oswald Buddenhagen wrote: >>> On Sat, Dec 12, 2009 at 07:12:13PM +0100, Thomas Zander wrote: >>>> On Saturday 12. December 2009 19.02.14 Oswald Buddenhagen wrote: >>>>> Whoopsie! Looks like this project has chosen to restrict commit >>>>> access. >>>>> >>>> Then it would not be a kde-developers project. >>>> >>> well, actually, most likely it would. the hook would allow >>> foo-developers through without a question, while kde-developers >>> would get the blurb. after all, the restricted group still needs the >>> ability to force a push, and kde-developers is just perfect for >>> that. >> >> But why? I honestly don't understand it. Why, if the fix needs to go >> in, couldn't the kde-developer person simply submit a merge request to >> foo-developers? Isn't that kind of the point? >> > the concept simply has to have a "backdoor", otherwise there is no way > it would be accepted by the kde community.
Heh, it's not often you see people that are describing backdoors as good things. > heck, i myself would refuse > it otherwise. after all, the ability to quickly fix compilation (and not > have everyone do the same until a maintainer does it) is one of the "key > features" of the "kde way" of handling the repository. But but but...which repositories are these that you're talking about which are both restricted *and* essential to compilation? We're talking about keeping things the "kde way" which means +kde-developers has access to everything. Only a few things are currently restricted, like www -- but that's not essential to compilation, and indeed I'm sure it's a matter of normal policy that you check the site after you commit to it. So exactly where does one need these backdoors, how is it a "key feature" to have such a backdoor, what are real use-case examples where we might hit something super time-critical if there are no such backdoors, and why isn't it enough to have a responsive kde-sysadmin team (which could be a larger team than those that have access to e.g. our servers) that can grant temporary exemptions to these normally restricted repositories? > we have that problem only for acl-protected areas, which are a few. > i'm proposing a "soft acl" to be able to have more acls without > disturbing legitimate exceptional workflows too much. Where is this needed? --Jeff
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
