Security Response Team / EOL

[Ed Hill]

On Fri, 2006-04-28 at 14:22 +0200, Thorsten Leemhuis wrote:
> Am Freitag, den 28.04.2006, 13:43 +0200 schrieb Patrice Dumas: 
> > > Doing both (e.g. 50% of the packagers update their packages to new
> > > versions, the other 50% only fix bugs) is IMHO the worst we can do. If
> > Why? [...]
> 
> People from the outside look at Fedora Extras as a single entity. And
> therefor we IMHO should maintain a consistent look-and-feel to
> outsiders.

The above is (IMHO) a important point that Patrice and others (again,
IMHO) are either missing or choosing to ignore.  There are a few
thousand packages in FE and the number is growing (yea!!!) every week.
No one -- *especially* users -- is going to have the time to determine
which packages are being updated and which aren't.  We ought (again,
IMHO) to strive for some consistency.

Expectations are a difficult enough thing to communicate.  We don't and
IMHO shouldn't try to make it any harder to understand.


> > > > 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. [...]
> > > I can live with that if others agree with it. But there were some people
> > > in FESCo that don't like this idea.
> > Why? [...]

IMHO, a "maintenance mode" should have no new packages and should be a
"cooling off" period that leads to a clear-cut EOL.  In my mind, "EOL"
means _dead_ -- the release has been honorably laid to rest.  And thats
a _good_ thing!  I want to be free of bug reports from old versions.  I
want to be free to ignore them and focus my limited volunteer time on
the present and future releases.

   "That release has reached EOL -- please see if the problem exists
    in current releases." 

The above should be a perfectly acceptable way to close bz tickets.  And
end users shouldn't be then arguing that some other ${XYZ} package is
being updated on ${EOLed_RELEASE} and that therefor my packages should
also be upgraded because there is some new problem or interaction or
inconsistency...

Ed

-- 
Edward H. Hill III, PhD
office:  MIT Dept. of EAPS;  Rm 54-1424;  77 Massachusetts Ave.
             Cambridge, MA 02139-4307
emails:  eh3 at mit.edu                ed at eh3.com
URLs:    http://web.mit.edu/eh3/    http://eh3.com/
phone:   617-253-0098
fax:     617-253-4464