[tex-live] Stable vs. Unstable/Testing Update Repositories?

[T T]

On 24 February 2010 00:12, C.M. Connelly <cmc at math.hmc.edu> wrote:
> "KB" == Karl Berry <karl at freefriends.org>
>
>    KB> 1) People on deadlines shouldn't update.
>
> Of course not, but updating is a great way to procrastinate, plus
> it gives you the warm glow of having all the latest and greatest
> features.  Saying that people should use common sense doesn't
> really help us, as all humans do dumb things sometimes, especially
> when it's made easy for us.

I disagree with your assessment here. Even well tested updates can
sometimes break your system.  When being on a tight deadline I usually
don't update anything, including the OS. The rule "if it ain't broken
..." applies is such situations.

>    KB> The only combination of packages that is or can be tested
>    KB> is the one that ships as the yearly release.  Personally,
>    KB> I keep an installation of that on my machine, and never
>    KB> update it.
>
> That's a reasonable policy, but it's not the policy that's
> suggested by the easy access to the updating features (which are
> also used for installing additional packages) in the current TeX
> Live.  If updating is something that only the most hardcore,
> living-on-the-edge folks should be doing, it should be hard(er) to
> do.

The update system is not intended for hardcore types only. Although
updates can occasionally result in breakage, most problems are
addressed within days and hot fixes for the critical ones are often
available within hours. I think this is quite a reasonable and
workable time frame in most cases. People requiring a stable system at
all times should update rarely or make regular backups.

What we could do to improve the situation somewhat is to set the
autobackup option in tlmgr as default.

>    KB> 2) There is no feasible way for anyone involved (authors,
>    KB> CTAN, TL) to know what a given update breaks and what
>    KB> doesn't.  So there's no feasible way to have branches (in
>    KB> addition, it would be a huge amount of work and a huge
>    KB> additional complication).
>
> The same argument could be made about any of the Linux
> distributions, which have thousands of potentially interacting
> packages from hundreds of upstream developers.  Yet they manage by
> implementing some system to handle the testing stage -- Debian has
[...]
> The same options could be used for TeX Live.  There could be a
> time-based progression, where new packages come in from CTAN and
> are added to a bleeding-edge TL repo for people to play with, and
> after some amount of time, those packages would qualify to be
> moved into the main TL repo that's considered safe to update from.
> New versions of a package reset the clock.  Adding some active
> testing would make that system even safer, of course, but would
> make things more complex.
>
> An even easier (and arguably better) option is to simply have a
> stable release repository, that only gets bugfixes or well-tested
> feature changes, and a second development repository where the
> newest stuff comes directly in from CTAN, and publicize the stable
> repositories.  An added advantage here is that you can continue to
> maintain that release for as long as you want, and even keep it
> around for people who aren't ready to update to the next year's
> release.

While I agree with what you propose in general, our resources are
already spread quite thin. Besides the lack of man-power and technical
hurdles there are also hosting problems -- TL is quite big and that
alone can preclude maintenance of multiple concurrent repositories.
That being said I will discuss with the rest of the team some ideas
and see if there is anything that we could do (but don't hold your
breath).

Cheers,

Tomek