Making the "new repo" requests go faster

Making the "new repo" requests go faster

[Ed Tanous]

An issue I've seen in the past with adding new repositories, is there:
1. Isn't a clear place to push code reviews for something "new".
2. The project quality/CI/formatting rules aren't really enforced
until after you request a repo, then push code to it.
3. Setting up a new daemon with CI/build is non-trivial, and has sharp edges.
4. "state of the art" build constantly changes (make -> autotools ->
cmake -> meson, clang-format, clang-tidy, shellcheck, cppcheck,
service file location, ect).

In an effort to fix these issues and more, I'd like to propose
creating a new repository for a "new daemon" template.  The hope would
be that we can centralize a single set of "current state of the art"
guidelines in such a way that they're usable more than just checking
them into documentation.  Initially, template repo would contain:

1. A meson file, that compiles a "hello world" dbus application that
requests a name.
2. All the relevant .clang-tidy, .clang-format, and cppcheck files
required to ensure that CI is testing as much as we can.
3. Unit tests
4. Pre-integrated repo CI.

The end goal of this would be that when new code is created, whomever
was looking for a new repository could push a gerrit review to this
"template repo" and the CI could ensure that it met the automated
quality requirements long before any maintainer actually reviewed it.
This would likely reduce the time it takes to propose "I want to add a
new repo" and make a procedure for doing it a lot more concrete than
sending an email to the mailing list.

As part of this, I'd also want to deprecate and remove the .clang-tidy
and .clang-format that are present in the docs repo, and supersede
them with the files in the new repo, such that any changes to the CI
infrastructure could be proposed on the template repo first.

FWIW, I take no credit for the above idea, I 100% stole it from James
Feist, who thought through the broad strokes of this a while back when
we were talking about how to move new initiatives along faster without
burdening maintainers.

I'd love feedback.  Do others think this worth doing?

-Ed

Re: Making the "new repo" requests go faster

[Brad Bishop]

On Fri, Feb 05, 2021 at 12:02:31PM -0800, Ed Tanous wrote:
>An issue I've seen in the past with adding new repositories, is there:
>1. Isn't a clear place to push code reviews for something "new".
>2. The project quality/CI/formatting rules aren't really enforced
>until after you request a repo, then push code to it.
>3. Setting up a new daemon with CI/build is non-trivial, and has sharp edges.
>4. "state of the art" build constantly changes (make -> autotools ->
>cmake -> meson, clang-format, clang-tidy, shellcheck, cppcheck,
>service file location, ect).
>
>In an effort to fix these issues and more, I'd like to propose
>creating a new repository for a "new daemon" template.  The hope would
>be that we can centralize a single set of "current state of the art"
>guidelines in such a way that they're usable more than just checking
>them into documentation.  Initially, template repo would contain:
>
>1. A meson file, that compiles a "hello world" dbus application that
>requests a name.
>2. All the relevant .clang-tidy, .clang-format, and cppcheck files
>required to ensure that CI is testing as much as we can.
>3. Unit tests
>4. Pre-integrated repo CI.
>
>The end goal of this would be that when new code is created, whomever
>was looking for a new repository could push a gerrit review to this
>"template repo" and the CI could ensure that it met the automated
>quality requirements long before any maintainer actually reviewed it.
>This would likely reduce the time it takes to propose "I want to add a
>new repo" and make a procedure for doing it a lot more concrete than
>sending an email to the mailing list.
>
>As part of this, I'd also want to deprecate and remove the .clang-tidy
>and .clang-format that are present in the docs repo, and supersede
>them with the files in the new repo, such that any changes to the CI
>infrastructure could be proposed on the template repo first.
>
>FWIW, I take no credit for the above idea, I 100% stole it from James
>Feist, who thought through the broad strokes of this a while back when
>we were talking about how to move new initiatives along faster without
>burdening maintainers.
>
>I'd love feedback.  Do others think this worth doing?

Yes!

These are all great ideas.  Thanks for tackling this.

Since I'm the only one with the right gerrit/github authority to create 
repos, I've obviously been the cause of the delay (there are others that 
can but this isn't really something they'd be comfortable doing).

For the record, making new repos from a logistics point of view is not 
hard and not any sort of burden on me.  I'm happy to do that.

