New package: cogito

[Michael Schwendt]

On Wed, 04 May 2005 16:23:09 -0400, Toshio wrote:

> > > (On fedora.us there was unstable and testing.)
> > 
> > ... and confused many users, since (1) no document explained the
> > philosophy behind a classification into stable/testing/unstable, (2) other
> > repositories use a different classification, (3) hardly any user who, runs
> > into problems with packages from "testing" or "unstable", would report a
> > bug, (4) repository mixing becomes even funnier, (5) inter-repository
> > dependencies (e.g. "livna") get more funny, too, (6) example yum config
> > files apparently suggested to enable all repositories by default, and (7)
> > an upgrade path from half-baked packages/software often is impracticable.
> > 
> > > I'm not sure if the new testing repository is more
> > > like the Fedora Core Testing repo....
> > 
> > It is and should not be abused for overly experimental stuff.
> >  
> I'll accept all this as for the good.
> 
> But reiterate the part you snipped: there's all sorts of broken but
> actively developed, dependency-inducing software that people will want
> to package.  There is not currently any policy of exclusion for such
> software.  Unless that changes, at some point there has to be some
> policy of how to minimize breakage when including it.

There is no simple solution, unfortunately, except not to include any
software which is considered too unstable / not ready.

If you are concerned that it may break badly in future upgrades, don't
include it [yet].

At some point in time, when a packager takes what an upstream project
offers and puts it into packages, the software may be found to be in a
working/usable state.

So a package enters Fedora Extras, and reviewers probably don't raise any
questions or don't argue that the software is advertised as being
"unstable" or "alpha/beta".

You don't know which road of development the upstream people will choose
in the future. It may be that they stick to old library APIs, resulting in
the need to move old Fedora Core library packages as compatibility+devel
packages into Fedora Extras. Or they prefer using CVS snapshots to build
for the absolute bleeding edge, and the packager has a hard time choosing
a version which works and builds with available dependencies and is not
too premature itself compared with the release that entered Extras. Or the
project stalls and doesn't seem to reach its defined goals. Or they
rewrite, rename, and redesign everything and break compatibility with
older configuration files and/or saved data.

In either case, a package, which is included in Fedora Extras, reflects
what its software developers offered at some point in time. Once a package
is _in_ Fedora Extras, there is no looking back as they day will come when
you may have to release an upgrade. It might happen that their newer
releases cause regression, break some features badly or even remove
features, or require specific dependencies which makes it more difficult
to integrate a release into a distribution.

There are no guarantees that software upgrades of extra packages are
painless. As the packager you cannot guarantee it, when the software
developers don't care about it. Even if you followed development of some
software for some long period, it may happen that developer surprise you
with a 2.0 branch which doesn't allow for any smooth upgrades at all.

As the packager you can pick a release which appears to be usable
and--when you and a reviewer are of the opinion that it is ready enough to
be included--hope for the best and add your own testing of updates.

-- 
Fedora Core release 4 (Stentz) - Linux 2.6.11-1.1369_FC4
loadavg: 1.35 1.27 1.10