Re: Thoughts on starting the SVG 2.0 spec

Hi,

On Thu, 24 Mar 2011 05:20:34 +0100, Jonathan Watt <jwatt@jwatt.org> wrote:

...
> Directory structure:
>
> Talking with Cameron I think we should get rid of the 'master' and  
> 'publish'
> directories and just have a 'spec' directory. Any files that need to be
> processed by the build script to produce a page can be marked with  
> ".src." in
> their name (e.g. index.src.html).
>
> This has several advantages. It Eliminates duplication of files that are  
> in both
> master and publish, such as the relatively large 'images' directory.  
> This in
> turn makes the repository smaller, makes diffs smaller, makes the build  
> script
> run faster (no copying), and eliminates the need for rsync to be  
> installed to
> build the spec.

IMHO it would be nice if the publish version was not tracked by the  
version control system at all until it was put in datespace (separate  
location). The w3 mercurial server should instead just run the necessary  
scripts after each commit/push, and keep an editor's draft copy up to date  
that way, but separately from the VCS.

There's really no need to keep updating and checking in those copies  
manually like we do at the moment. It's just extra manual work.

However, it still makes sense to be able to generate a publish version (or  
equivalent) locally, so I'm not saying get rid of that, just make the  
server do some of the work for us.

> Tools:
>
> I want to vastly simplify the setup required to be able to work on the  
> spec.
> Amongst other things I'm working on a new build script that will  
> eliminate the
> need for cygwin.

Just please say it's not perl-based :)

> Starting point:
>
> I think that once 1.1 2nd edition is done, we should start with the  
> files from
> 2nd Ed, and commit those *initially unmodified in any way* to the  
> Mercurial
> repository. (And in the same directory structure as 1.1 2nd Ed!! -- we  
> can 'hg
> move' them into any new directory structure as the next step.) There are  
> a few
> reasons for wanting to start with the 2nd Ed files.
>
>  * I want to be able to see and track how the spec that browsers have
>    implemented/are implementing changes, and what's different in 2.0.
>    Specifically I want to be able to see *diffs* for the changes as
>    people make them, starting right back from the 2nd Ed text. Starting
>    with a blank document for 2.0 and moving sections across from 1.1
>    to 2.0 would not provide anything like the same level of
>    transparency/insight.

It would buy us the revision history so in that sense it would be good to  
start with 1.1F2, that way you can always go back to the first revision to  
compare with new changes. I think either way is reasonable, but starting  
out with 1.1F2 will probably mean we will see faster progress of the spec.  
At least if the intention was to rewrite every single thing in the spec.

>  * Cameron tells me that on the last telcon you discussed having two  
> docs;
>    a 2.0 doc, and a 1.1 2nd Ed doc that gets modified in some way, with
>    links between the two showing what came from where and what changed.
>    This seems like a lot of work to add/maintain the links, will be
>    error prone, will clutter the source, and it will often be unclear
>    what to do when text is broken up or text is combined from various
>    places.

Yes, I think it'll be too much work to keep track of that too.

> Review:
...
> Regarding changes made without review before the commit, I think we  
> should start
> out by allowing people to do that, using their discretion about whether  
> or not
> other members of the WG would like to review the change before it's  
> committed.

It would be nice if we had a more easy to use way to review the spec,  
something along the lines of http://www.reviewboard.org/.

Imposing a public review using a system like that before a change is  
merged to the actual main branch could also be a way to raise the quality.  
It's more work though.


-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Thursday, 24 March 2011 12:09:53 UTC