major libgda and libgnomedb upgrade notice

[Jeff Spaleta]

On 11/28/05, Ralf Corsepius <rc040203 at freenet.de> wrote:
> No, such packages would have to stay until ETA of a distribution,
> because a package maintainer has no possibility to know what others are
> doing with it.

There is no such policy in place now nor has there ever been, which
demands packagers to keep maintainershiper for any period of time. 
Let's be clear, packagers can and will orphan packages based on their
individual circumstances at any time.  Extras is not designed to be a
reliable development platform for anyone. It is folly for anyone to
imagine that it is and worst folly to advertise it as such. You are
right, no maintainer can know what others are doing....but Extras
makes absolutely no promise that others can rely on it to be a
development platform, such a promise is derived from the structure and
policy of the development model.. and not from individual maintainer
circumstances.

>
> Think about it: It's same rationale why RH can't upgrade GNOME, KDE, GCC
> or glibc during a distribution's life-time.
>

I understand the rationale and I don't question the logic. What I am
saying is the Extras development model as it stands now does not
support nor has it claimed to support the goal of being a reliable
development platform.  For the rationale to hold sway, Extras would
need to move to a release model like Core, with established points in
the cycle where the tree freezes and updates apply on top instead of
being rolled into the tree with clear guidance to to the
responsibilities of maintainers to support the packages to the EOL of
that release. The development model of Extras is not structured to
support the platform reliability you desire.

> > Since there are no guidelines for how long someone is required to hold
> > maintainership over a package in general... i think your insistence
> > for this single case is misplaced.
> No, I am only demand maintainers to do a reasonable job.

You catch more flies with honey. Any demands that are not part of the
development structure that must be agreed to as part of participation
are ill-advised.


> 1. Then, they should not upgrade a package.
Highly limiting and the Extras development model and infrastructure
are designed to encourage upgrades instead of backports. The lack of a
security team dedicated to support maintainers keep up with security
issues makes refraining from upgrades a difficult trade-off to
support. Again, Extras does not claim to be a reliable development
platform.
If I had to choose between Extras as a secure software collection for
end-users and a reliable development platform..I would choose
security.  Without a dedicated security group to watch over compat and
backport fixes, tracking upstream with upgrades becomes the primary
vehicle to prevent security problems.

> Nobody is wanting it to be static - But I want it stable!

I avoid the word stable delibrately because people use it to mean
different things.

>
> The situation FE+Livna currently is, to me is beyond reason and
> unacceptable:

I hear you, but this is something the steering committee will have to
take up and determine if its worth building policy to enforce on all
packagers.  What I am saying is, to achieve the level of development
platform reliability that you desire Extras will need to shift its
development model to a point release model with clear points in time
when new packages can be added, and old packages can be dropped.  The
rolling structure we have now does not support the platform
reliability that you want.  The current model makes no demands as a
matter of policy that maintainers must provide compat libraries to the
end of a release's EOL. At the current time the policy allows for a
new maintainer to create compat packages if the original maintainer
doesn't recognize the need.

> Livna has rebuilt mplayer, but hasn't update xine-lib, yet.

Such is life. Extras has at no point promised to be a reliable build
platform for anyone working downstream. Until the model changes
downstream packagers will have to react in as timely a manner as they
can as situations demand.  Even between Core and Extras this can and
will happen on occasion. Livna has to rebuild nvidia drivers for
security kernels too... you can't get away from this problem of time
lag for downstream to rebuild packages.
Extras will lag Core, Livna will lag Core and Extras.. all you can do
is attempt to minimize the lag.

xine-lib-1.1.0-0.lvn.8.4 exists now and installs for me on fc4.

> FESCO still doesn't have an email address ;)

but the members of the committee do.

-jef