I don't know if this is a good excuse or not, but I just want to say 
that in a some of the past cases making the repository took so long 
simply because there did not seem to be any clear consensus on whether 
the new repo was good or bad for OpenBMC.  When you combine that with 
the fact that I'm not really good at making unilateral decisions, many 
times the result was "analysis paralysis" on my part.  This is a big 
part of why I'm creating and excited about this: 

https://lore.kernel.org/openbmc/20210111220919.zwc727vbwc4itm7h@thinkpad.fuzziesquirrel.com/#t

-brad

Re: Making the "new repo" requests go faster

[Bills, Jason M]

On 2/5/2021 12:02 PM, Ed Tanous wrote:
> An issue I've seen in the past with adding new repositories, is there:
> 1. Isn't a clear place to push code reviews for something "new".
> 2. The project quality/CI/formatting rules aren't really enforced
> until after you request a repo, then push code to it.
> 3. Setting up a new daemon with CI/build is non-trivial, and has sharp edges.
> 4. "state of the art" build constantly changes (make -> autotools ->
> cmake -> meson, clang-format, clang-tidy, shellcheck, cppcheck,
> service file location, ect).
> 
> In an effort to fix these issues and more, I'd like to propose
> creating a new repository for a "new daemon" template.  The hope would
> be that we can centralize a single set of "current state of the art"
> guidelines in such a way that they're usable more than just checking
> them into documentation.  Initially, template repo would contain:
> 
> 1. A meson file, that compiles a "hello world" dbus application that
> requests a name.
> 2. All the relevant .clang-tidy, .clang-format, and cppcheck files
> required to ensure that CI is testing as much as we can.
> 3. Unit tests
> 4. Pre-integrated repo CI.

+1 on this.  This would be very helpful for knowing how to set things up 
with the latest set of tools.  I know in a crunch, I would tend to leave 
some of these things out because I don't know how to get started on them.

In the future, it would also be nice to expand on the basics with some 
common enhancements such as build options in meson.

> 
> The end goal of this would be that when new code is created, whomever
> was looking for a new repository could push a gerrit review to this
> "template repo" and the CI could ensure that it met the automated
> quality requirements long before any maintainer actually reviewed it.
> This would likely reduce the time it takes to propose "I want to add a
> new repo" and make a procedure for doing it a lot more concrete than
> sending an email to the mailing list.
> 
> As part of this, I'd also want to deprecate and remove the .clang-tidy
> and .clang-format that are present in the docs repo, and supersede
> them with the files in the new repo, such that any changes to the CI
> infrastructure could be proposed on the template repo first.
> 
> FWIW, I take no credit for the above idea, I 100% stole it from James
> Feist, who thought through the broad strokes of this a while back when
> we were talking about how to move new initiatives along faster without
> burdening maintainers.
> 
> I'd love feedback.  Do others think this worth doing?
> 
> -Ed
> 

Re: Making the "new repo" requests go faster

[Ed Tanous]

