Re: Security Response Team / EOL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am Freitag, den 28.04.2006, 13:43 +0200 schrieb Patrice Dumas: 
> > > I don't think this constraint is productive. As Axel said keeping
> > > spec files synced is simpler most of the time for the packager.
> > The user IMHO is more important than the packager.
> Maybe, but in a project based on voluntary work from packagers, putting
> constraint on them is likely to decrease their reactivness, and in turn 
> it will harm the users. 

Sorry. Yes, that's a risk. But the same argument holds true for QA of
packages -- still we do QA. 

> Otherwise said, if the "no updates" policy has
> for consequence "Backporting is too much work, I won't bother for that 
> EOL FE branch, let the security SIG do the backport if they want to", it 
> is not a win for the user in my opinion.

If you have a good idea how to solve it feel free to post it. But
letting every packager do what he likes to do is IMHO wrong:

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

> > > 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? [...]

I can't remember the details. Please see the logs from the FESCo
Meetings in the wiki.

> > > What is the meaning of 'supported' for FE4 and FE5?
> > Good question. 
> ;-)
> 
> > > 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 tend to "lets give the Security Response Team some (two? three?)
> > months and revisit the EOL plans then again" ATM
> I don't think the 2 issues of security team and FE EOL should be mixed.

That was already discussed multiple times without a real result. I'm not
interested in starting this discussion anew.

If you are: Feel free to discuss it here and/or write better proposals
to your liking (hint: can be based on this one). Present it to this list
and to FESCo. FESCo can cherry-pick the best one then.

Note: FESCo really wants this done (it lingers around long time
already), so next Thursday is the deadline. Sorry, I know, that's not
much time.

BTW: Everything FESCo decides now can be reverted/modified later if that
should be needed and if there is interest from the community to change
something. We don't need to have the proper solution in the beginning.
But we have to start somewhere; and that's my goal atm.

CU
thl

-- 
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list

[Index of Archives]     [Fedora General Discussion]     [Fedora Art]     [Fedora Docs]     [Fedora Package Review]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite Backpacking]     [KDE Users]

  Powered by Linux