Purpose of openwrt-devel?

[Olliver Schinagl]

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