On Fri, Feb 5, 2021 at 12:58 PM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
>
> On Fri, Feb 05, 2021 at 12:02:31PM -0800, Ed Tanous wrote:
> >An issue I've seen in the past with adding new repositories, is there:
> >1. Isn't a clear place to push code reviews for something "new".
> >2. The project quality/CI/formatting rules aren't really enforced
> >until after you request a repo, then push code to it.
> >3. Setting up a new daemon with CI/build is non-trivial, and has sharp edges.
> >4. "state of the art" build constantly changes (make -> autotools ->
> >cmake -> meson, clang-format, clang-tidy, shellcheck, cppcheck,
> >service file location, ect).
> >
> >In an effort to fix these issues and more, I'd like to propose
> >creating a new repository for a "new daemon" template.  The hope would
> >be that we can centralize a single set of "current state of the art"
> >guidelines in such a way that they're usable more than just checking
> >them into documentation.  Initially, template repo would contain:
> >
> >1. A meson file, that compiles a "hello world" dbus application that
> >requests a name.
> >2. All the relevant .clang-tidy, .clang-format, and cppcheck files
> >required to ensure that CI is testing as much as we can.
> >3. Unit tests
> >4. Pre-integrated repo CI.
> >
> >The end goal of this would be that when new code is created, whomever
> >was looking for a new repository could push a gerrit review to this
> >"template repo" and the CI could ensure that it met the automated
> >quality requirements long before any maintainer actually reviewed it.
> >This would likely reduce the time it takes to propose "I want to add a
> >new repo" and make a procedure for doing it a lot more concrete than
> >sending an email to the mailing list.
> >
> >As part of this, I'd also want to deprecate and remove the .clang-tidy
> >and .clang-format that are present in the docs repo, and supersede
> >them with the files in the new repo, such that any changes to the CI
> >infrastructure could be proposed on the template repo first.
> >
> >FWIW, I take no credit for the above idea, I 100% stole it from James
> >Feist, who thought through the broad strokes of this a while back when
> >we were talking about how to move new initiatives along faster without
> >burdening maintainers.
> >
> >I'd love feedback.  Do others think this worth doing?
>
> Yes!
>
> These are all great ideas.  Thanks for tackling this.
>
> Since I'm the only one with the right gerrit/github authority to create
> repos, I've obviously been the cause of the delay (there are others that
> can but this isn't really something they'd be comfortable doing).
>
> For the record, making new repos from a logistics point of view is not
> hard and not any sort of burden on me.  I'm happy to do that.
>
> I don't know if this is a good excuse or not, but I just want to say
> that in a some of the past cases making the repository took so long
> simply because there did not seem to be any clear consensus on whether
> the new repo was good or bad for OpenBMC.  When you combine that with
> the fact that I'm not really good at making unilateral decisions, many
> times the result was "analysis paralysis" on my part.  This is a big
> part of why I'm creating and excited about this:

In a lot of these cases the community consensus is really hard because
there's no code to look at, just a short description of what could
theoretically go in that repo.  I think a lot of that becomes easier
if we invert the model, as we can talk in concrete technical terms,
coordinate on gerrit, and have the recipes up and building so others
can determine their utility long before the repo is created.

>
> https://lore.kernel.org/openbmc/20210111220919.zwc727vbwc4itm7h@thinkpad.fuzziesquirrel.com/#t
>

I think this will help a ton as well.

> -brad

Re: Making the "new repo" requests go faster

[Ed Tanous]

On Mon, Feb 8, 2021 at 9:29 AM Bills, Jason M
<jason.m.bills@linux.intel.com> wrote:
>
>
>
> On 2/5/2021 12:02 PM, Ed Tanous wrote:
> > An issue I've seen in the past with adding new repositories, is there:
> > 1. Isn't a clear place to push code reviews for something "new".
> > 2. The project quality/CI/formatting rules aren't really enforced
> > until after you request a repo, then push code to it.
> > 3. Setting up a new daemon with CI/build is non-trivial, and has sharp edges.
> > 4. "state of the art" build constantly changes (make -> autotools ->
> > cmake -> meson, clang-format, clang-tidy, shellcheck, cppcheck,
> > service file location, ect).
> >
> > In an effort to fix these issues and more, I'd like to propose
> > creating a new repository for a "new daemon" template.  The hope would
> > be that we can centralize a single set of "current state of the art"
> > guidelines in such a way that they're usable more than just checking
> > them into documentation.  Initially, template repo would contain:
> >
> > 1. A meson file, that compiles a "hello world" dbus application that
> > requests a name.
> > 2. All the relevant .clang-tidy, .clang-format, and cppcheck files
> > required to ensure that CI is testing as much as we can.
> > 3. Unit tests
> > 4. Pre-integrated repo CI.
>
> +1 on this.  This would be very helpful for knowing how to set things up
> with the latest set of tools.  I know in a crunch, I would tend to leave
> some of these things out because I don't know how to get started on them.
>
> In the future, it would also be nice to expand on the basics with some
> common enhancements such as build options in meson.

Good idea.

>
> >
> > The end goal of this would be that when new code is created, whomever
> > was looking for a new repository could push a gerrit review to this
> > "template repo" and the CI could ensure that it met the automated
> > quality requirements long before any maintainer actually reviewed it.
> > This would likely reduce the time it takes to propose "I want to add a
> > new repo" and make a procedure for doing it a lot more concrete than
> > sending an email to the mailing list.
> >
> > As part of this, I'd also want to deprecate and remove the .clang-tidy
> > and .clang-format that are present in the docs repo, and supersede
> > them with the files in the new repo, such that any changes to the CI
> > infrastructure could be proposed on the template repo first.
> >
> > FWIW, I take no credit for the above idea, I 100% stole it from James
> > Feist, who thought through the broad strokes of this a while back when
> > we were talking about how to move new initiatives along faster without
> > burdening maintainers.
> >
> > I'd love feedback.  Do others think this worth doing?
> >
> > -Ed
> >

Re: Making the "new repo" requests go faster

[Ed Tanous]

On Fri, Feb 5, 2021 at 12:02 PM Ed Tanous <ed@tanous.net> wrote:
>
> An issue I've seen in the past with adding new repositories, is there:
> 1. Isn't a clear place to push code reviews for something "new".
> 2. The project quality/CI/formatting rules aren't really enforced
> until after you request a repo, then push code to it.
> 3. Setting up a new daemon with CI/build is non-trivial, and has sharp edges.
> 4. "state of the art" build constantly changes (make -> autotools ->
> cmake -> meson, clang-format, clang-tidy, shellcheck, cppcheck,
> service file location, ect).
>
> In an effort to fix these issues and more, I'd like to propose
> creating a new repository for a "new daemon" template.  The hope would
> be that we can centralize a single set of "current state of the art"
> guidelines in such a way that they're usable more than just checking
> them into documentation.  Initially, template repo would contain:
>
> 1. A meson file, that compiles a "hello world" dbus application that
> requests a name.
> 2. All the relevant .clang-tidy, .clang-format, and cppcheck files
> required to ensure that CI is testing as much as we can.
> 3. Unit tests
> 4. Pre-integrated repo CI.
>
> The end goal of this would be that when new code is created, whomever
> was looking for a new repository could push a gerrit review to this
> "template repo" and the CI could ensure that it met the automated
> quality requirements long before any maintainer actually reviewed it.
> This would likely reduce the time it takes to propose "I want to add a
> new repo" and make a procedure for doing it a lot more concrete than
> sending an email to the mailing list.
>
> As part of this, I'd also want to deprecate and remove the .clang-tidy
> and .clang-format that are present in the docs repo, and supersede
> them with the files in the new repo, such that any changes to the CI
> infrastructure could be proposed on the template repo first.
>
> FWIW, I take no credit for the above idea, I 100% stole it from James
> Feist, who thought through the broad strokes of this a while back when
> we were talking about how to move new initiatives along faster without
> burdening maintainers.
>

If anyone is following this thread still, patches have been pushed to
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/41099 for the
moment.  As they get closer to approval, I'd like to get a new
template repo created to house the code contained in that patch, and
CI setup on said repo if I could.

> I'd love feedback.  Do others think this worth doing?
>
> -Ed

Re: Making the "new repo" requests go faster

[Brad Bishop]

On Fri, Mar 05, 2021 at 11:02:24AM -0800, Ed Tanous wrote:
>On Fri, Feb 5, 2021 at 12:02 PM Ed Tanous <ed@tanous.net> wrote:
>>
>> In an effort to fix these issues and more, I'd like to propose
>> creating a new repository for a "new daemon" template.
>
>If anyone is following this thread still, patches have been pushed to
>https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/41099 for the
>moment.  As they get closer to approval, I'd like to get a new
>template repo created to house the code contained in that patch, and
>CI setup on said repo if I could.

Thanks Ed!

The only reason I haven't created this already was I wasn't sure what to 
call it.  Any ideas on a name out there?

-brad

Re: Making the "new repo" requests go faster

[Ed Tanous]

On Tue, Mar 9, 2021 at 5:57 AM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
>
> On Fri, Mar 05, 2021 at 11:02:24AM -0800, Ed Tanous wrote:
> >On Fri, Feb 5, 2021 at 12:02 PM Ed Tanous <ed@tanous.net> wrote:
> >>
> >> In an effort to fix these issues and more, I'd like to propose
> >> creating a new repository for a "new daemon" template.
> >
> >If anyone is following this thread still, patches have been pushed to
> >https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/41099 for the
> >moment.  As they get closer to approval, I'd like to get a new
> >template repo created to house the code contained in that patch, and
> >CI setup on said repo if I could.
>
> Thanks Ed!
>
> The only reason I haven't created this already was I wasn't sure what to
> call it.  Any ideas on a name out there?

No worries.  I don't really have a strong opinion on what it's called
either.  The ideas I've had so far were "Sample app" or "example app".

