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: <20080213024730.GA8798@mail.oracle.com>
Date:	Tue, 12 Feb 2008 18:47:30 -0800
From:	Joel Becker <Joel.Becker@...cle.com>
To:	David Miller <davem@...emloft.net>
Cc:	akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
	bfields@...ldses.org, jeff@...zik.org,
	linux-kernel@...r.kernel.org, linville@...driver.com
Subject: Re: Announce: Linux-next (Or Andrew's dream :-))

On Tue, Feb 12, 2008 at 06:20:12PM -0800, David Miller wrote:
> From: Andrew Morton <akpm@...ux-foundation.org>
> Date: Tue, 12 Feb 2008 18:06:13 -0800
> 
> > So perhaps a better workflow would be keep the linux-next trees all
> > messy, and then each developer can consolidate, rebase, join and
> > drop things prior to sending their individual trees to Linus.
> 
> We could do that, but I believe Linus's main point is that if we go
> and change the trees then in the end we're merging in something
> different than what was actually tested, namely all the original trees
> as merged into linux-next.
> 
> And I kind of agree with that.

	Make the distinction earlier.  With ocfs2 and configfs (we got
this scheme from Jeff), we keep the topic branches as "unsafe" - that
is, officially rebaseable .  We merge them all into a big "ALL" branch,
which is also "unsafe".  Andrew pulls this for -mm, and it gets tested 
here.  If there is a brown-paper-bag problem, we can tell the original
author to fix it.  Then we re-pull the topic - effectively a rebase.
The ALL is also rebased.  But that's Ok, it will never go towards Linus.
	When a topic is considered worthy of going upstream, we pull it
to a branch called "upstream-linus".  This branch is *NEVER* rebased.
Now that the topic is in upstream-linus, the original topic branch can't
be rebased either.  So any fixes to that topic going forward will stay
in the history.  Since that topic was pulled into ALL for testing, we
are using the identical commits that got tested.

Joel

-- 

"I have never let my schooling interfere with my education."
        - Mark Twain

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@...cle.com
Phone: (650) 506-8127
--
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