Hi Gabe,
I'd say that is not desirable. A few months ago one of my compression patches
assumed there was a virtual function called init() in the base class. Then, due
to naming conflicts this function was renamed to tagsInit() by another patch.
If my patch had had a verified +1, and I just kept rebasing, it would have
never been verified, which would have caused a build error if the change was
merged (the derived class would override an nonexistent init()).
This might not occur that often, and the fix is fairly easy, but I am not sure
if that is the only situation that such error might arise. I agree it is an
annoyance (mainly the spam on the mailing list), but unless there is a resource
problem (i.e., overly using the server) I think it is better to be safe.
Regards,Daniel
Em terça-feira, 30 de abril de 2019 20:50:45 GMT+2, Gutierrez, Anthony
<[email protected]> escreveu:
I am fine with this.
Tony
-----Original Message-----
From: gem5-dev <[email protected]> On Behalf Of Gabe Black
Sent: Monday, April 29, 2019 7:39 PM
To: gem5 Developer List <[email protected]>
Cc: Rahul Thakur <[email protected]>
Subject: Re: [gem5-dev] gerrit pickiness interacting with kokoro
[CAUTION: External Email]
Hello again. I asked the gurus, and they say we probably want to set content
merging to true. Any objections? I'd like to flip that switch before I go on my
trip, so by the end of the week.
Gabe
On Sat, Apr 27, 2019 at 5:09 PM Gabe Black <[email protected]> wrote:
> Hi folks. It's historically been an issue with gerrit as we have it
> set up for use in gem5 that it seems to be pretty picky about when a
> change can be submitted, and I've had to fairly often (but not always)
> perform a trivial rebase through the gerrit UI so that it's happy and
> will let me submit a CL. In the past this has been annoying, but not a
> big deal since it just takes a few clicks to placate gerrit.
>
> Now that we have kokoro running and verifying CLs (which is a very
> good thing), rebases have the unfortunate side effect of clearing the
> verified bit which necessitates running the CI again on essentially
> the same CL, including a several hour wait. So far this has been a
> bigger annoyance than before with the added latency getting a CL
> submitted, but since there haven't (yet) been any series with a lot of
> those delays stack on top of each other it hasn't been a huge problem.
>
> What I'd like to know is what people think about making gerrit less
> picky (not sure how that translates to settings TBH) so that these
> trivial rebases aren't as necessary. Looking at the settings, I see
> that the "Submit type" is "Rebase Always" and the "Allow content
> merges" setting is false. There are other settings, but these seem like the
> most relevant ones.
>
> This page takes a bit about the philosophy behind the submit type setting:
>
>
> https://gerrit-review.googlesource.com/Documentation/intro-project-own
> er.html
>
> With a more complete description of all the submit types over here:
>
>
> https://gerrit-review.googlesource.com/Documentation/config-project-co
> nfig.html#submit-type
>
> If people agree that this is something we should try to change, we can
> probably ask the gerrit gurus here at Google what settings we can
> adjust to get the desired effect.
>
> Gabe
>
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
