User talk:Pertusus/Draft keeping infra open for EOL

• "when a release goes EOL open all acls to uberpackagers" -- At least initially I'd rather see this applied to a single release. (ie: target F8 to be a long term release or target F9 as a long term release rather than all releases)
• "Also it is not possible currently to report bug against these packages." -- I'm not certain but I don't think we have the ability to lock down bugzilla like this.
• "especially if some work has to be done from the infrastructure team" -- releng should be included in this as well. Until a signing server is created, signing the packages will likely need either releng to help or infrastructure to create a separate sandbox for signing these packages.

--abadger1999 01:09, 15 October 2008 (UTC)

• I still feel this is a bad idea - no guarantee (or even promise, or pledge) that anything will be fixed; the set of what may be fixed can change at any time (leading to different things being fixed at different rates, etc.)
• In any case, this speaks to 1) infrastructure 2) use of the Fedora 'brand' (including possibly the trademarks) 3) the goals of the project itself. It's a board-level issue, not a FESCo issue.

--notting 15 October 2008

• I generally agree with notting, its a board level issue but it seems appropriate for FESCo to put a solution together for the board to agree to or deny.
• size estimates - one concern I have is if we leave the old packages buildable, will everyone keep building against them? If so how many extra packages are to be stored in koji? What's the estimated increase in size?

--mmcgrath 15 October 2008

Bugzilla

• Will we continue to accept bug reports?
• How can we maintain three versions when we can't maintain two?
  • http://tinyurl.com/4cavl2

--poelcat

• When will releases close? Ever? Or is there a specific time when they will stop getting any updates and close for good?

• How does this figure into the bugzappers bug lifecycle handling? Should only security bugs get fixed in these LTS releases?

How about serious bugs? Bugs that annoy a maintainer? Any bug?

• How can you get maintainers helping when it's not advertised anywhere? How will they know? Perhaps there would be some way to indicate if a maintainer wanted to maintain their packages for old releases?

--nirik 11:27, 15 October 2008 (UTC)

Proposal Enhancement Suggestions

When proposing to change a well established process it often helps to explain why it needs to be changed to begin with--describing what the problem needing to be solved is.

• Include a "problem statement" section which includes:
  1. A description of the problem
  2. How you will measure success
  3. How you will measure failure and when you should stop
  4. What your exit strategy is if your approach fails
  5. What the risks of attempting to solve this problem are--could it negatively impact existing parts of Fedora that are currently functioning well?
  6. The benefits of expending resources to try an solve this problem

Perhaps you don't need to list all of these, but as someone who hasn't had time to read 100's of emails on the subject it might help me and others to better understand why you want to perform the implementation steps in your proposal.

--poelcat

I agree with poelstra, defining the problem space and setting some goals would go a hell of a long way. And as it stands there's nothing I see as a compelling vision that I can point new contributors at in an effort to build up a cohesive contributor community.

For example, "easing transitioning of Fedora installations into Centos/RHEL installations" would be an interesting problem space, one that I think is at the heart of the fascination with a Fedora LTS. How do we help people develop on Fedora, but then transition that development into a long term deployment once the next version of the Enterprise distros in our ecosystem are available? This sort of bigger picture goal would probably require some post EOL package maintenance as part of a transitional path for users looking to transition from development to deployment, but the extent of such a workload is automatically scoped by the problem statement and far less open ended.

--jspaleta

Focusing on selected releases?

I note the kernel maintainer for the 2.6.x series picks a version, and keeps it stable for a while. Would it make sense for this initiative to focus on one release above others to maintain? And add another one every couple of releases? Not to be dialtory here, but this was raised on fedora-devel, so thought I'd bring it up here for some love :)

Chris Weyl 23:37, 16 October 2008 (UTC)