linux-kernel - Re: [RFC] to rebase or not to rebase on linux-next

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: <20091027045632.GK13941@mit.edu>
Date:	Tue, 27 Oct 2009 00:56:32 -0400
From:	Theodore Tso <tytso@....edu>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	David Miller <davem@...emloft.net>, sam@...nborg.org,
	mingo@...e.hu, linux-kernel@...r.kernel.org, nico@...xnic.net,
	tony.luck@...el.com, sfr@...b.auug.org.au, mcgrof@...il.com,
	jeff@...zik.org, robert.richter@....com, dmitry.torokhov@...il.com,
	khali@...ux-fr.org, torvalds@...ux-foundation.org
Subject: Re: [RFC] to rebase or not to rebase on linux-next

On Mon, Oct 26, 2009 at 11:02:38PM -0400, Steven Rostedt wrote:
> > The problem isn't that you have to push patches out and only work
> > with patches, the problem is that you want to use publicly visible
> > GIT trees to do your testing at all times.
> > 
> > And sorry, that is not how you're supposed to do things.
> 
> That is a matter of opinion. We prefer to keep things as public as
> possible. No patches back and forth privately doing our own internal
> test suites, then come out with some "production release". If someone
> found something wrong with it then, we would need to start the cycle all
> over again.

There's nothing wrong with public branches that happen to be regularly
rewound, and they do exist in nature.  Exhibit one: The 'pu' branch in
git.  Exihibit two: linux-next.

It's strange to see people arguing for non-transparency, just because
we happen to be using git.  Given that linux-mm uses quilt, and
linux-next accepts quilt patches, I really don't see anything wrong
with linux-next taking git branches that are occasionally rewound when
doing things like adding tested-by:, or when I want to clarify or
rewrite rewrite the patch commit description or even in-code comments
into proper English.

Maybe we need better ways of advertising that a particular branch is
unstable, so people can be adequately warned they base work on that
branch at their own risk.  But fundamentally, saying that we should
keep git branches sekrit just because they might be rewound doesn't
seem to make sense.

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