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

Re: alternate plan for up-to-date docs on www.debian.org



On Fri, Feb 20, 2004 at 11:53:42AM -0500, Adam Di Carlo wrote:
> 
> We have all these plans for securely publishing the latest released
> versions of documents.  E.g., scripts at one site, materials on a more
> restrictive area, etc.
> 
> I think we need to step back for a moment.  Looking at these plans
> realistically, I haven't seen a single one that really has a hope of
> being implemented, assuming we're not just keeping the current
> (broken) system.

I agree on this assessment.

Just a minor difference, I have.  I have some hope for "implemented" in
terms of the system which has been proposed.  But I do not have much
hope that the system implemented is agreed to be "secure" and "usable".

Cumbersome system is a bad one.

> Why don't we just have a well-connected developer machine provide
> /usr/share/doc/{packages,...} (or a tarball of it), and then use that
> to refresh the WWW master?  This way, we use the packages themselves
> -- the whole problem of building source goes away.  The problem of
> identifying which version in CVS to use goes away.
> 
> If folks need HTML versions of the latest in CVS they should use CVS,
> or we could do something on alioth or a developer machine.

I agree on the basic thought: 
 No script shall run on the Debian www-master.

But not all DDP project documents have been published as packages.

So I suggest simpler solution assuming 
 * DD who will be involved (ddp group?) will get SSH access to the
   www-master and 
 * there will be a directory (not necessary /usr/share/doc/... but can
   be /org/www-master.debian.org/ddp/<doc-name>) which is group writable
   by ddp group.

One way or the other, we manually upload files there.
 (including something like "wget ... ; dpkg --root=. --unpack *.deb")

I build web page for my qref.sf.net site which hosts the latest CVS
version for "Debian Reference" by "scp"ing all the contents from my
local machine.  When build process got too big, I exceeded some kind of
limitation at SF.net site and I implemented this.  This allows me to
check build failure locally and update only versions I want.

I know there is some risk even with this but it is much simpler.

Another advantage is we can use latest unstable build environment with
local adjustment if needed for bug work around.  Considering XML
transition comming, this may make things much easier :-)

Osamu

Attachment: signature.asc
Description: Digital signature


Reply to: