linux-kernel - Re: [GIT PULL] 9p changes fro merge window

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]

Date:	Wed, 26 Oct 2011 16:05:13 +0200
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Eric Van Hensbergen <ericvh@...il.com>,
	V9FS Developers <v9fs-developer@...ts.sourceforge.net>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] 9p changes fro merge window

On Wed, Oct 26, 2011 at 14:58, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Wed, Oct 26, 2011 at 2:48 PM, Eric Van Hensbergen <ericvh@...il.com> wrote:
>> What's the preferred maintainer workflow?  I had been fetching and then rebasing, which seemed to keep my shortlog clean of merge commits and the outstanding patches towards the top.  Should I just be pulling from upstream and not caring about the merge commits?
>
> Hell no.
>
> Why do you pull from upstream? What does that add to *your*
> development? Don't do it. Pick a place to start, and just develop
> things. Ask me to pull.
>
> No merge commits, no rebases, no nothing. JUST ACTUAL WORK. It also
> keeps the history clean, and means that what people test (in
> linux-next _and_ in your own internal testing) is actually what you
> ask me to pull, rather than something else.

That works if what you do is "small" and "fast".

"small":
  - There are no conflicts with anyone else who is e.g. restructuring
part of the tree,
  - You do not want to early submit parts that should go in through a different
    maintainer as soon as they're ready (and thus they disappear from
your patchset
    when you rebase),

"fast":
  - You started working on it after the last merge window, and not 3
releases ago.

If the above are not true, it's a hell of work to keep track of
everything without
rebasing. Not to mention that the reviewers don't like seeing patches that apply
to obsolete trees.

And of course I don't want to bother you with fixing the merge
conflicts that happen
when I would ask to pull e.g. the m68k genirq conversion based on the
state of your
tree when I started working on it ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
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/