Fedora Board Recap 2009-12-17 UTC 1700

[Josh Boyer]

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 at redhat.com> 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