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
