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

Re: Policy Process (was: Bug #89867: Where to place web-accessible images)



On Mon, 2 Sep 2002, Manoj Srivastava wrote:

>  Matthew> Based on the proposal's use of http://localhost/, or some
>  Matthew> other criteria?
> 
> 	Right now, if I arrange for images to be referenced in
>  /var/www/, they are accessible elsewhere (I did something like that
>  when I used to maintain LaTeX2HTML -- the images were available both
>  locally using a fil:// url as well as from off machine).

What magic, precisely, did you use to achieve that?  Apart from having the
whole HTMLized document in /var/www (which, IIRC, we do here - I don't
manage documentation) and using proper relative links.

> 	Were I to follow this proposed polisy, that would not be the case.

That is true.  We'd need to place a symlink of /usr/share/images in /images
(noooo, I'm not suggesting that!).

What is important, though, IMHO, is that there is a consistent place to put
images, which is guaranteed (as far as practicable, anyway) to be available
by the web server.  This prevents such problems as sparked this amendment -
putting images in /usr/share/doc <shudder> - and also, if we can make it
somewhere other than /var/www, reduces the chances of breaking locally
created websites.  I've always thought of /var/www as being pretty much like
/home - there might be default contents in there on install, but after that
we leave it well alone.

I think, also, that your experience with LaTeX2HTML might have been
different to what this amendment is proposing.  Not that anything which may
be a picture viewable by a web browser go in /usr/share/images/, but that
images which come with a package for web pages go there (hence the
by-package naming, a-la /usr/share/doc).

>  Matthew> Also, I've noticed recent discussion on teams that are
>  Matthew> seriously short of manpower, and -policy editors was one of
>  Matthew> the groups that came up.
> 
> 	Perhaps. But the part we need most help with is flushing out
>  the issues in the BTS, updating the bugs to reflect the current
>  status, and kick starting moribund discussions (or flushing the
>  issues out).

I'll get onto that, then, I guess.

> 	We are also on the cusp of starting a rewrite of policy as a
>  tight, specs/standards document, and a good practices document (look
>  for the discussion between aj and Julian in this list). So, looking
>  at items in current policy, and deciding where they belong in the new
>  set of documents would help the process.

I think I'll triage bugs for a while, since I'm not particularly familiar
with the exact scope of the two documents.  I know the general idea, and I
agree, but not being a big part of the discussion, I'm hesitant to stomp in
with my size 11's and do damage.

> 	The actual writing to CVS and uploading the package itself is
>  less of a bottleneck, but we'll need to get more people in that set
>  as well.

Well, if there is cutting-and-pasting that needs to be done, I'm more than
happy to pick up my trusty text editor[1] and do some block shifting.  I can
string sentences together, too, if that's needed.  <g>

[1] Not going to start an editor war by mentioning which one...

- Matt



Reply to: