New bodhi release in production

[Michael Schwendt]

On Sat, 14 Aug 2010 11:33:02 +0200, Kevin wrote:

> > I've always warned about mass-pushing updates to multiple dists,
> > and I'm glad I'm not the only one.
> 
> EPEL is an entirely different matter, since:
> * there are literally YEARS between the RHEL releases and
> * RHEL has a very conservative update model, exacerbating the differences 
> between releases.
> 
> This kind of trouble is much less likely in Fedora (proper) than in EPEL.

IMO, that's splitting-hairs. Since I don't have the time to fill this list
with dozens of messages, probably this one will be the last for today in
this thread.
It doesn't matter much if it's "less likely" or "likely". We've had minor
version upgrades of libraries that broke the API and the ABI and lead to
app misbehaviour at run-time. Syncing all of Fedora N with Fedora N+1 is
not an option, or else we would arrive at the rolling-release model and
would not need to prepare "final releases" and distinguish between Fedora N
and N+1.

If only *some* components are replaced after the final dist release,
we basically need to redo the integration testing for each and every
update. And that hasn't been done so far. Not for changes in Python
modules, and not for other packages either.
Broken deps are just the tip of the iceberg. An unresolvable dep is a
show-stopper, as it makes installing an update impossible. But packagers,
who mass-build upgrades to multiple dists and mark them "stable" without
testing for each of the targeted dist, make it worse.

It's a packager's attitude problem. Mass-building updates for multiple
dists bears risks. Adding EPEL as additional target for the same
updates adds an extra problem. [Currently, some EPEL packagers admit they
haven't done any testing at all because they don't run a corresponding
EL dist installation.]


P.S. I'm not completely positive about the extra hurdles in bodhi either
(or crap like inheritance of Update Notes), but that is unrelated to my
view about "testing" and lack thereof.