[Device-tree] mailing list responsiveness and discoverability

[Device-tree] mailing list responsiveness and discoverability

[Brian Norris]

Hello device tree maintainers,

I (sub)maintain the Linux MTD subsystem and hang out on the
linux-mtd@infradead.org mailing list. I have been seeing an increasing
number of submissions that involve device-tree changes. Many of these
changes are ill thought out and may even cause ABI breakage.

According to discussions I've seen on LKML, you want to see better
bindings merged into the kernel, and you want to maintain more control
over the acceptance of bindings in general. However, I see a few
problems that have inhibited this.

(1) Mailing list change: it just so happens that you recently moved
your mailing list to @vger.kernel.org. Some people are still CC'ing
the old one (if they CC any DT list at all). I'm not sure what can be
done about this, exactly. Perhaps a forwarding rule + a warning
response would have been better for a transition period, rather than
just shutting down and rejecting from the old one.

(2) Responsiveness: when we finally do CC devicetree@vger.kernel.org,
I don't see much feedback, even for those which (when I get around to
reviewing them myself) look like they have obvious issues that
device-tree maintainers should care about.

(3) Archives: Archives for devicetree@vger.kernel.org are not easy to
find. I recently subscribed to the mailing list, so general
device-tree activity doesn't get lost in oblivion (to me). But if no
one has done so yet, I'd like to see this mailing list archived on at
least one of gmane (gmane has the old devicetree list and not the new
one.), marc.info (I "devicetree" is this the new one?), etc. and
linked at:

http://vger.kernel.org/vger-lists.html#devicetree

(there are no listed archives as of this email)

Admittedly, (2) is exacerbated by (1) when submitters send to the
wrong address and don't bother correcting and resending, so maybe
discoverability ((1) and (3)) is the only real issue.

Thanks for considering my complaints.

Regards,
Brian

Re: [Device-tree] mailing list responsiveness and discoverability

[ellis]

> (3) Archives: Archives for devicetree@vger.kernel.org are not easy to
> find. I recently subscribed to the mailing list, so general
> device-tree activity doesn't get lost in oblivion (to me). But if no
> one has done so yet, I'd like to see this mailing list archived on at
> least one of gmane (gmane has the old devicetree list and not the new
> one.), marc.info (I "devicetree" is this the new one?), etc. and
> linked at:
> 
> http://vger.kernel.org/vger-lists.html#devicetree

http://www.spinics.net/lists/devicetree/

Re: [Device-tree] mailing list responsiveness and discoverability

[Stephen Warren]

On 08/20/2013 08:25 PM, Brian Norris wrote:
> Hello device tree maintainers,
> 
> I (sub)maintain the Linux MTD subsystem and hang out on the
> linux-mtd@infradead.org mailing list. I have been seeing an increasing
> number of submissions that involve device-tree changes. Many of these
> changes are ill thought out and may even cause ABI breakage.
> 
> According to discussions I've seen on LKML, you want to see better
> bindings merged into the kernel, and you want to maintain more control
> over the acceptance of bindings in general. However, I see a few
> problems that have inhibited this.
> 
> (1) Mailing list change: it just so happens that you recently moved
> your mailing list to @vger.kernel.org. Some people are still CC'ing
> the old one (if they CC any DT list at all). I'm not sure what can be
> done about this, exactly. Perhaps a forwarding rule + a warning
> response would have been better for a transition period, rather than
> just shutting down and rejecting from the old one.

Indeed.

> (2) Responsiveness: when we finally do CC devicetree@vger.kernel.org,
> I don't see much feedback, even for those which (when I get around to
> reviewing them myself) look like they have obvious issues that
> device-tree maintainers should care about.

The problem here is that the mail volume is extremely high. Even keeping
up with the content that I'm explicitly CC'd on is difficult, let alone
the stuff that goes to the list that doesn't CC the binding maintainers.

Re: [Device-tree] mailing list responsiveness and discoverability

[Brian Norris]

On Wed, Aug 21, 2013 at 9:10 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 08/20/2013 08:25 PM, Brian Norris wrote:
>> Hello device tree maintainers,
>>
>> I (sub)maintain the Linux MTD subsystem and hang out on the
>> linux-mtd@infradead.org mailing list. I have been seeing an increasing
>> number of submissions that involve device-tree changes. Many of these
>> changes are ill thought out and may even cause ABI breakage.
>>
>> According to discussions I've seen on LKML, you want to see better
>> bindings merged into the kernel, and you want to maintain more control
>> over the acceptance of bindings in general. However, I see a few
>> problems that have inhibited this.
>>
>> (1) Mailing list change: it just so happens that you recently moved
>> your mailing list to @vger.kernel.org. Some people are still CC'ing
>> the old one (if they CC any DT list at all). I'm not sure what can be
>> done about this, exactly. Perhaps a forwarding rule + a warning
>> response would have been better for a transition period, rather than
>> just shutting down and rejecting from the old one.
>
> Indeed.

Grant, can you do anything about this?

>> (2) Responsiveness: when we finally do CC devicetree@vger.kernel.org,
>> I don't see much feedback, even for those which (when I get around to
>> reviewing them myself) look like they have obvious issues that
>> device-tree maintainers should care about.
>
> The problem here is that the mail volume is extremely high. Even keeping
> up with the content that I'm explicitly CC'd on is difficult, let alone
> the stuff that goes to the list that doesn't CC the binding maintainers.

In the few hours I have been subscribed to the devicetree list, I
already understand this point. Other than avoiding the old mailing
list, then I don't think there's much we can do.

Brian