>
> -brad

RE: Making the "new repo" requests go faster

[Milton Miller II]

On March 9, Brad Bishop wrote:
>On Tue, Mar 9, 2021 at 5:57 AM Brad Bishop
><bradleyb@fuzziesquirrel.com> wrote:
>> On Fri, Mar 05, 2021 at 11:02:24AM -0800, Ed Tanous wrote:
>> >On Fri, Feb 5, 2021 at 12:02 PM Ed Tanous <ed@tanous.net> wrote:
>> >>
>> >> In an effort to fix these issues and more, I'd like to propose
>> >> creating a new repository for a "new daemon" template.
>> >
>> >If anyone is following this thread still, patches have been pushed
>> >to
>> >https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/41099   for the
>> >moment.  As they get closer to approval, I'd like to get a new
>> >template repo created to house the code contained in that patch,
>> >and
>> >CI setup on said repo if I could.
>>
>> Thanks Ed!
>>
>> The only reason I haven't created this already was I wasn't sure
>> what to
>> call it.  Any ideas on a name out there?
>
>No worries.  I don't really have a strong opinion on what it's called
>either.  The ideas I've had so far were "Sample app" or "example
>app".


One thing I wanted to point out when we are adopting this.

Git has a feature that it purposely checks the oldest ancestor of
the target repository against the source repository.  This is a
check that helps prevent pushing an unrelated tree.

From the git push man page:

       -f, --force
           Usually, the command refuses to update a remote ref that is not an
           ancestor of the local ref used to overwrite it. This flag disables
           the check. This can cause the remote repository to lose commits;
           use it with care.


If we give instructions to rebase the commits when creating a new 
repository the new commit time and/or committer will cause a unique 
hash and we will not defeat this check.

milton

Re: Making the "new repo" requests go faster

[Ed Tanous]

On Tue, Mar 9, 2021 at 9:32 AM Milton Miller II <miltonm@us.ibm.com> wrote:
>
> On March 9, Brad Bishop wrote:
> >On Tue, Mar 9, 2021 at 5:57 AM Brad Bishop
> ><bradleyb@fuzziesquirrel.com> wrote:
> >> On Fri, Mar 05, 2021 at 11:02:24AM -0800, Ed Tanous wrote:
> >> >On Fri, Feb 5, 2021 at 12:02 PM Ed Tanous <ed@tanous.net> wrote:
> >> >>
> >> >> In an effort to fix these issues and more, I'd like to propose
> >> >> creating a new repository for a "new daemon" template.
> >> >
> >> >If anyone is following this thread still, patches have been pushed
> >> >to
> >> >https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/41099   for the
> >> >moment.  As they get closer to approval, I'd like to get a new
> >> >template repo created to house the code contained in that patch,
> >> >and
> >> >CI setup on said repo if I could.
> >>
> >> Thanks Ed!
> >>
> >> The only reason I haven't created this already was I wasn't sure
> >> what to
> >> call it.  Any ideas on a name out there?
> >
> >No worries.  I don't really have a strong opinion on what it's called
> >either.  The ideas I've had so far were "Sample app" or "example
> >app".
>
>
> One thing I wanted to point out when we are adopting this.
>
> Git has a feature that it purposely checks the oldest ancestor of
> the target repository against the source repository.  This is a
> check that helps prevent pushing an unrelated tree.
>
> From the git push man page:
>
>        -f, --force
>            Usually, the command refuses to update a remote ref that is not an
>            ancestor of the local ref used to overwrite it. This flag disables
>            the check. This can cause the remote repository to lose commits;
>            use it with care.
>
>
> If we give instructions to rebase the commits when creating a new
> repository the new commit time and/or committer will cause a unique
> hash and we will not defeat this check.

I'm not really following why this would be a concern for this kind of
thing.  Sure, force push is a big hammer, and should be used with
discretion and care, but I'm not seeing why we would ever have that
problem on a new repo, regardless of if we squashed the template repo
history (which would be my preference as the template repo history is
irrelevant to a new repo) or whether we pushed it as-is with the
template repo history.  I can't think of a workflow where we would
rebase, but maybe I'm missing something?

Can you elaborate on what the exact concern is?

>
> milton
>

RE: Making the "new repo" requests go faster

[Milton Miller II]

