[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: Removal of gtkmm20 (was Re: Packages failing rebuild for FE4)
- From: Jeff Spaleta <jspaleta gmail com>
- To: List for Fedora Package Maintainers <fedora-maintainers redhat com>, Discussion related to Fedora Extras <fedora-extras-list redhat com>
- Cc:
- Subject: Re: Removal of gtkmm20 (was Re: Packages failing rebuild for FE4)
- Date: Tue, 24 May 2005 18:04:36 -0400
On 5/24/05, Jeremy Katz <katzj redhat com> wrote:
> [1] It does bring up that we should probably have a slightly more
> documented process on how to deprecate/remove packages. For now, I say
> we stick to "mail the list, see if anyone objects horribly"
And on a related note, how to notify users of extras that these
packages have been dropped. Extras is somewhere between a rolling
release and a point release model. I'm not sure a 'release notes'
document like Core has/had detailing what has been removed since 'last
release' makes sense as the primary notification tool for Extras. I
doubt it's valid to assume that all package expirations from Extras
will come at the opening of a new branch.
Appropriate notification of package expiration is a tough nut.
Ideally, it would be great if there was a way to inform all users
relying on expired Extras packages that there will no longer be
updates from this repository, through the same mechanisms as they get
updates. But I don't see a way to do that within the current
technical limitations of rpms without adding an additional peice of
information at the repository level that kept a list of expired
packagenames with timestamps for that repository. Package update tools
could then parse that additional list of expired packages to notify
users of expiration events.
-jef
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]