linux-kernel - Re: [GIT PULL REQUEST] watchdog

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20130713120713.GG14258@spo001.leaseweb.com>
Date:	Sat, 13 Jul 2013 14:07:13 +0200
From:	Wim Van Sebroeck <wim@...ana.be>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Linux Watchdog Mailing List <linux-watchdog@...r.kernel.org>
Subject: Re: [GIT PULL REQUEST] watchdog - v3.11-rc1

Hi Stephen,

> On Thu, 11 Jul 2013 22:34:24 +0200 Wim Van Sebroeck <wim@...ana.be> wrote:
> >
> > Please pull from 'master' branch of
> > 	git://www.linux-watchdog.org/linux-watchdog.git
> 
> This was all rebased in the last day from what has been in linux-next for
> some time.  All the patches are the same, so the rebase achieved nothing
> positive at all.  Please don't do this (see I am still much nicer than
> Linus :-)).  Just submit what you have in linux-next which has already
> been tested (presumably) and Linus can fix up any conflicts (in this case
> there were nothing significant anyway).

<sigh on><sigh off>.
My linux-next patches are in:
git://www.linux-watchdog.org/linux-watchdog-next.git
which is a different tree then:
git://www.linux-watchdog.org/linux-watchdog.git .

So my development process is the following:
After the merge window is closed I start adding patch to the
linux-watchdog-next.git tree. All patches go into the linux-watchdog-next tree
so that they also become part of the linux-next tree. This to make sure that
patches are normally tested. Once in a while I receive a bugfix which is also
applied to linux-watchdog-next. After having been a couple of days in
linux-watchdog-next, I also apply this patch to the linux-watchdog tree and ask
Linus to pull the fix from the linux-watchdog tree (and thus not from the
linux-watchdog-next tree). Near the end of the merge window I sync up the
linux-watchdog tree to the mainline linux tree and add the patches (that have
been in linux-next) to this tree. Reason I do this is because there are
also other watchdog patches that come in via the arch or mfd trees. I can then
catch small merge conflicts so that Linus has no problem with this. At the same
time I clean-up my linux-watchdog-next tree so that it is clean again for the
development towards the next merge window again.

I'm sure that everything can be done in one tree with different branches, but
I am used to do this for years now.

So to answer on what you wrote:
1) it was not a rebase in the linux-watchdog-next tree but a sync + the addition
of the patches from development into the linux-watchdog tree so that I can do
a so clean possible handover to Linus for the watchdog patches.
2) If I have to submit what is in Linux-next, why don't we then make the merge
only one day where Linus just pulls linux-next ? We don't allow any patches
for the nex merge window in linux-next when the merge window opens so
technically this is possible. But I'm sure you also understand that everything
what is in linux-next is not always something what Linus want's to pull. So me
sticking to 2 different trees is still in line with the phylosofy that Linus
decides on which trees he wants to pull and that we test as much as possible by
using linux-next.
3) I personnaly think you are doing a great job for the complete community and
linux kernel development, but I think you started to focus on merge details to
much so that you forgot the overal system that we created. If our Basic system
(testing in linux-next and then handing over the tested stuff to Linus so that
he still has the final decision as the overall maintainer) however has changed
then I have to apologize and then my development cycle is indeed wrong. If the
basic system is still the same then my way or working is probably not the best
but still the easiest for me, and still correct.

> Also, you might like to consider using "git request-pull" to generate a
> starting place for your pull request rather than sending all the commit
> messages and the diff in line.

Nice! Learned something new here. Thanks!

Kind regards,
Wim.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/