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