Documentation updates in-cycle?
linux.photo.geek at gmail.com
Mon May 7 19:02:25 UTC 2007
On 5/7/07, Matthew East <mdke at ubuntu.com> wrote:
> I think there are three considerations to balance:
> 1. the risk of introducing new bugs - it's possible to introduce real
> bugs, although I doubt they would be that serious - for example, you
> might write some invalid markup that results in scrollkeeper errors that
> end up in people's monthly cronjob error logs. I personally can't think
> of anything more serious than that (and even that would be quite
> difficult to do) but I'm not an expert with Ubuntu and I'm told that
> bugs can come from unexpected places;
> 2. the resources taken up by doing the update - when doing an update
> it's necessary to: (a) prepare a fix both for the unstable version of
> Ubuntu and each stable version to which the bug applies; (b) make sure
> the translators know about the change and can translate it; (c) import
> the relevant translations; (d) prepare an updated package and submit it
> to the relevant developer team for checking. The documentation team is
> very small and 100% volunteer based and we don't have much time.
> 3. the seriousness of the bug.
> 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.
> What do other people think? I'm cc:ing Tollef for his views.
Thanks for the clear explanation. Also one of the statements on the
StableReleaseUpdates pages is "In contrast to pre-release versions, official
releases of Ubuntu are subject to much wider use, and by a different
demographic of user." Emphasis on the "a different demographic of user".
This helps me get my mind around this policy.
gnupg public key :: 1024D/F0E55A06
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ubuntu-doc