Hello device tree maintainers, I (sub)maintain the Linux MTD subsystem and hang out on the linux-mtd@xxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx, 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@xxxxxxxxxxxxxxx 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
