Hi contributors!

Patrick Williams patrick at stwcx.xyz
Wed May 25 06:03:50 AEST 2016


On Tue, May 24, 2016 at 03:30:00PM +1000, Cyril Bur wrote:
> ...
> Sincerely,
> 
> Cyril
> _______________________________________________

Cyril,

You wrote a lot.

On commit messages:
    I totally agree.  Poor commit messages are a pet peeve of mine as
    well.  I also recommend http://chris.beams.io/posts/git-commit/ .
    Going forward, I will attempt to do a better job of encouraging
    better formed messages in reviews.

On git documentation:
    Thanks for the write up.  Rather than put yet another git tutorial
    in a wiki, I would prefer we point to a good existing tutorial.  For
    some reason new people seem to always want a "cookbook" of simple
    git commands.  [Un]Fortunately, nothing in git is that simple.

On Reviews:
    We do have a problem with some people reviewing in Github
    (Reviewable.io) and some people reviewing via mailing list.  We also
    have an issue with maintainers not ensuring all comments have been
    addressed.

    We discussed at the Wed (5/18 PM for US) call last week how to do
    reviews going forward.  We agreed to the following:
        1) For OpenBMC specific packages we are going to set up a Gerrit
           server for all code reviews.  There is a Github integration
           module for Gerrit that allows mirroring pull requests into
           Gerrit and replicating merged code back to Github.  Look for
           this in the near future.
        2) For packages we are modifying from upstream, we should use
           upstream method (ie. mailing lists for kernel, yocto, etc.).
           Patches accepted into the openbmc meta-layers should have
           already be submitted upstream and have a reasonable
           confidence about their long-term acceptance.
        3) For packages we are _temporarily_ forking from upstream, to
           do significant and focused development on, we can use either
           Gerrit or this mailing list.  Eventually, changes should be
           submitted, via path #2, upstream.

    Once we get the Gerrit server in place, I plan to deprecate the
    automatic pull-request mailer.

On 'Reply-All' issue with patches:
    At some level, this is an intrinsic problem with Github.  People can
    optionally set their Github profile to "Hide my email address
    whenever possible."  The content for the cover letter comes from the
    pull request information they have entered into the Github
    web-field.  When my patch mailer gets the content from the pull
    request to make the cover letter, it has to ask Github for their
    email address.  For people who have hidden their email address in
    their profile this yields something like "Joe Developer
    <joey_d at users.github.com>" (I forget the exact format off the top of
    my head).  Unfortunately, this means my auto-mailer and anyone
    responding to the cover gets lots of bounces, so I disabled the
    auto-cc on the cover.  (There is an obvious solution to filter out
    the @...github.com email addresses but I haven't had the spare
    cycles).

    For the code patches themselves, I use git-format-patch and
    git-send-email and I don't think I suppress-cc at all.  That means
    the author, per the commit message, should be cc'd.

    Like I said early, this script is planned to be deprecated at some
    point in the not-too-distant future anyhow.

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20160524/9684e7f6/attachment.sig>


More information about the openbmc mailing list