[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Upstreaming patches [Was: RFC: upstreaming debian/patches/exec_filen

From: Zhang Cong
Subject: Re: Upstreaming patches [Was: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff]
Date: Mon, 7 Apr 2014 19:32:57 +0800

On Mon, Apr 7, 2014 at 5:31 PM, Samuel Thibault <samuel.thibault@gnu.org> wrote:
Zhang Cong, le Mon 07 Apr 2014 17:25:34 +0800, a écrit :
> The one who do this  need have the full plan,

I don't see why one would need a full plan.  A patch deals with just
part of the code, you don't need to know *all* the code to review the
patch, ping people about what is wrong with it, clean it, etc.
   I reserve my opinion here.
> How about we make a upstream branch and do fast iterator merge and other stuff,
>  we review this branch but not the patches,  when it's OK,  merge the branch to
> the main upstream branch or just use it as the main upstream branch? 

Be it a branch or patches lying in Debian package is just the same.  See
DDE, it *is* a branch already.  But if nobody works on it, well things
don't happen magically, it's as simple as that :)

I don't think so, Debian hurd was the main hurd downstream, and debian hurd drive the hurd development. 
So, can I mark the dde as needed for hurd even it is experiment,  and,  commit it and just add some readme like info is enough?
why should we make ourselves so hard to maintain our code when no other people care about that? 

Separate it can not help the development process, but merge the repo will, and make the build and test process easy will make us newbie friendly :)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]