From: Mark Wielaard <mark@klomp.org>
To: elfutils-devel@sourceware.org
Subject: Some ideas for process improvements/changes
Date: Thu, 06 Apr 2023 18:30:53 +0200 [thread overview]
Message-ID: <11b1c515a2a0ed2af0c72ac6437aca81ba0806a7.camel@klomp.org> (raw)
Hi hackers,
In general it feels like the elfutils community is working well, there
are regular releases with bug fixes and new features. Most patches are
reviewed fairly quickly (although there are some exceptions where
patches have been pending too long). So I don't want to change too
much. But here are some small suggestions for changes to out processes
that might be helpful:
- Get rid of ChangeLog files and trivial ChangeLog entries
I personally love ChangeLog entries. Writing them helps me
double check I actually intended to make the changes. And
it is a great help reviewing patches. It helps having to
guess if some specific change was an accident or intended.
But patches that have changes against the ChangeLog files are
sometimes hard to rebase or move between branches. The gnulib
git-merge-changelog driver is awesome, but is not always able
to help. Also some commit messages for smaller changes are
already fine describing what changed.
So I propose to drop ChangeLog files completely and only add
a ChangeLog entry to the commit message for larger changes
to help the review process.
- Use patchwork more
All patches sent to the mailing list are tracked at
https://patchwork.sourceware.org/project/elfutils/list/
It has helped me a lot keeping track of patches that
have been pending for some time. Also git-pw has been
really nice for cherry-picking patches.
https://patchwork.readthedocs.io/projects/git-pw/en/latest/
Please let me know if you would like to help maintain the
pending patch list and I'll add your account as maintainer
for the elfutils project.
For using it with git-pw use these .git/config settings:
[pw]
server = https://patchwork.sourceware.org/api/1.2/
project = elfutils
token = <hex-token>
states = committed,accepted,superseded,deferred,rejected,under-review
It would be nice if it was automated a bit more by have a git
commit hook that flagged whether a patch was committed. And if
the buildbot try-branch system would flag pass/fail on the patch.
- Don't require "real names" in Signed-off-by lines.
Our current CONTRIBUTING guide say that you have to use your
your real name for the Signed-off-by line. This is sometimes
problematic for people for who their real (legal) name is not
how they identify themselves to others. I suggest to change
the requirement as follows (this mimics what the linux kernel
project did recently):
diff --git a/CONTRIBUTING b/CONTRIBUTING
index bb48975b..1a1c443f 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -45,7 +45,9 @@ then you just add a line saying
Signed-off-by: Random J Developer <random@developer.example.org>
-using your real name (sorry, no pseudonyms or anonymous
contributions.)
+using a known identity (sorry, no anonymous contributions.)
+The name you use as your identity should not be an anonymous id
+or false name that misrepresents who you are.
git commit --signoff will add such a Signed-off-by line at the end of
the commit log message for you.
- "Security" bug guidance
Here I don't have good guidance, but I have the feeling some of
the bugs reported (especially by some fuzzers) are sometimes
unnecessarily marked as security issues. Which causes lots of
unnecessary work for downstream users of our code. Especially
if someone starts assigning CVEs to them. It would be good to
have some explicit text to point "security" bug reporters at
on how we will handle their bugs.
Cheers,
Mark
next reply other threads:[~2023-04-06 16:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-06 16:30 Mark Wielaard [this message]
2023-04-06 17:34 ` Frank Ch. Eigler
2023-04-06 21:57 ` Mark Wielaard
2023-04-07 0:56 ` Frank Ch. Eigler
2023-04-07 20:26 ` Mark Wielaard
2023-04-07 20:44 ` Frank Ch. Eigler
2023-10-19 16:13 ` Mark Wielaard
2023-10-25 13:10 ` Mark Wielaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=11b1c515a2a0ed2af0c72ac6437aca81ba0806a7.camel@klomp.org \
--to=mark@klomp.org \
--cc=elfutils-devel@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).