Graham Percival writes:
> Because this empirically did not work in the past for us.
Possibly we can identify why and fix it. Did we ever have
Git style patches sent to the mailing list as official procedure?
There is quite a difference between attaching a patch to a mail
with a dubious subject, or using a Git patch with beautiful
commit message one-liner directly as email.
The strategy of switching to a much more heavyweight and complex
solution (plan B) instead of fixing plan A reminds me of roadrunner
cartoons ;-)
> - few people reviewed patches
Okay...
> - patches get lost, especially from new contributors
This is bad; however, with Git patches and an email client it is
* easy to identify which are patches from the subject line
* easy to see whether a patch/email has gotten a reply
Now, this does not guarantee that patches will not get lost,
as the past experiment tells us. However, possibly we did
things badly, eg, not use Git patches as emails.
We now have quite a system for contributing. Probably it fixes some
things. However, your survey found out that this is one of the major
sources of developer discouragement.
What if, when adopting a linux kernel style email-patch strategy,
we add some guidelines (we have enough of them right now anyway)
0 prepare a small, nice and sweet patch
1 use a good descriptive subject line of 70 characters max
2 make sure that the subject line sells your patch
3 the subject line should say why we need this
4 send the patch
5a patch is included, goto 0
5b incorporate all comments, goto 0
5c if your patch is ignored, or only gets useless comments, then
* re-read rules 0, 1, 2 and 3
* tell yourself: I'll make a better effort and won't get ignored
* rewrite your description according to 1, 2 and 3
* resend it after 4(?) days
This is all we need*, and much, much easier and friendlier than what we
have now. Indiscriptive, automatic emails with urls in them, that
you cannot reply to. Useless.
* possibly we need to mention git format-patch git send-email and
astyle/fix-cc.py
> Being able to automatically keep track of patches is key.
The submitter does that, until it gets in. Her responsibility.
> I know that the linux kernel mailing list does things differently, but
> they can *afford* to turn away developers, i.e.
Yes, we don't want that [yet/ever]. We can try to take away as
much of the responsibility as we like, for each individual case,
by fixing one of 0..3 in place and say: fixed it it for you,
see below. Thanks!
Jan
--
Jan Nieuwenhuizen <jann...@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
