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]
Date:	Tue, 16 Jul 2013 01:40:28 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Greg KH <greg@...ah.com>
Cc:	ksummit-2013-discuss@...ts.linuxfoundation.org,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	James.Bottomley@...senPartnership.com
Subject: Re: [Ksummit-2013-discuss] KS Topic request: Handling the Stable
 kernel, let's dump the cc: stable tag

On Tue, 16 Jul 2013, Jiri Kosina wrote:

> (*) For me personally, the best mode of operation would actually be to 
>     have for-stable/3.x branches in my git tree, cherry-pick from other 
>     topic branches once the patches are in Linus' tree, and send you pull 
>     request for stable regularly (for each stable branch separately of 
>     course)
>    
>     This model would make maintainers clearly responsible for the contents 
>     of stable tree, wouldn't cause any extra work for you (quite the 
>     contrary, I'd say), and it'd follow the development model we have for
>     Linus' tree.

... and it will actually have a nice self-regulatory feature (in case 
maintainers who are pushing too much stuff your way are part of the 
problem).

Preparing a proper pull request requires much more care, "stopping and 
thinking for a while", formulating the pull request, than just blindly 
tossing "Cc: stable" everywhere in a headless-chicken mode.

To sum it up:

- if the maintainers really do care about their patches being in the 
  -stable tree, this wouldn't cost them too much extra time

- if they are just randomly pushing everything to -stable because "hey, 
  why not", this will be an extra hurdle for them to overcome, and they 
  will be revealed easily by poor pull request justification

- if the maintainers are lazy and don't care about preparing stable 
  branches, it's their responsibility (and their shame) that -stable will 
  be missing the code they are responsible for

- it offloads the work from single point of failure (you) to the 
  maintainers, which makes a lot of sense to me

- it aligns the workflow with the workflow that's in place for Linus' 
  already (and not only there) to be more or less a proper git workflow

-- 
Jiri Kosina
SUSE Labs
--
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