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

Re: Incoming: directfb soname problems

On Sat, 2006-05-13 at 22:02 +0200, Thomas Vander Stichele wrote:

> We don't have many packages like directfb afaik that chose to have a
> different so name for each release.

That's not really relevant.

> when I asked on IRC, people felt it was enough
> to warn the affected maintainers.  Which is what I did.

I strongly disagree with that.  The fundamental problem is that one
can't possibly reach the whole target audience.  Have the maintainers
ack'd that they will be able to ship updated packages shortly (or at
all) after your update hits the repos, for all affected distro versions?
Are you sure you mailed the correct individuals?  Rhetorical: If not,
have all end users been notified what they need to do in the meantime?
If the answer to any of these is "no", this is a potential security
issue, which you're essentially willingly inflicting on users.

I didn't see immediate commits following the directfb one to affected FE
packages in the commits list, which already proves that as implemented,
this update was a failure even within FE.

> I'm happy to follow any other guidelines if there are others.

A real policy in FESCO's TODO list.  Some members were skeptical whether
a policy is needed, but this reoccurring example probably serves as a
good case in point.  (My personal opinions follow.)  The absolute
minimum one can do is to think hard whether it makes sense to inflict
the pain in the first place.  If the conclusion is yes, in addition to
poking chosen maintainers, announce it (along with the reasoning why
it's going to be done!) prominently in public well (I'd say minimum 3
working days) before queuing the builds.  The fedora-maintainers list
has been used for these announcements in the past and should be used in
the future.  It won't hurt to send it to other lists as well, such as
this list and 3rd party repo lists.

I've temporarily moved the packages out of the needsign queue so the
update can be reconsidered (as a whole or partially), and if still
wanted, properly communicated before done.

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