Documentation updates in-cycle?

[Duncan Lithgow]

> Factual errors might pop up too, and in some cases you can get
> applications to crash if they use strings from the documentation as
> format strings.
And that's the type of update I've got in mind - corrections to
mistakes in the documentation. We have also had silly things like
links to files and guides which are no loger valid (there was one with
the thunderbird and firefox icons). Surely while these are not
security threats if left unchanged it _should_ be trivial to fix (I
don't know if it is, but it should be).

> | My personal view is that *probably* when balancing all these things up,
> | the bug would have to be high-impact before it justifies undertaking the
> | process to fix it, which takes us back to the StableReleaseUpdates policy.
It sound like the process is a burden. Is that right? Does the process
take any account of the fact that we're talking about changes to
marked-up text and not executed code?

> FWIW, I agree with this; if you have updates which should really go
> in, the procedure shouldn't block you from doing that.  At the same
> time, a released distro should not change in substantial ways, it
> should only receive critical fixes, something I believe applies to
> security as well.
Well, security of course is critical.

If:
* we're agreed that documentation patches are extremely unlikely to
cause 'real' bugs, and
* we agree that there are many occasions when patches to stable
releases of docs are a good thing, not least to encourage completion
of translated docs, and
* the current StableReleaseUpdates policy is a procedural burden on
doing these things, then

... what is the next step

Do we need to request a way that documentation patches have a
streamlined process?

Duncan