Security Response Team / EOL

Axel Thimm Axel.Thimm at ATrpms.net
Fri Apr 28 12:20:07 UTC 2006


On Fri, Apr 28, 2006 at 01:43:46PM +0200, Patrice Dumas wrote:
> > > FE is unsupported (as in the no waarranty clause of free software licences)
> > > being a project based on volunteering.
> > 
> > Maybe -- but that's not a reason to leave known security bugs
> > unfixed ;-)
> 
> Of course, but let's not mix that issue with the fedora extras EOL issue.

I think this is inevitable. The end of the time span where one commits
to fix security issues is by definition the EOL. When you talk about
EOLs, different phases in the life times of a product and similar, you
need to keep it in the picture.

Let's forget about the coining of the word "supported" as in "there are
SLAs". This definition is important for Red Hat's relationship to
Fedora, but is otherwise only confusing. There are two phases to FC
and FE, one which is the active mode, where packages get both security
fixes, bug fixes and enhancements, and the other is a phase we try to
define, which at the very least has security and bugfixes.

The questions are:

o forbid/obstruct enhancements or easy-bugfixes in the second phase?

  For a release like RHL/RHEL one can see the reason why, you want a
  stable ABI and these did offer it. So you need to be conservative as
  a large userbase will remain with these due to the ABI. But FC has
  no stable ABI, so this reason can be skipped. People that will want
  to run FC3 in 6 months just don't have the time to do the upgrade,
  it's not that they have a lock-in by third party propriatarey
  applications, they are running RHEL for that.

  So I believe that there is no pressure to be conservative about
  upstream upgrading when in maintenance mode.

o does it make sense for fedora extras to have better support than
  fedora core?

  IMO no, it's like not caring whether the basements stand and
  building on. This issue is probably trivial, but needs to be taken
  into account.

o Can there be consolidation of forces in fedora (core) legacy and
  fedora extras legacy?

  Even if the current group of legacy maintainers are not interested
  in extras, the about to be formed group should consider joining them
  and sharing the same methology and resources. So the old legacy
  members have no additional workload, while the new ones can learn
  from their experience. And there will certainly be a lot of
  synergetic effects in the long run.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20060428/57798187/attachment.sig>


More information about the fedora-extras-list mailing list