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: <7119737.DzNTr3WlaV@avalon>
Date:	Fri, 08 Jan 2016 20:28:51 +0200
From:	Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:	Rob Landley <rob@...dley.net>
Cc:	Simon Horman <horms@...ge.net.au>, Rich Felker <dalias@...c.org>,
	linux-sh@...r.kernel.org, linux-kernel@...r.kernel.org,
	Yoshinori Sato <ysato@...rs.sourceforge.jp>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	"D. Jeff Dionne" <jeff@...inux.org>
Subject: Re: [PATCH 2/2] MAINTAINERS: remove linux-sh list from non-arch/sh sections

Hi Rob,

On Friday 08 January 2016 11:35:37 Rob Landley wrote:
> On 01/08/2016 12:56 AM, Simon Horman wrote:
> > On Thu, Jan 07, 2016 at 11:40:54PM -0500, Rich Felker wrote:
> >> From: Rich Felker <dalias@...c.org>
> >> 
> >> Recently the bulk of traffic on the linux-sh list has been unrelated
> >> to arch/sh but instead focused on Renesas hardware for their ARM-based
> >> SoCs. As part of resuming maintenance of arch/sh, remove the linux-sh
> >> list from the MAINTAINERS file sections for these other components so
> >> that new arch/sh development is not drowned out by unrelated
> >> cross-postings.
> > 
> > The use of the linux-sh mailing list has evolved somewhat over time,
> > from SH related to ARM related. Its name (obviously) has not evolved.
> 
> According to http://vger.kernel.org/vger-lists.html#linux-sh
> 
>   This is the development discussion and bug reporting mailing list
>   for the Linux port to the SuperH architecture.
> 
> By "evolved" you mean "acquired a bunch of off-topic traffic because the
> architecture's original owner abandoned it and moved on to other things
> that already _have_ lists, but treated this list as their own personal
> scratch pad".
>
> Those people let the architecture this list was created for become
> unmaintained for a year and a half.

A year and a half since the architecture was officially marked as orphan, at 
least one more year since the maintainer stopped handling patches.

> DURING that year and a half they posted unrelated content to the list
> because they think it belongs to them personally rather than to Linux.

I would hardly call upstream Linux R-Mobile and R-Car development "personal 
stuff". The decision to keep using the linux-sh mailing list comes from the 
overlap between the SH-based and ARM-based chips. It sure doesn't match the 
mailing list description anymore, but jumping to the conclusion that the 
description is the only authoritative source of information is a bit too 
hasty.

> Now that the architecture is becoming maintained again (on the hardware
> side as well, because the patents have expired and other people are
> taking an interest), we would like to reclaim this list to develop the
> Linux arch/sh directory.

How about asking nicely instead of claiming ? It usually helps.

> This is a kernel list, not a Renesas list.

It has never become a Renesas list. We have private mailing lists for that.

> > Dropping linux-sh@...r.kernel.org from portions of the MAINTAINERS file as
> > you suggest would essentially leave the Renesas ARM work without a mailing
> > list or patchwork instance.
> 
> Here's a half-dozen arm lists already:
> 
>   http://www.arm.linux.org.uk/mailinglists/lists.php
> 
> And that's not even a complete list of them all:
> 
>   http://vger.kernel.org/vger-lists.html#linux-tegra
> 
> > Both of which are actively used for that work.
> 
> Off-topic traffic exists, therefore it should exist? Its volume is its
> justification? Why do we have spam filters then?
> 
> > Off-hand I can think of three solutions to this problem:
> > 
> > 1. Live with the noise
> > 2. Establish a new list (and possibly patchwork instance) for the SH work.
> 
> So... squatter's rights?
>
> Renesas calling its new arm stuff "shmobile" is as relevant as Intel
> designating itanic "ia64" as the successor to "ia32". The superh
> architecture's only been officially unmaintained for a year and change
> (presumably because the patents were expiring so they saw no more profit
> in it for themselves).
> 
> Meanwhile there was active superh-compatible work off-list during that
> time (the j-core stuff) that's just now coming to fruition, building off
> 20 years of history and a decade and change of previous Linux development.
> 
> > 3. Establish a new list and patchwork instance for the ARM work.
> 
> Now that people are interested in superh again, the correct answer
> seemed to be #3, which is what we were suggesting.

Now I like the suggesting better than the claiming :-)

> A similar situation occurred when buildroot didn't have its own mailing
> list for several years and used the uClibc list: uClibc development
> suffered greatly. I eventually got sick of it and created a new
> buildroot list and politely kicked the traffic off, which is why the
> first message in the buildroot mailing list archive is:
> 
>   http://lists.busybox.net/pipermail/buildroot/2006-July/012219.html
> 
> The corresponding "please move the buildroot traffic off the uClibc
> list" thread started at:
> 
>   http://lists.busybox.net/pipermail/uclibc/2006-July/036836.html
> 
> The current list is not a Renesas list, it is a Linux list for the
> SuperH architecture port. Says so on the tin, and that was its history
> until pretty recently. Renesas moving away from the SuperH architecture
> doesn't change that this is the Linux arch/sh list.
> 
> We aren't proposing to rename the arch/sh directory to "jcore", so
> "linux-sh@...r.kernel.org" remains the logical name for this list. The
> new stuff is intentionally backwards compatible with the old stuff,

How about IP cores around the CPU, do you plan to develop cores compatible 
with the Renesas implementations, or go for something else ? If we end up 
sharing the same peripherals between multiple architectures we will need to 
decide on how to coordinate the work.

> and we are happy to maintain compatibility with the old stuff, and have
> current plans to move it to device tree. (We just need a lot more legacy
> test hardware...)

I personally don't think that's worth it given that most of the legacy 
hardware is buried under a thick layer of dust (when not used as coasters or 
door stoppers).

-- 
Regards,

Laurent Pinchart

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