From: Paul Menzel <pmenzel@molgen.mpg.de>
To: Benjamin Fair <benjaminfair@google.com>
Cc: Brandon Kim <brandonkim@google.com>, openbmc@lists.ozlabs.org
Subject: Re: Upstreaming downstream Google BMC repositories
Date: Thu, 7 Jan 2021 19:25:17 +0100 [thread overview]
Message-ID: <711a5031-c774-4b03-6a6e-1f14d8699789@molgen.mpg.de> (raw)
In-Reply-To: <CADKL2t5ajasf9NzFbTwtT0=W7ZO2jcfD5V+tk5VVSrkZTuLNmw@mail.gmail.com>
Dear Benjamin,
Am 07.01.21 um 18:33 schrieb Benjamin Fair:
> On Thu, 7 Jan 2021 at 00:09, Paul Menzel <pmenzel@molgen.mpg.de> wrote:
>> Am 07.01.21 um 02:49 schrieb Brandon Kim:
>>
>>> We're exploring ways of upstreaming some of the downstream repositories
>>> from Google to openbmc/* .
>>>
>>> Half, if not most of the downstream repositories are C++ daemons that are
>>> specific to Google so we didn't want to create a bunch of new
>>> openbmc/<repo> that no one would use.
>>>
>>> An idea that Ed gave me was having something like openbmc/google-misc
>>> repository for all these repositories and if there are any that seem useful
>>> to others, we can break it out into a different, separate repository in
>>> openbmc/* layer.
>>>
>>> Please let me know if this seems like a good idea and I'm open to other
>>> suggestions!
>>
>> Thank you very much for putting in the effort to make these repositories
>> public.
>>
>> Using the openbmc/google-misc approach, how would the git history
>> (commit log) be handled?
>>
>> Personally, I would prefer having small repositories as git makes that
>> very easy to handle. Also it might save you time, as you do not have to
>> think about what to do with the git history, and do not have to merge it.
>
> We would most likely squash the history together, in case there's
> something confidential or private in the earlier commits.
Understood. If that could be avoided, and only the confidential stuff
removed, that would be great, as the git history gives a lot of insight
into design decisions.
> Many small repos would be easy to handle for us, but OpenBMC may not
> want to have lots of small Google-specific repos in their org as this
> may make it more cumbersome for others to find the relevant repos that
> they're interested in.
Understood. On the other, with small repositories, they can only use the
parts they need.
> There's also overhead for the project maintainers to create the
> relevant groups and permissions for each new repo.
Please note, that Without knowing the contents of the repositories and
the size, this is all just my opinion. If the OpenBMC “admins“ can
easily create several repositories, I’d prefer that route. If it’s too
much work for them, their preference should be chosen.
Kind regards,
Paul
next prev parent reply other threads:[~2021-01-07 18:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-07 1:49 Upstreaming downstream Google BMC repositories Brandon Kim
2021-01-07 8:01 ` Paul Menzel
2021-01-07 17:33 ` Benjamin Fair
2021-01-07 18:25 ` Paul Menzel [this message]
2021-01-07 21:20 ` Ed Tanous
2021-01-11 21:13 ` Patrick Williams
2021-01-11 21:51 ` Ed Tanous
2021-01-14 23:17 ` Brandon Kim
2021-01-20 19:04 ` Ed Tanous
2021-01-30 22:19 ` Brad Bishop
2021-01-30 22:23 ` Ed Tanous
2021-02-01 2:21 ` Brandon Kim
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=711a5031-c774-4b03-6a6e-1f14d8699789@molgen.mpg.de \
--to=pmenzel@molgen.mpg.de \
--cc=benjaminfair@google.com \
--cc=brandonkim@google.com \
--cc=openbmc@lists.ozlabs.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.