Security Response Team / EOL

[Patrice Dumas]

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

I am not ignoring it. But I consider that it is impossible, given the
span of use and package styles. I personnaly maintain packages that are
very different, used by different users and more importantly in different
contexts. Am I the only one in that case?

To be more precise I maintain oldish science/fortran stuff that in my
opinion should be maintained and updated even in EOL feodra, document 
processing stuff that could be updated for eol versions if users ask for 
it and chm related stuff that I would prefer not to maintain for EOL 
fedora. That's my expectations and I believe they make sense, maybe I'm 
wrong.

> 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,

They don't have to. They should rely on the maintainer choice, and
communicate if they are unhappy.

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

In my opinion it is better to have inconsistencies than prevent maintainer
to package things in a relevant way. I am not saying that there shouldn't
be a general recommendation to avoid breaking stuff in EOL version and
so don't systematically update in EOL versions, but it should be flexible 
to account for all the use cases.

Similarly in devel it is nice to experiment and break stuff, but it is not
a requirement...

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

You want that. But why do you want to bind others to do the same?

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

I have never argued against that. I just say that a maintainer could be able 
to chose that (update please) and another could be able to care about those
reports.

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

They could be arguing but then you would have to point them to the
guideline saying that they have to follow your choice. You could also
ask them to be co-maintainers and maintain the packages for this branch,
if you feel you don't care about them, or, if you think they should be
kept frozen you could just say that. You are the maintainer.

--
Pat