Pipes3.0 maybe Threads3.0

[David Henningsson]

Dmitrijs Ledkovs wrote:
> To achive this we will use a read/write content filter to show
> debian/patches directory. The content filter will export each
> patch-pipe as quilt series into debian/patches. So that you can invoke
> bzr-bd using current state & generating original tarballs from the
> shelved packaging branch.
> 
> 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.

I'm not into the details of this proposal, so just a layman's question:

How does this contribute to the complexity of the packaging work as a
whole? While I see that it fills a gap where things are not working
optimally today, I'm also curious if this will be one more thing to
learn to do packaging right, and one more thing to troubleshoot when
things go wrong? And if it is, are there any plans or thoughts of how to
minimize that trouble?

Will it increase the time taken to build a package?

While Ubuntu itself is striving towards becoming more "light", I
sometimes fear that its packaging system is becoming more heavyweight,
at least it is not becoming lighter. Do you agree?

That said, I think the idea of transformation between bazaar pipes and
quilt patches is most interesting, since it removes one layer of
indirection, compared to having a quilt patch inside a bzr commit.

// David