also sprach Manoj Srivastava <srivasta@debian.org> [2008.02.29.2153 +0100]:
> 3) I propose ./debian/branches/{TopicA,TopicB,TopicC}.diff.gz
> files. Each diff, applied to the orig.tar.gz , shall recreate for
> the interested user the corresponding branch in my development.
>
> Bingo. With this addition, every user that want to see where the
> integration branch comes from can examine each topic patch or topic
> branch. Each of these topic branches can then be compiled and
> experimented with. Upstream can incorporate each of these topic
> patches, if they wish.
... until I want to play with two branches at the same time, or
upstream wants to pull two branches. Now you are forcing users to
deal with potential conflicts.
> The downside, of course, is shipping the same patch twice, once
> in the diff.gz, and once in ./debian/branches/*.diff.gz.
I don't see the added value in your approach. I don't see the use
case. I know your workflow and note how this is a continuation
thereof, but I can't identify the benefit to others and the project
in doing this. Do you really think there are many people or
upstreams who want pristine feature branches without being able to
use the net? Why wouldn't these people be helped with a quilt
series? They just want to work on feature B, do you think they
actually care that quilt first pops A before it applies B,
especially with tools like interdiff around?
Can you try to quantify?
--
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
"good advice is something a man gives
when he is too old to set a bad example.
-- la rouchefoucauld
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)