also sprach Manoj Srivastava <[EMAIL PROTECTED]> [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 <[EMAIL PROTECTED]> : :' : 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
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
