Re: DDP from its packages (Re: r8957 - /manuals/trunk/Makefile)
Hi Javi,
I was off-line a while... if I am missing some discussion, excuse me.
(I just had my mobo died on my Debian MacBook to be unbootable and had
other things. So I was slow responding and busy fixing my environment
...)
On Sat, Oct 29, 2011 at 08:05:30PM +0200, Javier Fernández-Sanguino Peña wrote:
> On Sat, Oct 29, 2011 at 10:34:05AM -0400, David Prévot wrote:
> > > Who has taken this decision?
I do not think anyone made blanket decision for all DDP contents yet. I
certainly send messages asking to move some DDP documents I maintain to
go to "package -> web" path after I fed up with consistent build failure
and awkward workaround. I did not do much except saying "it is good
idea" to David several times on and off list when I see build failures
such as ones involving po4a and texlive on stable platform. I will
expect fonts for xetex backend will be another headache for PDF for next
cycle.
> > 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
Yes, you are cordinating translation for project-history but I being
practical uploader of this package recently and fed up with build
failures.
http://packages.qa.debian.org/d/debian-history.html
> 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.
CJK PDF build was always problem at least for ...
* debian-reference
* maint-guide
* project-history
* debian-refcard
Ones without problem means they just do not build PDF.
> > 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.
Yes, I agree it needs to be fixed.
But different problem will come up using stable for web PDF
and unstable for packaged PDF.
> 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.
With new PO4A, now it may be true for HTML. Footnote used to kill break
web build under lenny.
> "Upload
> quality" might mean "tested" but it does not certainly mean up-to-date
> documentation.
I agree with usefulness of building from VCS repository but it must be
done on testing or unstable chroot to be consistent with package side.
Until this is set up, we should have choice of 2 path depending on the
design of documentation contents and maintainer's choice.
> 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.
I do not think David is imposing...
> Just like the website itself is rebuilt periodically and committed 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.
I fully agree. I have been thinking about this but never got time to do so.
> 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 impact 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).
I do not think anyone is asking this. There is always enough chances of
uploads with good amount of changes.
Osamu
Reply to: