I just went ahead and did it with git. I don't think going through the gerrit UI with the configuration as we have it now would have worked.
Gabe On Wed, Apr 1, 2020 at 3:21 AM Gabe Black <[email protected]> wrote: > That is definitely something that can (and has at least once) gone wrong, > but I know it can go wrong even with the current setup since it did :-) I'm > not 100% sure if this will work, but I tried to edit the configuration for > the label through the gerrit interface over here: > > https://gem5-review.googlesource.com/c/All-Projects/+/27330 > > I think it's still going to insist on the verification bit getting set on > that CL, but I don't think anything is going to pick it up and set that > bit... I might need to jam it in directly through git, or some other > hackery to make the actual change. > > Gabe > > On Wed, Apr 1, 2020 at 2:30 AM Giacomo Travaglini < > [email protected]> wrote: > >> Name clash is not the only scenario where you have conflicting patches. >> It might be that I have two patches targeting different portions of the >> code where I am not breaking the build but I am breaking simulation. >> Two patches that work on their own but they break gem5 once combined. >> >> This is just to be accurate; there are definitely downsides but >> considering the frequency of these cases I am fine on trying to reduce the >> computational load >> >> Giacomo >> >> -----Original Message----- >> From: gem5-dev <[email protected]> On Behalf Of Daniel Carvalho >> Sent: 01 April 2020 10:09 >> To: gem5 Developer List <[email protected]> >> Subject: Re: [gem5-dev] Making the verification bit sicky(ier) in gerrit >> >> I believe that in the case 2 changes from different people add a >> variable with the same name to the same scope, the rebase could still be >> trivial, yet the second change will generate a compilation error due to >> variable declaration repetition. Similar situations (variable removal, >> things being done twice, etc) could raise other compilation errors, and >> even runtime errors. >> Anyway, I think this is quite rare (IIRC, a compilation error like this >> happened only once since I joined), and it will be caught right away on the >> following kokoro run, so the benefits far outweigh any potential issue. >> Regards,Daniel >> Em quarta-feira, 1 de abril de 2020 06:57:27 GMT+2, Bobby Bruce < >> [email protected]> escreveu: >> >> Sounds like a great idea to me. I fail to see any downside. >> -- >> Dr. Bobby R. Bruce >> Room 2235, >> Kemper Hall, UC Davis >> Davis, >> CA, 95616 >> >> web: https://www.bobbybruce.net >> >> >> On Tue, Mar 31, 2020 at 7:03 PM Gabe Black <[email protected]> wrote: >> >> > Hi folks. I (and probably many of you) have noticed that gerrit >> > sometimes decides something needs to be rebased when it doesn't really >> > seem to, and that rebase ends up forcing a rerun of verification which >> > delays getting a patch checked in, and incurs extra cost for gem5 for >> > the compute resources which run the verification. >> > >> > I asked for potential solutions from the gerrit team within google, >> > and they suggested turning on this property of the verified label: >> > >> > >> > https://gerrit-review.googlesource.com/Documentation/config-labels.htm >> > l#label_copyAllScoresOnTrivialRebase >> > >> > They said that since we already have the "Rebase Always" merge >> > strategy selected it wouldn't reduce the level of verification for >> > changes, and while it wouldn't avoid having to do trivial rebases >> > (there's a button in gerrit for that), it would avoid having to rerun >> verification. >> > >> > Note that this would not make the verification label permanent, it >> > would just mean that as long as the rebase was trivial (no commit >> > message change, no diff change including context lines) then it would >> stay verified. >> > >> > Does that sound like a good idea to everyone? If so, I can look into >> > how to make that happen. >> > >> > 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 >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose the >> contents to any other person, use it for any purpose, or store or copy the >> information in any medium. Thank you. >> _______________________________________________ >> 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
