Pipes3.0 maybe Threads3.0

[James Westby]

On Mon, 29 Mar 2010 23:32:19 +0100, Dmitrijs Ledkovs <dmitrij.ledkov at gmail.com> 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