Pipes3.0 maybe Threads3.0

[Dmitrijs Ledkovs]

(again inline but trimmed)

On 29 March 2010 22:47, James Westby <jw+debian at jameswestby.net> wrote:
> On Sat, 27 Mar 2010 00:43:26 +0000, Dmitrijs Ledkovs <dmitrij.ledkov at gmail.com> wrote:
>>
>> == Assumptions ==
>>
>> Spec does not include multiple tarballs format.
>
> Yes, these are tricky to deal with, so I'm happy to defer including them
> in this until we have an idea of how to handle them.
>

When we will have nested trees everything will be fine ;-)

>>
>> So for example you are MOTU (Master Of The Unseeded) and need to do a
>> complex merge with 10 patches. You would grab  lp:ubuntu/$package.
>> Reveal it from the base revision. Import new debian revisions from
>> lp:debian/$package in revealed state. Do a bzr pump resolving
>> conflicts. Do a build, do testing. Fold the revealed state into
>> lp:ubuntu/$package which will become a single commit/tag, mark
>> uploaded and push to launchad for building.
>
>
> Interesting approach.
>
> Do you think there is a benefit to providing a command to reveal the
> patches, rather than making lp:$distro/* use the revealed structure?
>

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 ;-)

> It certainly sounds like you have some good ideas for implementing some
> of the tricky bits.
>

Thanks. Recent rumblings on Debian/Ubuntu planet got me thinking.
Initial wiki history was far less pretty ;-)

>> Stage 2
>>
>> Add a new read & write content filter for '''debian/patches'''. Such
>> that when you switch to debian pipe and all patches magically are
>> refreshed. Removing a patch should remove pipe & vice-versa.
>
> Is this so that people can manipulate the debian/patches somewhat rather
> than manipulating the pipes?
>

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

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.

>
> 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.

> 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.

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

>> == GSoC2010 ==
>>
>> Potentially my 3rd GSoC 2010 proposal. See
>> [[DmitrijsLedkovs/GSoC2010]] and [[DmitrijsLedkovs/CadieSpec]]. Would
>> you mentor this?
>
> Of course :-) I'd love to see someone taking on this problem, while I
> think there's still plenty to talk about having something to evaluate
> would be great.
>

Thanks a lot of comments. I will move to appropriate place such that
at least this stub ideas are not lost ;-)