FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Advisory Board

 
 
LinkBack Thread Tools
 
Old 12-19-2009, 08:59 PM
Bruno Wolff III
 
Default Fedora Board Recap 2009-12-17 UTC 1700

On Sat, Dec 19, 2009 at 15:12:19 -0600,
Bruno Wolff III <bruno@wolff.to> wrote:
>
> There are also different causes of brokenness. Some is brokenness within
> a package or small set of packages because of sloppiness. That shouldn't
> really be happening and is definitely not desireable. Some is caused by
> a change in a subsystem used by a lot of stuff without all of the dependencies
> also getting updated. This isn't really desireable either. Some ways of
> avoiding this situation have been discussed, but there can be conflicts
> between getting the new feature in, having packagers need to jump into
> action quickly to support such changes and doing the push without having
> all of the dependencies updated.

I meant to add a bit more to this but got distracted and then sent the
message before going back to this part.

There is also another case where a new feature is being tried out and
sometimes what looks good in theory doesn't work so well in practice
even if there aren't actual bugs. I think this kind of issue is something
that rawhide is useful for testing before a bad idea makes it to an
actual release. I also think this is the kind of spear heading that Fedora
should be doing.

I don't think that being the first distro to use the new version of firefox or
whatever, really does that much to advance free software in general. I don't
think that tossing out alphas or broken betas into rawhide is really all
that useful as the upstream project can find the obvious errors without
help from Fedora.

The kernel is a bit of an exception, because getting that tested is harder
than most things and Fedora takes special steps to mitigate against bad
kernels.

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 12-19-2009, 10:47 PM
Josh Boyer
 
Default Fedora Board Recap 2009-12-17 UTC 1700

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@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

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 12-20-2009, 02:07 AM
Matthias Clasen
 
Default Fedora Board Recap 2009-12-17 UTC 1700

On Sat, 2009-12-19 at 11:31 -0500, William Jon McCann wrote:

>
> Also, do you have an audio copy or transcript of the meeting? I think
> that might be of interest to some people.
>

I would be really interested in this. The hostile tone in this thread
makes me wonder what went wrong in that meeting. Not having the context
of the full meeting makes it hard for me to 'come in and speak up' as
has been requested elsewhere in this thread.

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 12-20-2009, 02:44 AM
Mike McGrath
 
Default Fedora Board Recap 2009-12-17 UTC 1700

On Sat, 19 Dec 2009, Matthias Clasen wrote:

> On Sat, 2009-12-19 at 11:31 -0500, William Jon McCann wrote:
>
> >
> > Also, do you have an audio copy or transcript of the meeting? I think
> > that might be of interest to some people.
> >
>
> I would be really interested in this. The hostile tone in this thread
> makes me wonder what went wrong in that meeting. Not having the context
> of the full meeting makes it hard for me to 'come in and speak up' as
> has been requested elsewhere in this thread.
>

I'm fairly certain the board meetings aren't taped and for good reason.
In fact this is the first time I can think of where "someone said this,
and this and this and this in the meeting" has ever been made public in
such a manner. All the context you need is provided by the whiteboard
though if you want to speak up.

I'd mention though, the desktop team seems to be well represented by Jon,
I feel very confident I have a good idea of what he is trying to
accomplish with his proposal. The problem is that so far none of the
other teams have chimed in and most of the suggestions I've heard made to
him have been completely ignored (break it up into smaller bits, take it
to fesco, take it to the other teams, etc)

-Mike

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 12-20-2009, 03:13 AM
inode0
 
Default Fedora Board Recap 2009-12-17 UTC 1700

On Sat, Dec 19, 2009 at 9:44 PM, Mike McGrath <mmcgrath@redhat.com> wrote:
> I'm fairly certain the board meetings aren't taped and for good reason.

If the only topic at this meeting was the updates/installs
presentation I'm having a hard time imagining a good reason it
couldn't have been done in public. Doing work out in the open is not
always possible, it is almost never as convenient as the alternative,
but I hope the board will continue to look for opportunities to give
the community access.

John

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 12-20-2009, 03:24 AM
Mike McGrath
 
Default Fedora Board Recap 2009-12-17 UTC 1700

On Sat, 19 Dec 2009, inode0 wrote:

> On Sat, Dec 19, 2009 at 9:44 PM, Mike McGrath <mmcgrath@redhat.com> wrote:
> > I'm fairly certain the board meetings aren't taped and for good reason.
>
> If the only topic at this meeting was the updates/installs
> presentation I'm having a hard time imagining a good reason it
> couldn't have been done in public. Doing work out in the open is not
> always possible, it is almost never as convenient as the alternative,
> but I hope the board will continue to look for opportunities to give
> the community access.
>

In hindsight not having this talk during a public board meeting was
certainly a mistake. But then I'm still confused why this was taken to a
board meeting at all. Especially if, as Jon says, everyone he's spoken to
is in agreement with it. If everyone's in agreement, why not just do it?
It's not like the items listed on the white board need the boards
permission or anything.

-Mike

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 12-20-2009, 04:12 AM
Matt Domsch
 
Default Fedora Board Recap 2009-12-17 UTC 1700

On Sat, Dec 19, 2009 at 10:13:21PM -0600, inode0 wrote:
> On Sat, Dec 19, 2009 at 9:44 PM, Mike McGrath <mmcgrath@redhat.com> wrote:
> > I'm fairly certain the board meetings aren't taped and for good reason.
>
> If the only topic at this meeting was the updates/installs
> presentation I'm having a hard time imagining a good reason it
> couldn't have been done in public.

It certainly could have been, but in general we've been having one
public IRC meeting a month, and the other three are higher-bandwidth
phone calls with notes taken during the call. This happened to make
the agenda for a phone call. Given the tone, and repetitiveness of
the conversation, it could have been done on IRC too...

> Doing work out in the open is not always possible, it is almost
> never as convenient as the alternative, but I hope the board will
> continue to look for opportunities to give the community access.

I struggle with this. From a logistics POV, we could do a wider phone
bridge, or bridge with limited voicing. I think we've been waiting on
Fedora Talk to have that capability. But I don't think listening in
on a 2-hour meandering conversation, either live or recorded later,
would really help in this instance.

Their proposal was public (it's in the wiki), and was certainly
discussed in various groups at FUDCon Toronto. I don't know how much
more open that can be, without requiring all conversations about
anything to get moved onto the mailing lists.

I think the whiteboard proposal doesn't do enough to explain what
the pain points are, before it jumps into proposals for how to address
them. Maybe the pain is obvious, but it's hard to motivate large
swaths of the project contributors to change their ways without being
able to articulate _why_ they should, and how life will be better
having done so.

I don't fault Jon and Christopher for bringing their idea to the
Board. They are in many ways trying to help define the audience for
Fedora, which the Board has been struggling with for some time. The
problem here (from my perspective) was recognizing that there are many
audiences to satisfy. Furthermore, I'd like anyone to feel
comfortable bringing any concerns, ideas, etc. to the Board. Yes, the
Board may well redirect (either before or after listening), but the
Board need not only converse on requests raised by another formal
committee (e.g. FESCo).

Jon and Christopher presented a plan which, to me, tried to collapse
several different audiences into one. I think that the audience for
updates-released is significantly different than the audience for
rawhide. In increasing levels of "pain I as a user am willing to put
up with", updates-released -> updates-testing -> Fedora++-devel (early
branching due to No Frozen Rawhide plans) -> rawhide. Processes
(including level of QA) that let developers push updates into rawhide
necessarily should differ from pushing updates into updates-released.

Is rawhide in its current form perfect - no, far from it. But
concrete steps _are_ being taken to address the most obvious pain
points: No Frozen Rawhide, including early branching for Fedora++;
AutoQA to test trees prior to being published. Maybe even (gasp)
nightly repoclosure, and, dare I say it, automatic rebuilds of
packages when one of their dependencies change.

Is the updates-released process perfect? Again, no, and steps are
being taken to address some of the more visible pain points here too.
The return of "the set of packages which thou shalt not break" is
welcome - now we need some help with AutoQA to check those more
thoroughly. Getting additional people to use updates-testing, and
report bodhi karma and comments, either as a formal tester or not,
would help. Batching updates into weekly chunks? I'm not convinced
yet. I can see how that might give a QA team a more testable target,
but I'm not convinced it helps our users a whole lot.

What I'd like to see out of this is that when people do wish to
suggest far-ranging changes to the Project, please put more rigor put
into articulating the problems, politely, but thoroughly, and proposed
solutions, in a consumable fashion. Sure, this may cross internal
boundaries and responsibilities - I'd hope we're not so inflexible as
to allow such. If you don't know where a piece or two belongs, the
Board can help with that redirection.

Thanks,
Matt


_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 01-05-2010, 11:48 PM
John Poelstra
 
Default Fedora Board Recap 2009-12-17 UTC 1700

William Jon McCann said the following on 12/19/2009 01:13 PM Pacific Time:

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.

But let's try to turn this into something positive. For those of us
who would like to see the board give an opinion on this issue - or for
the project as a whole to move in this direction, what does the board
recommend that we do at this point? I have tried to convey that this
wiki does not only represent my professional recommendation for the
project but an effort to reflect the desires of many other
stakeholders as well. I'm sorry if this has appeared to be in bad
form. Even if it was I'm not sure it is productive to focus on that
now.



https://fedoraproject.org/wiki/Desktop/Whiteboards/UpdateExperience

Overall I really like the "whiteboard." I think it is a good collection
of a lot of things that if implemented would make Fedora much better.


While this page is a collection of lots of good information I do not see
it as a "proposal." To me it is more a laundry list of all the things
that should be changed. There is a section called "requirements", but
these seem like more wide ranging policy changes that would affect a lot
of different groups. While many of these requirements or "changes"
would be good for Fedora the part missing for me is how and when they
would all be implemented.


For it to be a considered a proposal (that I as a board member would
vote in favor of implementing), I would want to see a detailed section
explaining the phases and process that these changes would be
implemented with.


I would also suggest breaking the suggested changes into sections or
separate pages by functional areas. For example, FESCo, QA, Release
Engineering, etc. Some of the suggested changes might be implemented by
enhancing the release criteria. Other changes might be implemented
through policies created and monitored by other groups.


So in summary, there are lots of good ideas that would really benefit
Fedora, but the list is somewhat overwhelming and the implementations
details and related ownership and accountability for each individual
item are ambiguous.


It would also be helpful to be clear about why this set of problems
needs to be solved and what target audience we are intending to benefit
by solving them. I think this write-up assumes that a particular target
audience would benefit from these changes, but that target audience is
not clearly spelled out. Doing so would make the case for these changes
stronger.


John

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 

Thread Tools




All times are GMT. The time now is 11:38 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org