Security Response Team / EOL

[Patrice Dumas]

Hello,

I agree on the security SIG part.

On the EOL part, I know I have allready said thoses things repeatedly,
and I hope I am not perceived as being counter-productive, but I'll
repeat again...

> === EOL.
> 
> state. In this state maintainers will be allowed to issue updates to
> existing packages, but Maintainers are strongly urged to only issue
> severe bugfix or security fixes. New software versions should be avoided
> except when necessary for resolving issues with the the current version.

I don't think this constraint is productive. As Axel said keeping
spec files synced is simpler most of the time for the packager. And for
the users it depends, some want updates other don't. I would prefer 
something along

  Maintainers are urged to consider that many users expect that only
  severe bugfix or security fixes are fixed in maintainance state. However
  packagers may still update their packages if they find it more convenient
  or if they perceive that enough users want an update.

This is fuzzy, but I think it is better that way.

> Branches for new packages in CVS are not created for Distributions
> that are in Maintenance state. FESCo can approve exceptions of this rule
> if there are good reasons for it. The official package maintainers are

I completly disagree with that. If a user don't want new packages that
entered extras while in maintainance state he shouldn't install new
packages. In my opinion the maintainer could be able to add new packages
for distributions in maintainance state, if he is confident that he
will maintain it.

For me the only rule should be

  When creating branches for distributions that are in maintainance state
  the packager should understand that he is commiting to maintain them.

But it is the same for active distributions, and this commitment is still
on a voluntary basis.

> urged to fix their packages also for Distributions that are in
> Maintenance state. They should work hand in hand with the "Security
> Response Team" in case they don't have access to older
> distros anymore to test their updates. 

What about co-maintainership, if a maintainer volunteers for maintaining
the old branches?

> When the Fedora Project drops support for a Fedora Core release the
> corresponding Fedora Extras is also dropped -- read this as
> "End-of-life, no new updates,support for that EOL distro will be removed
> from the Extras buildsys". 

Agreed.

> The EOL Policy depends on the creation and a working Security Response
> Team and especially the part of it that "will lend assistance as needed"
> if the maintainer is unable to fix the package -- if that group does not
> start working properly until June 15 2006 we'll send out a EOL for
> Fedora Extras 3 -- means: "Packagers can still update things in cvs and
> build updates for now, but the official state of Fedora Extras 3 is
> 'unsupported and End of Life'". In that case we'll try to improve for
> FE4 and later.

What is the meaning of 'supported' for FE4 and FE5? I consider that
FE is unsupported (as in the no waarranty clause of free software licences)
being a project based on volunteering.

Anyway, beside all that I said above I think that, as long as the 
infrastructure and the guideline are kept unchanged, I am all for saying

"Packagers can still update things in cvs and
build updates for now, but the official state of Fedora Extras 3 is
'unsupported and End of Life'"

regardless whether there is a security team which will be nice and helpfull,
but even more for current versions than for eol/in maintainance versions.

--
Pat