public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: elfutils-devel@sourceware.org
Subject: Re: Some ideas for process improvements/changes
Date: Thu, 6 Apr 2023 23:57:49 +0200	[thread overview]
Message-ID: <20230406215749.GC18331@gnu.wildebeest.org> (raw)
In-Reply-To: <20230406173420.GA10746@redhat.com>

Hi Frank,

On Thu, Apr 06, 2023 at 01:34:20PM -0400, Frank Ch. Eigler via Elfutils-devel wrote:
> > - Get rid of ChangeLog files and trivial ChangeLog entries
> >   [...]
> 
> Yes please!

So sad, on irc people are also enthousiastic about this. O well. :)

> > - Use patchwork more
> >   [...]
> 
> This doesn't seem like something for community/contributors
> to do - patchwork seems mostly a maintainer/committer tool.

But I want more community/contributors to feel like they are
maintainers/committers!

> >   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.
> 
> Sounds like a sourceware infrastructure RFE.

Yes, but if I RFE that then it often just comes back to me to add it
:) So I mention it here in the hope someone says "O, but that is easy,
this is exactly how to do it..."

> > - Don't require "real names" in Signed-off-by lines.
> >   [...]
> > +The name you use as your identity should not be an anonymous id
> > +or false name that misrepresents who you are.
> 
> (No strong opinion on this one, except that a declaration that is this
> informal would have little weight, should it ever be relied upon in
> legal proceedings.)

Do you feel this weakens our Developer's Certificate of Origin
process? My point is that we shouldn't judge what is a "real name" or
not. But the name shouldn't misrepresent who someone is. What we care
about is that the identity people use to sign the certificate refers
to a real person that can be contacted about their contributions when
needed.

> > - "Security" bug guidance
> >   [...]
> 
> Yeah, a brief SECURITY file would be nice.

Any suggestions about what to put in such a section or file.  My main
concern is that people are filing things we regard as simple bugs as
"security" issues and get CVEs assigned which cause lots of extra work
for some of our downstream users. I think we should be clear that we
want to fix all bugs and don't want to get dragged into embargoed
security theater.
https://daniel.haxx.se/blog/2023/03/29/pre-notification-dilemmas/

Cheers,

Mark

  reply	other threads:[~2023-04-06 21:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-06 16:30 Mark Wielaard
2023-04-06 17:34 ` Frank Ch. Eigler
2023-04-06 21:57   ` Mark Wielaard [this message]
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=20230406215749.GC18331@gnu.wildebeest.org \
    --to=mark@klomp.org \
    --cc=elfutils-devel@sourceware.org \
    --cc=fche@redhat.com \
    /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).