It's customary to send out a 'heads up' message along the lines of "the following patches have been on reviewboard for N days with no comments, so I'm going to commit them on <date> if no one speaks up in the meantime" (where date is ideally at least 24, preferably 48 or more hours in the future) just to give one more shot to people who may have missed the initial review request one last warning.
It's also nice to wait a certain minimum amount of time for reviews, e.g., the process with http://reviews.gem5.org/r/2527 where it looks like you got a single 'ship it' from Nilay a few hours after posting and then committed a few hours after that was pretty rushed---particularly since that whole sequence occurred during normal sleeping hours in the Pacific time zone---and didn't allow me to raise the issue about minimum python versions that really needs some discussion (regardless of how it falls out). It seems we should have some minimum time on review board as well as a maximum time. If everyone agrees that these informal customs should be made official, I can add them to the wiki. Steve On Sun, Nov 23, 2014 at 6:20 AM, Gabe Black via gem5-dev <[email protected]> wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2505/#review5524 > ----------------------------------------------------------- > > > Per the review process documentation on the wiki, if nobody comments on > this or asks me to wait after 10 days, I'm going to commit this as is. > > - Gabe Black > > > On Nov. 17, 2014, 6:42 a.m., Gabe Black wrote: > > > > ----------------------------------------------------------- > > This is an automatically generated e-mail. To reply, visit: > > http://reviews.gem5.org/r/2505/ > > ----------------------------------------------------------- > > > > (Updated Nov. 17, 2014, 6:42 a.m.) > > > > > > Review request for Default. > > > > > > Repository: gem5 > > > > > > Description > > ------- > > > > Changeset 10539:db6cb6e4303b > > --------------------------- > > ISA: Allow named constants as decode case values. > > > > The values in a "bitfield" or in an ExtMachInst structure member may not > be a > > literal value, it might select from an arbitrary collection of options. > Instead > > of using the raw value of those constants in the decoder, it's easier to > tell > > what's going on if they can be referred to as a symbolic constant/enum. > > > > To support that, the ISA description language is extended slightly so > that in > > addition to integer literals, the case value for decode blobs can also > be a > > string literal. It's up to the ISA author to ensure that the string > evaluates > > to a legal constant value when interpretted as C++. > > > > > > Diffs > > ----- > > > > src/arch/isa_parser.py 1a9e235cab09e37837819876d28fbd2914a47291 > > > > Diff: http://reviews.gem5.org/r/2505/diff/ > > > > > > Testing > > ------- > > > > > > Thanks, > > > > Gabe Black > > > > > > _______________________________________________ > 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
