Ticket #382 (closed task: fixed)

Opened 4 years ago

Last modified 3 years ago

Implementing Stable Release Vision

Reported by: poelstra Owned by:
Priority: major Keywords: meeting
Cc: board-private@…, lmacken, jlaska Blocked By:
Blocking:

Description

Proposal topic

The Fedora Board created https://fedoraproject.org/wiki/Stable_release_updates_vision and asked FESCo to accept and implement it https://fedorahosted.org/fesco/ticket/351#comment:34

Overview

it has been two months since the board brought this to FESCo's attention. As a board member I would like to know:

  1. If FESCo accepts the vision--If not, when FESCo and the Board can sit down to work out something that is agreeable.
  2. If FESCo plans to implement the vision
  3. When FESCo plans to implement the vision

Change History

comment:1 Changed 4 years ago by lmacken

  • Cc lmacken added

comment:2 Changed 4 years ago by kevin

  • Keywords meeting added

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

comment:3 follow-up: ↓ 6 Changed 4 years ago by 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.

comment:4 Changed 4 years ago by mclasen

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")

comment:5 Changed 4 years ago by kevin

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.

comment:6 in reply to: ↑ 3 Changed 4 years ago by poelstra

Replying to 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.

comment:7 Changed 4 years ago by kevin

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".

comment:8 Changed 4 years ago by jlaska

  • Cc jlaska added

comment:9 Changed 4 years ago by kevin

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.

comment:10 Changed 4 years ago by dafrito

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. :)

comment:11 Changed 4 years ago by kevin

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. ;)

comment:12 Changed 4 years ago by cwickert

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)

comment:13 Changed 4 years ago by spot

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.

comment:14 Changed 4 years ago by kevin

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.

comment:15 Changed 4 years ago by kevin

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

comment:16 Changed 4 years ago by kevin

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.

comment:17 Changed 4 years ago by kevin

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. ;)

comment:18 Changed 4 years ago by kevin

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?

comment:19 Changed 3 years ago by kevin

  • Status changed from new to closed
  • Resolution set to fixed

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.

Note: See TracTickets for help on using tickets.