On Sat, Oct 29, 2011 at 10:34:05AM -0400, David Prévot wrote: > > Who has taken this decision? > > The web team (CCed) want to do this for quite some time already and > agreed about it last year during the sprint. We already began to take > care of these documentations one at a time when needed.
I'm part of the www team (albeit low profile, and don't remember seeing this discussion in the mailing list) and have not agreed to this. I'm also the maintainer of these documents you are changing and nobody has gathered my opinion (against the change) before committing. And we are talking about changing something that has been working mostly fine for the last >10 years I've been around. > The rationale for this specific change is that the project-history > didn't built any more on www-master since it was upgraded to Squeeze. Then that should be fixed instead. I find it funny that nobody has contacted me with these issues (me being the one that commits to this particular document) and the build breakage has not been forwarded to me either. > In order to avoid breaking the web build each time a DDP commit goes > wrong (either in the original pages, in one of its translation or even > in the build system), providing a well tested (upload quality) document > to our users seems like a great improvement. Having the documents built on www-master actually ensures that the translators (or original authors) do not botch the documents. "Upload quality" might mean "tested" but it does not certainly mean up-to-date documentation. I see this as a step backwards, since our users will not benefit from updates to documentation until an upload is done. And that happens less frequently than CVS commits. I would suggest you take a loot at the commits of the project-history package and compare them to the uploads to this document, and ask yourself whether we do a "better service" to our users by delaying publishing changes in the repository until a package is uploaded. > Please consider increasing the upload frequencies in order to keep the > online documentation up to date. It's certainly absurd to do an upload for every typo fix or commit to the document and I'm not going to do so. So "please consider" not imposing documentation maintainers like myself a given workflow. Just like the website itself is rebuilt periodically and commited to its main place (www.debian.org), documents which are part of the DDP which are published at the website, should be built and updated periodically to the site. If the issue is that documents need to be built with up-to-date tools then maybe we should think about build documents in an unstable chroot (instead of an stable Squeeze system that does not get updates to po4a and other tools), the solution should *not* be we wait until an upload from the main uploader to of the package. What we should do is: - raise visibility of issues in builds of documents by sending them to the documentation maintainers and translators, not to the mailing list of the documentation project together with a bunch of unrelated things - isolate the build process in such a way that issues in the build of one document do not impactb builds of another document - (if we need up to date tools) have a sid chroot for building documentation With all due respect, I'm going to revert the changes done to the documents *I* maintain/commit to as this change forces me to change my work process in a way I don't want to (I will not upload a new package just to fix a typo). Best regards, Javier
signature.asc
Description: Digital signature