Anthony Liguori <anth...@codemonkey.ws> writes: > Markus Armbruster <arm...@redhat.com> writes: > >> Anthony Liguori <anth...@codemonkey.ws> writes: >> >>> Peter Maydell <peter.mayd...@linaro.org> writes: >>> >>>> On 15 August 2012 20:25, Alexander Graf <ag...@suse.de> wrote: >>>>> On 15.08.2012, at 21:17, Markus Armbruster wrote: >>>>> >>>>>> We create a number of default drives for machines to use: floppy, >>>>>> CD-ROM, SD card. Machines can suppress the ones they don't use, but >>>>>> few do. Fix that. >>>> >>>>>> v2: >>>>>> Make default drives opt-in instead of opt-out for boards (Andreas) >>>>>> Cover new target unicore32 >>>>>> Bonus fix for unicore32 -M puv3 without -kernel >>>>>> Cover mpc8544ds, pseries (missed in v1) >>>>> >>>>> Nack from my POV. Too late for 1.2. Better get this in early for 1.3. >> >> What's the risk? >> >> For the record, I tested every single machine to make sure it still gets >> default drives for any drive it uses. >> >>> No, it's not too late for 1.2. >>> >>> The release process is pretty clear. Major features needed to be posted >>> before August 1st. The late to get non-bug fixes in is today. >>> >>> This is not a major feature but more importantly, has gone through a few >>> revisions and has gotten positive review comments. >>> >>> So let's not just go around declaring things as being "too late". If >>> something needs more review or hasn't gotten adequate review, it's >>> perfectly acceptable to point that out. But please don't just Nack and >>> say it's too late. >>> >>>> Agree. I also think we should follow up Paul Brook's suggestion >>>> that we don't need to have any kind of "default sd card" flag >>>> at all. Floppy is weird because we don't properly separate out >>>> the drive and the controller, right? Not sure about cdrom... >>> >>> This is a valid critique and suggests that more review is needed. >>> Given that, I won't pick this up today. But let's not throw around >>> Nacks without justification. >> >> Paul's idea is worth pursuing. But I don't think we should reject a >> improvement we can have now just we can imagine an even nicer >> improvement we may have some day. Taking the former now doesn't make >> the latter any harder. > > If doing it a different way means touching 50 files again, then it's > best not to rush into that. There is something to be said to for > avoiding unnecessary churn.
Three cases: 1. Reject my small improvement now, take the nicer improvement later. 2. Take the small improvement now, take the nicer improvement later. The latter has to remove 94 lines ".no_FOO = 1" it wouldn't have to in case 1. BFD. 3. Reject the small improvement now, nicer improvement fails to materialize. I think you're exaggerating the 2's drawback and ignoring 3's.
