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

Re: DDP from its packages

Hash: SHA256

Le 29/10/2011 14:05, Javier Fernández-Sanguino Peña a écrit :
> 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

> 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.

Actually, it was just informal discussion between a few webmasters that
actually care about the DDP.

> I'm also the maintainer of these documents you are changing

I am not changing at all your documents, please, I'm picking another
source for them to appear on the www.d.o website, as we always did for
the debian-policy, and other documents too.

>> 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.

That's the purpose of the fix that has been committed to the cron
repository of www-master. It brings furthermore the benefit of not
relaying on a direct build on www-master, which often breaks for various

> 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.

Again, this issue just popped up Tuesday [1], we didn't anticipated it
on our test host (you can blame Damyan ;-), sorry about it, you just
received the same notice as all of us.

	1: http://lists.debian.org/debian-doc/2011/10/msg00024.html

>> 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.

Using packaged documents also allows translations to be always
up-to-date: translators are not alerted each time a tiny change is done
in the original document, but should be alerted before the upload,
offering them a chance to keep up.

> 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.

That can evolve: e.g. if documentations are team maintained, we can
share the upload “burden”, with another side benefit to not run after
all translators only at freeze time.

> 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

The current “ddp build failed” mail sent to debian-doc@l.d.o is already
an improvement from the previous status (where only a few people who
actually cared about the online DDP were looking at the log, or noone
even noticed).

Sending these alert to the exact concerned people would indeed probably
be even better, please feel free to implement such improvement.

> - isolate the build process in such a way that issues in the build of one
>   document do not impactb builds of another document

It's already isolated this way.

> 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

I guess the project-history issue was (this time) just a dependency
issue, so since you insist, I'm going to look for them, test the build,
ask DSA to install the missing dependencies, revert my changes to the
cron task, and then revert my changes to the DDP, so the project-history
will build again the old way as you asked, but I would really prefer if
you could reconsider.



Version: GnuPG v1.4.11 (GNU/Linux)


Reply to: