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
