On Mon, 29 Mar 2010 23:32:19 +0100, Dmitrijs Ledkovs <[email protected]> wrote: > When we will have nested trees everything will be fine ;-)
Yes, they are certainly part of the problem I think. > 1) If lp branches are in the revealed structure we are loosing > compatability with debian. Right now you can browse Logerhead view and > ever single debian maintainer will understand what's going on. Even > hard-core tool-chain maintainers we don't depend on dh at all =) > > 2) Storing in revealed structure will make it harder to move around & > host elsewhere. Eg. people with bzr without any plugins. (looms & > pipelines & buildeb are all optional and not shipped with bzr) > > 3) By having revealed state locally, I can rewrite it as much as > possible until I like what I see ;-) These are good arguments. I think it makes it harder to collaborate on work in progress, but perhaps that's a reasonable trade-off. You haven't convinced me, but you've at least shifted my opinion :-) > The content filter was so that you don't have to re-export patches > after you have edited it in a pipe and came back to the top packaging > pipe such that you can envoke bzr-builddeb Right, I like that. > You can edit debian/patches in regular mode and go between releaved > <-> colapsed states if you want to switch between editing by hand & > via pipes. > > In the revealed mode changing the order of patches in the series file > will instantly make pipes history inconsistent which was just created. > So no you can't edit debian/patches directly with editor, you have to > commit to pipe. > > > Do you think it would confuse some people in to e.g. losing work as they > > think they can just alter that patch and be done? > > > > Good point. > In revealed state add debian/patches/WARNING-DO-NOT-EDIT with help > text? Make debian/patches non-writable? Drop people into subshell with > cool modeline showing pipliene status? Have a notify-osd pop-up to > reminde them? > > Needs work. Indeed. > > > > Right, so you don't want to rewrite? > > > > At this stage each time you reveal you are creating history and can do > it locally as many times as you like until you make this plugin work > ;-) > When we are ready, we can rewrite, It will work best for 3.0 quilt > packages cause we want to store the branch in patched state. > And if we rewrite history we would be better off rewriting on top of > vcs-imports. > > So my answer is maybe / later. Sounds reasonable. > > In all the talk so far the opinion has been that we would just make > > lp:$distro/* a loom that would provide this without the extra step. > > > > Ok. Chicken & Egg problem between: looms are used <--> logerhead & > merge proposals work with looms. Good point. > I haven't used looms yet. And pipes are far more stable imho cause > it's just lightweigth checkouts with UI on top. Plus some parts of > this spec will be useful even without whole reveal mechanism eg. quilt > patch series import-export to from pipes of a single commit vs Yep. pipes work fine for this use case, but don't currently support the use-case of making lp:ubuntu/* in to the revealed state, which is why looms have been spoken about more for this task. > Thanks a lot of comments. I will move to appropriate place such that > at least this stub ideas are not lost ;-) Thanks, James -- ubuntu-distributed-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
