How quickly should we retire orphaned packages?

[Kevin Fenzi]

On Thu, 21 Aug 2014 15:11:53 +0100
"Richard W.M. Jones" <rjones at redhat.com> wrote:

...snip...

First to be clear, I am not sure I really care one way or the other on
this proposal, but happy to try and add more information... ;) 

> (a) The reason for wanting packages to be retired so quickly has not
> been made clear by rel-eng.

So, my understanding of the reasoning is that currently we retire
packages only once a cycle before branching. If we do this more often
it means there's less orphan packages that go out with the next stable
release (how many that is I don't know). 

So, you have foo getting orphaned now say, it would still go out with
f21, and only be retired in f22.

> (b) The biggest reason for people to use one distro over another is
> based on number of packages available to be installed.  By retiring
> packages more quickly we inevitably reduce this number thereby making
> Fedora less popular.

I'm not sure I agree with your first statement there. ;) 

If we split texlive into 5,000 seperate packages Fedora would suddenly
become more popular? 

I think at least a good number of people want the packages they need
for whatever purpose, but they want them to be packaged well and
maintained when they have issues with them. 

> (c) An orphaned package is not necessarily a risk ("security" has been
> mentioned here ...).  Just because it might be a risk on rare
> occasions doesn't mean we have to throw out every orphaned package.
> Security bugs can sit around in non-orphaned packages too.

Sure. Orphaned packages also increase frustration some since no one
answers bug reports or updates them or rebuilds them. 

> (d) 4 weeks is too short.  Some people go on holiday for this long.

True. 

kevin


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140821/cc24dbb3/attachment.sig>