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] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFx4bytJFzJTbCbp-YTEfuGo9di3oyBwY87BRRXszfK5Rg@mail.gmail.com>
Date:	Tue, 24 Jul 2012 09:47:52 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Bob Liu <lliubbo@...il.com>
Cc:	linux-kernel@...r.kernel.org,
	uclinux-dist-devel@...ckfin.uclinux.org, vapier@...too.org,
	sonic.zhang@...log.com
Subject: Re: [GIT PULL v2] Blackfin changes for 3.6-rc1

On Mon, Jul 23, 2012 at 10:54 PM, Bob Liu <lliubbo@...il.com> wrote:
>
> This is the new pull request about blackfin changes for 3.6-rc1.
> I've rebased my tree to 3.5.

So I pulled it, but next time I'd really like to not see so much
recent rebasing.

So preferably it would be something that has been stable for at least
a week, and tested in next. If you really need to use some kind of
rebasing model, try to calm it down *before* the merge window starts,
so that you can have a tested tree ready without rebasing it in the
last few days.

The release schedule is generally predictable enough that you can (for
example) decide to pick a fairly stable -rc version (say -rc5 or -rc6,
by which time the kernel should be pretty reliable), and use that as
your base point, and keep it in -next *without* rebasing at all (just
possibly add new patches at the end).

Generally, the less you rebase, the better. Yes, sometimes it's worth
it as a way to clean up the history especially if you need some
changes that come from elsewhere, or if you want to fix a bug in a
commit that you haven't asked me to pull yet. But if you can get to a
workflow with minimal rebasing, it really helps people who want to
work with you, so that they can rely on your tree not changing from
under them.

Now, I assume that blackfin just doesn't have enough developers or big
changes for this to be a big deal, but it's a good habit to aim for
regardless.

                   Linus
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