Purpose of openwrt-devel?

[Paul D]

Elliott,

You raise some important points, and also mention some *solutions* which 
is commendable.

1) all work is done voluntarily
2) time is limited
3) understanding is lacking
4) courage is lacking

Or... success has many fathers, but failure is an orphan.


Speaking from personal experience over the course of several years: I've 
seen patch-sets appear here and get lost like a fart in the wind. Have a 
look at patchwork. They require attention. See 1 and 2.

Then the kernel and software has changed so many times in-between that 
patches become irrelevant. The exception is members who post patches 
here, who wrote said patches, and have commit permissions, see those go in.

In view of this, I propose a maximum two week life-time/cycle. Time 
limits ensure things have a definite start and finish. Didn't work out? 
Try again. New member votes have 21 days.

After this time period, it's safe to assume your patch has not garnered 
interest or enough understanding.


What is the problem with patches here? It requires someone to do *work* 
to apply it and see it in context. On github, for example, just send a 
PR and the work is already done for you. You see the patch in context, 
and you can tag other reviewers immediately. Small changes are handled 
quickly. Big ones move at glacial pace.

That said, I've yet to see a maintainer response to PRs in more obscure 
repos on e.g.

https://github.com/openwrt/odhcpd


I asked for commit permissions to at least the luci repo because I was 
tired of waiting for simple fixes and good ideas to land *for years* 
which I knew would work. I set about halving the amount of open PRs and 
we've seen virtually no breakage. At the same time, I'm no vet, so I 
defer bigger changes to the vets.

This brings us to another point: patchsets should be small, unless 
someone can take responsibility for it from coding to commit.


BUT most of this belies the understanding with GH: it uses git. A change 
management system. If you screw something up, you can unscrew it by ... 
reverting. People don't want to take responsibility, are afraid of being 
wrong or getting shouted at for screwing up builds. ( See 3 and 4 ). 
It's software. Make a new one. Reverting tells us a number of things: we 
learn what did not work, and we tried.

* We need more trusted members who can tackle specific package areas to 
deal with the volume of PRs on github. Especially in the openwrt repo.

====





On 2024-03-13 09:43, Olliver Schinagl wrote:
> On 13-03-2024 08:46, Felix Baumann wrote:
>> Am 13. März 2024 05:11:23 MEZ schrieb Elliott 
>> Mitchell<ehem+openwrt at m5p.com>:
>>> I must challenge this.  If patches via the mailing list were accepted,
>>> then we should see things sent to the mailing list getting into the
>>> repository.  Yet many patches get no attention.  Some get reviews from
>>> various people, yet then never get into the main repository.
>> It's the same for Github, some stuff doesn't get in and remains there. 
>> There might be a difference what kind of PRs are send to the mailing 
>> list and you get attention of different committers when sending to 
>> mailing list vs sending to Github. Github patches might be accepted 
>> more easily when it's just a new device for a well established target.
>>
>> I feel like patches on the mailing list are ignored, when committers 
>> don't have time for review or don't feel confident enough to do it 
>> well (not their field of expertise). Or if it's written in a language 
>> they don't feel confident reviewing.
> 
> *PERSONALLY* I think mailing list reviews are on their way out. People 
> have found that there are easier and better ways. Granted, some folks 
> still _prefer_ mailing list reviews. *I PERSONALLY* do not at all. I 
> hate my mailbox being full with threads of stuff I have no attention for 
> at that moment, it just adds noise for me. And ignoring it for a  while 
> just puts huge amounts of e-mails in my mailbox, that become useless 
> after a while. Though I much rather would like to see GitLab then GitHub 
> use :p but that's more the FOSS spirit, and avoiding anything Microsoft 
> where possible :p
> 
> Even the Linux kernel (forgive me for omitting the link, though I can 
> find it if really needed, they are just not easy google terms) is 
> discussing this; but there's a few technicalities holding them back for 
> the most part (See Linus's rant against github a few years ago, but 
> diff-range, comment on commit-message are two key points).
> 
> Further more, I think it is fair to realize that very few developers 
> that exist, as said before, prefer different ways of working. This 
> sucks, but means we have two 'groups' of reviewers in two different 
> locations.
> 
>> In the end it's up to one committer to do the merge. If Noone replies, 
>> then that doesn't happen and the patch will only collect dust.
>>
>> Yes, that might be stupid if there was no critical comment on a patch 
>> but that is how it currently appears to be. This is still voluntary 
>> work and people choose themselves what to spend time on.
>>
>> I realize this is not a satisfying answer.
>> I won't comment on how your code was used as a base for the script 
>> earlier this year. I'm not involved enough in the project to handle 
>> this. Regardless of copyright (since I'm just a layman): people didn't 
>> tell you about it or mentioned you in the commit that was merged. On a 
>> social level that was not okay, that is all I can say. I'm sure Noone 
>> meant harm but still: Noone thought about consequences.
>>
>> I cc-ed Olliver to let him know about this mail thread.
> 
> Thanks!
> 
> In light of that
> 
>> Huh.  Parts of that look suspicious.  Those commit messages look *very*
>> similar to my version 2.  I was jumping between documentation sources
>> when writing it.
> Not sure what is surprising to you, since the mail thread was listed in 
> the MR and your perl code was even referenced (not _directly_ I admit). 
> Obviously I was using your messaging format as that was discussed on the 
> mailing list and I didn't want to deviate from those messages, also they 
> made a lot of sense anyway. "Fair Use" if anything :p
> 
> The actual code of course has nothing to do with the perl script, as you 
> right full say 'I know nothing of perl', as does probably most of the 
> development community by now. Which is sad for perl, but 'it is what it 
> is'.
> 
> In no way was there any ill intent. I just wanted my kernel tree bump 
> for the realtek target, and didn't want to install, learn etc perl to 
> try things out. Sorry for that on my part.
> 
>> Regards
>> Felix Baumann
> 
> 
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel