On Sat, Dec 19, 2009 at 04:13:17PM -0500, William Jon McCann wrote: >Hey Mike, > >On Sat, Dec 19, 2009 at 3:29 PM, Mike McGrath <mmcgrath@xxxxxxxxxx> wrote: >> On Sat, 19 Dec 2009, William Jon McCann wrote: >> >>> > The whiteboard: >>> > >>> > https://fedoraproject.org/wiki/Desktop/Whiteboards/UpdateExperience >>> > >>> > is almost entirely FESCo or other team based. >>> >>> Exactly, the Chairman of board doesn't seem to agree with that. I >> >> It's not getting you anywhere and bad it's form. Besides, just because >> someone agrees with you (or me) doesn't make it so. If you're not alone >> on this, have them come and speak up and be willing to let them do that. >> Otherwise stick to what you think on your own. When the whiteboard was >> brought up to the FAB in October [1] it was met with complete silence. > >People should step forward on their own, I agree. Similarly I'd like >the folks on the board go on the record and state publicly what parts >of the proposal that they disagree with. That would help me >understand where the points of disagreement actually are. Because >those folks didn't bring up specific issues at FUDCon, on the list, or >in the board meeting. That isn't entirely true. I brought up the fact that the proposal doesn't address one of the primary causes of such a bad experience, and that is that we have almost no coherency among what we consider acceptable for a stable update, and when it's pushed. While it's certainly something the submitters of the proposal shouldn't be tasked with solving, the proposal does presume to express when and how updates get pushed without any insight into the difficulties with that. This lined up exactly with Spot's point that the proposal should be broken into separate, more managable pieces. There is a lot of overlap in there with things like AutoQA, the CritPath management, etc. Personally, I'd like to see the proposal boiled down into what is envisioned for the end user update design interaction. Also, I suggested during the meeting that Board members discuss implementation details on this list, and not during the meeting. Whether that is the reason you didn't get specific technical feedback on many portions or not, I have no idea. However it certainly is _not_ because there are no issues or some kind of silent agreement. Now, since you asked, here are my current objections to the implementation details on the Whiteboard page. I will start by saying I am under the assumption that the presentation portions of this are referring to PackageKit, or some other graphical package manager. If this implies that today's basic yum functionality needs to change, I would have major objections to that. - Overlap with the critpath and AutoQA work. The 'Testing' section at the bottom has a very limited set of things that are all in the critical path, but it is certainly not complete and overlaps the effort there entirely. Also, the sections on testing essentially describe what AutoQA is going to accomplish. Both of these have already been proposed and approved. This proposal doesn't need to rehash them. - "Users should be able to detect updates from within the application they are running." This seems both overreaching and fairly difficult to implement. I don't think patching applications to query for an update to themselves is a good idea. Also, getting update notification from multiple apps and a graphical package manager would be really annoying. - Non-interactive update installation. My only issue is if this was forced on and/or not configurable. If users can opt into it, I have no problems. - Apply updates at shutdown. Again, if this is a configurable, opt in option I have no problems. If not, I certainly don't want to wait for my laptop to install 60MiB of updates when I tell it to shutdown as I'm leaving a coffee shop. - System updates can only be defered for a short time. I would like more information as to why this is good. I certainly don't need to update e.g. grub on my non-EFI machine if the update only fixes an EFI related bug. I also have some concerns on your proposed weekly stable update releases. How does that apply to the updates testing repository? How does it apply to entirely new packages that are pushed to a stable release? Personally, I would like to see these kind of issues broken out into a separate proposal and worked through FESCo. I'd be happy to discuss it with you if you and your team would like. josh _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
