| ricotz | hi, I think there are some x86 builders stuck in "Cleaning" | 10:50 |
|---|---|---|
| cjwatson | Investigating | 11:31 |
| cjwatson | ricotz: Should mostly be back but I'm keeping an eye on it | 11:36 |
| ricotz | cjwatson, thank you | 11:38 |
| rbalint | hi, can i mark a bzr repo read-only for everyone while keeping it in the same owner group? | 17:42 |
| rbalint | i'd like to keep bzr repositories available after migrating them to git | 17:42 |
| cjwatson | I don't think that's possible | 17:54 |
| nacc | rbalint: do you have to keep the same owner group? | 18:03 |
| nacc | seems like that's the easiest solution (changing the owner group so no one has write permission) | 18:03 |
| rbalint | nacc, well, if i change the owner group ther url changes too, isn't it? | 19:49 |
| nacc | rbalint: i'm not super familiar with the bzr format; in my mind, it was under a project, which it was still under | 19:51 |
| nacc | rbalint: if that's not true, then you're probably right :) | 19:51 |
| rbalint | i would like to preserve this branch for example: https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/bionic-proposed | 19:54 |
| rbalint | nacc, i'm not super familiar with the lp side, thus i'm not sure :-) | 19:55 |
| nacc | rbalint: ah i see ... hrm, i'm not sure either, sorry! in that case, i think you're right the repository would 'move' | 19:56 |
| rbalint | nacc, could somehow lp admins put a read-only acl on the branches? | 20:08 |
| nacc | rbalint: that i don't know | 20:08 |
| juliank | Seems like I don't have a launchpad branch on my laptop, hmm | 20:11 |
| juliank | I guess the question is what it would take to mark a branch (or a project) as non-writable | 20:12 |
| teward | is there even a read-only-branch mechanism for bzr? | 20:14 |
| teward | (not sure that even exists) | 20:14 |
| juliank | teward: well, there is obviously a way to prevent users from pushing to branches they dont own | 20:14 |
| juliank | wherever that is we basically need a check if repo is in blacklist and then produce the same error | 20:15 |
| juliank | maybe s/blacklist/attribute on branch/ | 20:16 |
| juliank | and an API call to set it | 20:16 |
| nacc | right but that's probably just built-in to bzr, no? so you'd need a source-level change possibly to bzr to understand that? (speaking totally hand-wavily) | 20:16 |
| nacc | but yes, i agree in general :) I'd file a bug, personally, against LP itself and discuss it there :) | 20:16 |
| juliank | i don't think so | 20:16 |
| juliank | launchpad implements the whole sftp bzr layer itself afaics | 20:17 |
| nacc | oh i didn't know that | 20:17 |
| juliank | that's lip.lp.codehosting and probably something else I can't find on the web interface | 20:18 |
| juliank | though, if it is just files stored on a file system, maybe somebody could go in and chattr +i them | 20:20 |
| juliank | after the mass transitions are done | 20:20 |
| juliank | are mirrored repos read-only? | 20:23 |
| * juliank looking for hacks | 20:24 | |
| cjwatson | We will certainly not be perpetrating that kind of hack. | 21:36 |
| cjwatson | Everyone else just makes a final commit replacing the branch content with a pointer to the new location. | 21:37 |
| cjwatson | It would be possible and relatively non-hacky to have a read-only attribute, but I'm not convinced it's worth the effort. | 21:38 |
| cjwatson | (You can do it for cases where the old location was git by using the newish per-branch permissions feature.) | 21:39 |
| rbalint | cjwatson, i think the final commit with the pointer does not look particularly good, at least in the cases i saw, for example in https://bazaar.launchpad.net/~ubuntu-desktop/gdm/ubuntu/files | 21:57 |
| rbalint | cjwatson, setting the description to a pointer of the branch and freezing the content would be more appealing imo, and if it is not a huge effort to implement freezing then it may worth it | 22:00 |
| cjwatson | It's a moderate amount of effort on a part of the codebase we largely try to avoid touching nowadays and don't have any effort allocated to it. Your argument is really just cosmetics. | 22:07 |
| cjwatson | So it's going to be hard for that to justify actual engineering time IMO. | 22:07 |
| cjwatson | (IOW I doubt the engineering time spent on implementing that feature would ever be made up for by savings elsewhere.) | 22:08 |
| cjwatson | I mean, you can take it over my head if you like, but my opinion at the moment is that it isn't worth it. | 22:09 |
| cjwatson | If somebody else wants to do the work; maybe. The necessary changes would be in the Branch interface and database model (whether it should be a basic owner-settable read-only flag or something more sophisticated, I'm not sure), probably a bit of UI to set it, and in lp.code.xmlrpc.codehosting to handle it at push time. | 22:14 |
| cjwatson | lp.code.xmlrpc.codehosting and its corresponding tentacles in codehosting itself are fairly confusingly laid out (especially the latter). When I was doing the git equivalent on the webapp side I used it for general inspiration but tried to make it a good deal clearer ... | 22:16 |
| rbalint | cjwatson, thanks for the pointers! | 22:53 |
| rbalint | cjwatson, i started cloning lp's code a few minutes ago but it is still running thus i'm not diving into it today :-) | 22:55 |
| wgrant | rbalint: But if you leave the old content in place then nobody will realise they're branching an ancient version of the code. | 23:34 |
| wgrant | Replacing the code with a pointer that is ugly is a feature, not a bug. | 23:34 |
| rbalint | wgrant, i set the migrated branches as merged and updated their description to have the pointer like https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/bionic-proposed , but imo that would be a good argument for for fixing this in lp | 23:36 |
| wgrant | rbalint: On what basis? | 23:37 |
| wgrant | Nobody looks at the branch page | 23:37 |
| wgrant | The bigger problem is pulls, not pushes. | 23:37 |
| rbalint | where are people looking for the branches then? | 23:38 |
| wgrant | rbalint: "bzr pull" in my local checkout | 23:38 |
| rbalint | how many people are out there who don't know about the migration of the repositories they are actively contributing to? | 23:41 |
| rbalint | how is that different than merging a bzr repository to an other one and continuing development there? | 23:43 |
| rbalint | wgrant, but i get back to foundations and discuss if we want to follow desktop team's practice of replacing the tip of a pointer four our branches | 23:45 |
| wgrant | You do want to do that. | 23:45 |
| cjwatson | I contribute to lots of projects on an occasional basis where I wouldn't notice if they moved their repositories around until I tried to do something to them. | 23:47 |
| cjwatson | And it's not different from moving a bzr repository to another one; people often did the same "replace with a pointer" trick for that. (Though sometimes they just made the old location stop existing, which doesn't tell people what to do but is better than leaving it in place and silently stale.) | 23:48 |
| rbalint | in my possibly biased experience with packages i found that i have to check if the repo is up to date with the archive before basing my change on it because the archive can have much newer code | 23:57 |
| cjwatson | I don't think that contradicts me. | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!