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-next>] [day] [month] [year] [list]
Date:	Fri, 23 Oct 2009 15:35:12 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Nicolas Pitre <nico@...xnic.net>,
	"Luck, Tony" <tony.luck@...el.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	"Luis R. Rodriguez" <mcgrof@...il.com>,
	Jeff Garzik <jeff@...zik.org>,
	Robert Richter <robert.richter@....com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Jean Delvare <khali@...ux-fr.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: [RFC] to rebase or not to rebase on liunx-next

This is an email attempt to move a thread from users.kernel.org to LKML
where it belongs.

I've tried to Cc all those that were on the original Cc (sorry if you
don't want to be, but just send this to /dev/null in that case).

Here's the basic gist, some people believe that linux-next is used as a
dumping ground for their repos that get rebased all the time. They use
linux-next for early testing, and mostly to make sure their repo will
not collide with other developers repos.

Some of the reasons for the constant rebasing are:

1) the patches are held in quilt, which just by nature leads to
rebasing.  These developers find that quilt is the best tool for the
job.

2) after collisions with other repos, the developers find other ways to
to solve the issue, and rebase it instead of having a bunch of "merged"
conflicts go off to Linus.

3) They want acks and reviewed-by labels added. Which would cause a
rebase because the commit must change to add these.

4) Major bugs are found and bisectablity is broken. Rebasing would keep
the git history working for bisecting.


I'm sure there are other reasons, please feel free to add your own, or
to refute the ones I listed.

Other developers feel that there's too much rebasing going on in
linux-next and that there should be a cleaner work-flow. Perhaps have
maintainers test their work a bit more before passing it off to
linux-next?

This is not a complete description of what is going on, but it gets the
idea across. Now those of you that want to argue this, go ahead. But use
this email as the starting point and keep it off of users.kernel.org

Thanks,

-- Steve


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