public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Rebecca Cran <rebecca@bluestop.org>
To: stephano <stephano.cetola@linux.intel.com>,
	"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: Re: [edk2-announce] March Community Meeting Minutes
Date: Mon, 11 Mar 2019 14:55:41 -0600	[thread overview]
Message-ID: <3dd639e4-2ff8-f8f1-a10d-8b4059169e25@bluestop.org> (raw)
In-Reply-To: <bfd246e1-ed04-90f7-4f12-a06630bca119@linux.intel.com>

On 3/11/19 10:33 AM, stephano wrote:

>
> Stephano has taken an action item to work with the Kubernetes 
> community to see what trade-offs and benefits they experience using 
> GitHub. Kubernetes is one of the largest open source projects 
> currently using GitHub for patch reviews. It is notable that a git 
> module "request-pull" exists, and the kernel gives directions on how 
> to use these "git style" of pull requests:


I took a look at the Kubernetes project a few days ago, and there are a 
couple of things we might _not_ want to copy, since they look to me to 
obfuscate things.

For example, the git log:


commit 50bf223a0545a121dc202de8fad673402b8ebde6 (HEAD -> master, 
origin/master, origin/HEAD)
Merge: 4ea48886df c5c4cd2580
Author: Kubernetes Prow Robot <k8s-ci-robot@users.noreply.github.com>
Date:   Mon Mar 11 12:00:15 2019 -0700

     Merge pull request #75224 from neolit123/certs-print-key-on-phase

     kubeadm: print key inside the upload-certs phase of init

commit 4ea48886df2e0830daa2384f6fe57dd55b8dbb51
Merge: 8477c486a8 58c7b5de9c
Author: Kubernetes Prow Robot <k8s-ci-robot@users.noreply.github.com>
Date:   Mon Mar 11 09:39:40 2019 -0700

     Merge pull request #75008 from nikopen/patch-4

     rebase audit-proxy image to distroless/static

commit 8477c486a81c1094440cf7c78d6be5c52b0828c4
Merge: 6ec5a7d337 fa926ed6e0
Author: Kubernetes Prow Robot <k8s-ci-robot@users.noreply.github.com>
Date:   Mon Mar 11 09:39:27 2019 -0700

     Merge pull request #74652 from cofyc/fix72500

     Delay CSI client initialization


You can't see without following the pull request *who* committed the 
change.  There are almost 1000 open pull requests, which is something we 
probably want to try and avoid. They also seem to have _lots_ of labels. 
I wonder if there's a cleaner way of handling them?


Also, about groups.io, I wonder if I might want to investigate their 
support for using our own domain, so people don't have to remember that 
the mailing list and documents are on groups.io and not tianocore.org?


--

Rebecca Cran



  reply	other threads:[~2019-03-11 20:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-11 16:33 [edk2-announce] March Community Meeting Minutes stephano
2019-03-11 20:55 ` Rebecca Cran [this message]
2019-03-11 22:20   ` stephano
2019-03-11 22:54     ` Rebecca Cran
2019-03-11 22:29 ` stephano

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-list 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=3dd639e4-2ff8-f8f1-a10d-8b4059169e25@bluestop.org \
    --to=devel@edk2.groups.io \
    /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