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+open...@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@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel