Added meeting keyword to discuss at 2010-06-01 meeting.

In todays fesco meeting we agreed in general to the vision statement.

More work is needed to come up with concrete implementation details from this vision.

We will solicit such proposals and revisit next week.

After the meeting yesterday I scribbled down some quick ideas for how to
implement parts of the stable updates vision.

• For getting better update descriptions:
• Make it easier to monitor bodhi updates as they are created, maybe
  have some mailing list where bodhi dumps update changes ?
• Do manual monitoring of update descriptions and approach package
  maintainers about improving update description. Not a nice job,
  necessarily. A bit like an updates czar...

• Update of the week - too silly ?

• For ensuring that the updates we do fix the problems of our users:

• Create a somewhat regular report of 'hot' bugs and issues in forums.
  This would probably have to be done by QA people/bugzappers

• For making things measurable / transparent:

• Create monthly update reports, which would probably be very similar
  to the statistics that bodhi already collects and displays
• Maybe correlate update statistics with bugs (things like "X updates
  fixed at least one 'hot' bug")

Various folks have tried publicly noting updates that have poor/no descriptions or are major updates, etc... but then others have flamed them for 'singling out' people.
So, I think we need to be carefull about monitoring.

I think the hot issues report is a great idea. Something related is in FES:
https://fedorahosted.org/fedora-engineering-services/ticket/24

Good ideas on reporting. I think we could also track: overall bugs filed in the time period and closed in the time period? Number of updates could be handy to know.

I think the first step here might be: update our maintainer docs to include this vision and how to follow it, then a mass emailing to maintainers announcing the pages and asking everyone to follow them.

Replying to [comment:3 kevin]:

In todays fesco meeting we agreed in general to the vision statement.

More work is needed to come up with concrete implementation details from this vision.

We will solicit such proposals and revisit next week.

Great to hear! Looking forward to an answer to question #3 about the time line. I want to emphasize how important it is that FESCo set a time line on this with some high level milestones--otherwise this could drift for several releases before being implemented. Better to set some dates and potentially not hit them than to never set any dates and not get this done for a long time.

As always I'm glad to help facilitate a meeting to discuss scheduling or creating a schedule.

We have created an ideas container wiki page:

https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_ideas

we will gather ideas there and then discuss which ones we want to commit to implementing and on what timeframe. We will divide them into: before f14, before f15, and "later".

We are giving this one more week to collect ideas from fesco members.
Next week we hope to start assigning work and priorities to tasks and can start hashing out a timeframe.

I tried to organize the current version of the implementation ideas wiki page. I put my draft here:

https://fedoraproject.org/wiki/User:Dafrito/Stable_release_updates_vision_implementation_ideas

This is somewhat late to the show, but I figured I'd make it in case it'd help the group out. I just tweaked the formatting of the existing version while doing my best to faithfully preserve the content.

Feel free to copy, edit, or ignore it. :)

I like the re-org/draft page. I'd be fine with moving it in place.

Reminder: Fesco folks should look at this and try and add any ideas today before the meeting. ;)

I cannot subscribe to https://fedoraproject.org/wiki/User:Dafrito/Stable_release_updates_vision_implementation_ideas or the initial statement from the board because of
Stable releases should provide a consistent user experience throughout the lifecycle and only fix bugs and security issues.

Note that this is an '''AND''' conditional while it should IMHO be an '''OR'''. What if an update fixes a bug or even security issue '''BUT''' changes the user experience? Are package maintainers supposed to backport every change?

(I won't be able to make it for the meeting tonight, that's why I'm asking here)

As a Board member who helped draft the statement, the last point should be "and/or", as applicable, changing it to:

Stable releases should provide a consistent user experience throughout the lifecycle and only fix bugs and/or security issues.

I realize that you wanted the other "and" to become an "or", but I don't support that. There may be situations where the only way to make a key bugfix or a security fix is to alter the user experience, but that should be the exception rather than the rule, and such exceptions should be treated individually.

We divided up items in our ideas page for being worked on by fesco members:

notting to work on Fedora 14: Document this stance in maintainer docs and announce to maintainers the new docs.

SMParrish to work on Fedora 14: metrics on how many updates each branch gets including rawhide?

nirik to work on Fedora 14: Some way to document failures to quality and consistency so we can learn from them, and see that the incidence is decreasing.

kylem to work on Fedora 14: Have an updates-features optional repository.

mjg59 to work on Fedora 14: Document a exception process. Some packages will need to provide updates for security reasons or working with external sources, etc.

Will see where we are next week.

Cwickert: You might open discussion on changing that clause on the board list?
Also, I think thats going to have to be subject to implementation somewhat, I hope there is some leway there for pushing an update that fixes bugs and/or security, but changes features in some cases.

Just a friendly reminder here for folks assigned items in the last comment to try and work on them before the meeting tomorrow. ;)

We all worked on our tasks over the last week, but nothing was fully complete:

notting is working on a draft.

smparrish is working on a draft.

nirik made https://fedoraproject.org/wiki/Updates_Lessons and asks for folks to help update it.

kylem hasn;t had a chance to work on that yet.

mjg59 has added some exception process to the wiki page.

cwickert is going to ask on the board list for clarification on the 'only bug fixes and security fixes' statement in the board vision.

ok. I took Ajax's draft from https://fedoraproject.org/wiki/User:Ajax/Stable_Release_Policy and put together:

https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

trying to unify the rawhide/branched/stable release policies and provide a one-page document we can point maintainers to.

It's rough, but please edit and/or revise before the next meeting.

We really need to get this done. ;)

So, to update this ticket:

• We have a update policy in place.
• It provides for a way to note issues and let us learn from them.

We need still:

• Metrics.

• Some talk about enforcement. How can we see that our maintainers are following the policy and teach them/help them to do so.

• There was talk about a 'feature/enhancement' repo at one time. Do we still wish to persue this? Would it help the KDE case as well?

We have this implemented now except for the metrics part is somewhat incomplete.

https://fedoraproject.org/wiki/Updates_Policy

I'm going to close this now as we continue to work on metrics.

If the Board doesn't think we have fully implemented what their vision was, please do reopen or file new tickets for us to address.