Mark Martin wrote: [... much snipped] > I think in the interest of learning the processes first, I'd like to > modify my request to just the bug id "6196126: svcs -xq" as this one > seems straight forward. I'll follow up after put-back with the rest if > they haven't been taken yet. I do have my own opinions on the "svcadm > enable -t" RFE because of personal preferences, so it may be interesting > to hash on that (but probably not right now -- Polaris is also occupying > time). > > If it makes it easier for sponsorship, I don't mind slicing and dicing > these any which way -- I'd rather make it easier on whomever. Fixing > minor or trivial bugs is still worthwhile for me.
From a sponsorship point of view, it doesn't really matter how you want to tackle them. The big place it matters is in terms of putback time. Fixes to small bugs can go back pretty quickly. Changes which require ARC take a little more time, and potentially controversial changes can take longer. Splitting them up or not is up to you -- depends on whether you're happy to wait to see the smaller stuff go in quickly or just do testing all in one go. I've got an ARC license, so am happy to sponsor you on any/all of these. I'll leave it to you to explicitly withdraw the request on request-sponsor for any of the individual bugs you don't want to start working on soon. I'll: - respond on request-sponsor - send you mail offline about drafting the ARC case for svcs -xq If you're still thinking about doing the svcadm start/stop work, I suggest starting a thread here with your proposal so that we can all discuss it. (One thing I'd encourage is considering aliasing it to enable/disable -st, not just -t.) liane