On March 9, Ed Tanous <ed@tanous.net> wrote:
>On Tue, Mar 9, 2021 at 9:32 AM Milton Miller II <miltonm@us.ibm.com>
>wrote:
>>
>> On March 9, Brad Bishop wrote:
>> >On Tue, Mar 9, 2021 at 5:57 AM Brad Bishop
>> ><bradleyb@fuzziesquirrel.com> wrote:
>> >> On Fri, Mar 05, 2021 at 11:02:24AM -0800, Ed Tanous wrote:
>> >> >On Fri, Feb 5, 2021 at 12:02 PM Ed Tanous <ed@tanous.net>
>wrote:
>> >> >>
>> >> >> In an effort to fix these issues and more, I'd like to
>propose
>> >> >> creating a new repository for a "new daemon" template.
>> >> >
>> >> >If anyone is following this thread still, patches have been
>pushed
>> >> >to
>> >>
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.openbmc-
>2Dproject.xyz_c_openbmc_docs_-2B_41099&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1
>ZOg&r=bvv7AJEECoRKBU02rcu4F5DWd-EwX8As2xrXeO9ZSo4&m=zOJQ8qDYu5wBWzKub
>6P9N-WKFD3SB3DdgsAsegfH5xQ&s=iLLTE_nLMY6TUpL-Q4U6xtZoUdNkXSDwdlMskft8
>vIU&e=    for the
>> >> >moment.  As they get closer to approval, I'd like to get a new
>> >> >template repo created to house the code contained in that
>patch,
>> >> >and
>> >> >CI setup on said repo if I could.
>> >>
>> >> Thanks Ed!
>> >>
>> >> The only reason I haven't created this already was I wasn't sure
>> >> what to
>> >> call it.  Any ideas on a name out there?
>> >
>> >No worries.  I don't really have a strong opinion on what it's
>called
>> >either.  The ideas I've had so far were "Sample app" or "example
>> >app".
>>
>>
>> One thing I wanted to point out when we are adopting this.
>>
>> Git has a feature that it purposely checks the oldest ancestor of
>> the target repository against the source repository.  This is a
>> check that helps prevent pushing an unrelated tree.
>>
>> From the git push man page:
>>
>>        -f, --force
>>            Usually, the command refuses to update a remote ref that
>is not an
>>            ancestor of the local ref used to overwrite it. This
>flag disables
>>            the check. This can cause the remote repository to lose
>commits;
>>            use it with care.
>>
>>
>> If we give instructions to rebase the commits when creating a new
>> repository the new commit time and/or committer will cause a unique
>> hash and we will not defeat this check.
>
>I'm not really following why this would be a concern for this kind of
>thing.  Sure, force push is a big hammer, and should be used with
>discretion and care, but I'm not seeing why we would ever have that
>problem on a new repo, regardless of if we squashed the template repo
>history (which would be my preference as the template repo history is
>irrelevant to a new repo) or whether we pushed it as-is with the
>template repo history.  I can't think of a workflow where we would
>rebase, but maybe I'm missing something?
>
>Can you elaborate on what the exact concern is?

User starts with template repository and adds content for app A.

User starts with template repository adding files for content B.

User accidentlly recalls pull command for repository A when 
working in repository B.

If the commits were rebased git complains.

If the repositories share a common ancestor then the content 
of A is merged into repository B.  At a minimum the user has 
unrelated content to purge.  In a worse case the content of 
the second repository is relatively small and doesn't get 
caught in the review process.

Rebasing to get an updated commit time allows this check to 
remain effective.   The Author history including timestamps 
can be preserved.

I thought about saying merge this into your repository would 
work but then I realized there is a common ancestor in the 
middle which may defeat the checking.

milton

Re: Making the "new repo" requests go faster

[Ed Tanous]

