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

Re: package updates for in all repos at the same time (Was: Incoming: directfb soname problems)

On Sun, 14 May 2006 13:50:13 +0200, Thorsten Leemhuis wrote:

> > Remember a few things:
> > 
> > 1) A regular [updates-]testing repository exposes only some users to
> > package releases which may or may not become official. This adds another
> > upgrade path. Do we work around bugs introduced in these updates? 
> What kind of bugs do you mean exactly? How does core handle it?

For instance: A bug in a package scriptlet, which touches some files and
damages them. Will the final update try to repair the damage?
Or: Accidentally dropped features, which are missing because a configure
script failed to detect upgraded build requirements and hence disabled
some pieces. In several applications, related configuration settings are
lost when features are removed (a concrete example is Sylpheed).

One thing for sure, both are scenarios which can happen. However, from a
user's perspective it must be clear in which ways another extras-testing
repository differs from the normal extras repository.

Increased risk -> possibly increased requirement to recover from broken
test updates -> the smell of guinea pigs -> the optional testing
repository does not become popular -> doubtful benefit.

> > Do
> > enough active users enable such an optional repository, so that it would
> > become really helpful? 
> That's always problematic. But that's not a reason not to do it. It IMHO
> would be helpful enough if only all the Extras packagers would enable it
> and test their own packages falling out plague. (they can do that with
> the needsign-repo, too, but I doubt that a lot of people do that)

Most likely because there is no convenient way to pull a package from the
needsign-repo [and any deps built against it]. And no way to put a lock on
a set of packages in the needsign queue in order to release the complete
set as a whole.

How about picking up the old idea of a "scratch target" instead?

> > I think Fedora Core Test Updates suffer from quite
> > some desinterest.
> Well, it's not perfect, but I think it works good enough. 

As a counter-example, createrepo for FC4 and FC3 has still not been
updated to fix the broken deps in Extras' "plague". If the Test Update
repository were popular and helpful and if the developers believed in it,
the errata for FC4/FC3 would have happened already long ago.

> >  Lack of feedback--also success reports--about test
> > updates doesn't help you to decide whether an update is good.
> Well, currently there is no testing or decision if a update is good at
> all (besides the checking from the packager himself). As a ordinary user
> I'd much more prefer a package that was in extras-testing for some days
> (without feedback) over one that got no testing at all.

?  Is a package in extras/5, which is four weeks old, more safe to use
than a package in extras/5, which is two hours old? The age of a package
is irrelevant. The number of competent (!) testers who actually tested it
and report success or failure, is the interesting bit.

> And to make it sure (in case it wasn't already): No, I don't want a
> explicit testing repo where stuff could be published and tested that is
> not ready yet. I only want a testing repo where all updates hang out
> some days before they hit the proper repo. First in and First out (if
> there is no major breakage).

And *if* there is major breakage? Which pieces would you want to hold up?
And how?

> >  And how are test updates pushed
> Fifo. Example: Package foo is pushed to testing today (Sunday) and bar
> on Monday. foo will be pushed to the proper repo on Friday and bar on
> Saturday.

Before that becomes possible we will need a way to mark packages which
depend on eachother, so they are only pushed together. Plus a way to
prioritise build jobs and releases (not just with security fixes in mind).
> > or withdrawn when dependencies have or have not been built against them?
> good question. But that shouldn't normally be the case. 
> Another example (in case a problem showed up): Package foo is pushed to
> testing today (Sunday) and bar on Monday (bar depends on the new foo).
> foo makes problems. foo is fixed quickly on Tuesday. foo and bar get
> pushed to the proper repo on Saturday.

Automatically? So, Extras packagers must watch another moving target?

> > How does an additional repo solve the problem of insufficient
> > communication about upgrades and rebuilds of complete dependency chains?
> Not at all. That's not it's purpose. /me feels misunderstood 

Then I must admit I don't understand the purpose of an extras-testing
repository (in the context of how we've been doing builds/releases for
quite some time).

> CU
> thl
> /me sometimes doesn't understand the Open-Source-World -- a lot of
> people (see the achieves of the fedora mailinglists) scream when Fedora
> Core updates a package directly without letting it linger around in
> updates-testing for some days.


Well, I see no users who scream and demand an extras-testing repository.
We must improve in the area of _Package Upgrade Guidelines/Policies_,
not create extra burden and artificial hurdles for the packagers.

> But proposing the same concept for Extras
> only get criticism. Why should Extras be different? *Especially* because
> Extras has major version updates that are avoided in Core. 

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