Markus Armbruster <arm...@redhat.com> writes: > 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.
PS: By "now" I mean "before this series bit-rots", not "in time for 1.2".