On Tue, Mar 9, 2021 at 10:24 AM Milton Miller II <miltonm@us.ibm.com> wrote:
>
> On March 9, Ed Tanous <ed@tanous.net> wrote:
> >On Tue, Mar 9, 2021 at 9:32 AM Milton Miller II <miltonm@us.ibm.com>
> >wrote:
> >>
> >> On March 9, Brad Bishop wrote:
> >> >On Tue, Mar 9, 2021 at 5:57 AM Brad Bishop
> >> ><bradleyb@fuzziesquirrel.com> wrote:
> >> >> On Fri, Mar 05, 2021 at 11:02:24AM -0800, Ed Tanous wrote:
> >> >> >On Fri, Feb 5, 2021 at 12:02 PM Ed Tanous <ed@tanous.net>
> >wrote:
> >> >> >>
> >> >> >> In an effort to fix these issues and more, I'd like to
> >propose
> >> >> >> creating a new repository for a "new daemon" template.
> >> >> >
> >> >> >If anyone is following this thread still, patches have been
> >pushed
> >> >> >to
> >> >>
> >>https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.openbmc-
> >2Dproject.xyz_c_openbmc_docs_-2B_41099&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1
> >ZOg&r=bvv7AJEECoRKBU02rcu4F5DWd-EwX8As2xrXeO9ZSo4&m=zOJQ8qDYu5wBWzKub
> >6P9N-WKFD3SB3DdgsAsegfH5xQ&s=iLLTE_nLMY6TUpL-Q4U6xtZoUdNkXSDwdlMskft8
> >vIU&e=    for the
> >> >> >moment.  As they get closer to approval, I'd like to get a new
> >> >> >template repo created to house the code contained in that
> >patch,
> >> >> >and
> >> >> >CI setup on said repo if I could.
> >> >>
> >> >> Thanks Ed!
> >> >>
> >> >> The only reason I haven't created this already was I wasn't sure
> >> >> what to
> >> >> call it.  Any ideas on a name out there?
> >> >
> >> >No worries.  I don't really have a strong opinion on what it's
> >called
> >> >either.  The ideas I've had so far were "Sample app" or "example
> >> >app".
> >>
> >>
> >> One thing I wanted to point out when we are adopting this.
> >>
> >> Git has a feature that it purposely checks the oldest ancestor of
> >> the target repository against the source repository.  This is a
> >> check that helps prevent pushing an unrelated tree.
> >>
> >> From the git push man page:
> >>
> >>        -f, --force
> >>            Usually, the command refuses to update a remote ref that
> >is not an
> >>            ancestor of the local ref used to overwrite it. This
> >flag disables
> >>            the check. This can cause the remote repository to lose
> >commits;
> >>            use it with care.
> >>
> >>
> >> If we give instructions to rebase the commits when creating a new
> >> repository the new commit time and/or committer will cause a unique
> >> hash and we will not defeat this check.
> >
> >I'm not really following why this would be a concern for this kind of
> >thing.  Sure, force push is a big hammer, and should be used with
> >discretion and care, but I'm not seeing why we would ever have that
> >problem on a new repo, regardless of if we squashed the template repo
> >history (which would be my preference as the template repo history is
> >irrelevant to a new repo) or whether we pushed it as-is with the
> >template repo history.  I can't think of a workflow where we would
> >rebase, but maybe I'm missing something?
> >
> >Can you elaborate on what the exact concern is?
>
> User starts with template repository and adds content for app A.
>
> User starts with template repository adding files for content B.
>
> User accidentlly recalls pull command for repository A when
> working in repository B.
>
> If the commits were rebased git complains.

I think I get this, this would really only be a concern for whomever
is writing commit 1, right?  Presumably everyone else would be cloning
from the new repo, which would have a completely disparate history.
Hopefully nobody else is pulling directly from the template repo.
Based on the MAINTAINERS files, the gerrit admins would retain control
on the repo until the MAINTAINERS file is pushed, and are hopefully
schooled enough to avoid this kind of thing.

>
> If the repositories share a common ancestor then the content
> of A is merged into repository B.  At a minimum the user has
> unrelated content to purge.  In a worse case the content of
> the second repository is relatively small and doesn't get
> caught in the review process.

In theory the only changes they'd get here would be if we update the
template repo, in which case, we probably want the changes in the new
thing?

>
> Rebasing to get an updated commit time allows this check to
> remain effective.   The Author history including timestamps
> can be preserved.
>
> I thought about saying merge this into your repository would
> work but then I realized there is a common ancestor in the
> middle which may defeat the checking.
>

Overall, yeah, this a concern, but I'm not sure what we can do about
it to mechanically limit it from happening in git;  If there's any way
we can structure the template repo to avoid this, I'm open to
suggestions.  When I add the readme to the commit (coming soon) I'll
be sure to put renaming the origin remote as one of the steps.

> milton
>