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

Re: DDP from its packages (Re: r8957 - /manuals/trunk/Makefile)

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

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

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,


Attachment: signature.asc
Description: Digital signature

Reply to: