[OpenWrt-Devel] [19.07] [PATCH] ath79: add support for Sitecom WLR-7100

mail at adrianschmutzler.de mail at adrianschmutzler.de
Mon May 4 15:22:10 EDT 2020

> -----Original Message-----
> From: Tomasz Maciej Nowak [mailto:tomek_n at o2.pl]
> Sent: Montag, 4. Mai 2020 20:45
> To: mail at adrianschmutzler.de; openwrt-devel at lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [19.07] [PATCH] ath79: add support for
> Sitecom WLR-7100
> W dniu 04.05.2020 o 20:31, mail at adrianschmutzler.de pisze:
> > Hi,
> >
> >> -----Original Message-----
> >> From: openwrt-devel [mailto:openwrt-devel-
> bounces at lists.openwrt.org]
> >> On Behalf Of Tomasz Maciej Nowak
> >> Sent: Montag, 4. Mai 2020 19:49
> >> To: openwrt-devel at lists.openwrt.org
> >> Subject: [OpenWrt-Devel] [19.07] [PATCH] ath79: add support for
> >> Sitecom
> >> WLR-7100
> >>
> >> Backported from: 1bc921f419df508c57dc07cd3e43cdf0408c17dd
> >
> > Device support is typically not backported to stable branches, unless you
> have a very good reason for it.
> I see bunch of devices added during rc phase and after stable release, so
> what's the truth here?

Okay, so you want the long answer:

In general, stable branches are meant to only receive "fixes", but not "features".
In that terminology, new devices are also considered "features", of course.

Backporting a device from master (or reviewing it) frequently needs a substantial amount of work and care, as it is linked to several different parts of the code which all might have changed in the meantime. That's why "typically", device support is not backported. This saves a lot of review time that can be spent on other stuff that will go into master (despite, if we'd backport devices to stable on a regular basis, it would defeat the idea of having stable branches).

However, as you have found out, there are exceptions to this "typical behavior". In a nutshell, an exception is made whenever a committer decides to make one, and invests his/her time to review or create a device backport. Personally, I tend to make exceptions in the following cases:

1. A particular device is just a stupid clone of another device, and backporting would complete the family in the stable branch (i.e. add WDR4310 to ath79 where WDR4300 and WDR3600 are already present). Reason: Quick/easy (because clone), benefit (family complete)

2. I have backported a device for downstream anyway. (If I've done all the work anyway, there is no reason to not merge it so others can benefit as well.) Reason: No additional work.
Note that this is different from merging the device support somebody else provided: In that case, I would need to review it first, and reviewing a backport is about the same amount of work as needed for creating it in the first place.

3. There is a strong reason of any kind why a particular device should be made available. (That would also make me review a more substantial support backport from somebody else.)

But as Daniel stated, backporting device support is not "forbidden". That's why I wrote "is typically not backported", as it's effectively a matter of perceived behavior in the past, and no formal rule.

After all, you just have to find a committer who reviews and applies it. I just tried to express that this most probably won't happen, as other committers might follow a similar reasoning as discussed above (as experience tells).

So, please don't feel pestered.



> >
> > Best
> >
> > Adrian
> >
> --
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20200504/be4c49c8/attachment.sig>
-------------- next part --------------
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list