W3C home > Mailing lists > Public > www-style@w3.org > September 2013

Re: [spec tools] spec tools should be checked into the csswg repo

From: John Daggett <jdaggett@mozilla.com>
Date: Mon, 23 Sep 2013 22:08:44 -0700 (PDT)
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Dirk Schulze <dschulze@adobe.com>, fantasai <fantasai.lists@inkedblade.net>, www-style list <www-style@w3.org>
Message-ID: <953893950.219464.1379999324394.JavaMail.zimbra@mozilla.com>
Tab Atkins wrote:

> > I think this hits both of my concerns.  For ease of use, it's a pain
> > to have the spec data and tools spread across two different version
> > control systems. And I don't like the idea that any one member of the
> > WG has effective dictate power over the tools used to construct specs,
> > however benevolent. I think it would be much better to have Tab
> > continue to use his github repo for active development and push
> > changes to the csswg repo whenever necessary.  That makes it simpler
> > for new spec writers and hopefully avoids hiccups introduced by
> > in-progress dev changes.
> Bert has had "dictate power" over the processor for years; using mine
> just means you're changing who you're relying on.  Using Anolis or
> Respec would similarly put you at the mercy of Ms2ger (I think?) or
> Robin.

No, the preprocessor files are in CVS and can be accessed/modified by anyone
with checkin access.  Bert is the primary maintainer and I've requested
changes in the past by sending him patches but I can still fix minor problems
without waiting for a review process.

> As for two different version control systems, blame the W3C for
> picking the wrong VCS when Git was already winning back then.  ^_^
> Pushing updates to the CSSWG repo still wouldn't make it that easy;
> again, you still have to install two modules.  It would just make it
> more annoying for me, and increase the likelihood of people running
> into bugs I've already fixed.  In-progress dev changes that have a
> chance of breaking things *should* be done by me in a branch.  (I'm
> not *great* at remembering to do this, but I'm trying to get better.)

Sure, more steps for you but fewer steps for everyone else!!

> Like I've already said, the correct thing to do is to just check in a
> curl script (and a README) to the csswg repo that communicates with
> Shepherd (which runs a local version of Bikeshed).  This is identical
> to the workflow you have currently with Bert's processor.

Again, not entirely correct.  I *never* use the curl version, I always
use local tools, since that allows me to quickly make changes when I'm
somewhere without a net connection.  I do a lot of changes/reviews while
on the train/bus/plane, so this is kind of important, at least to me.


Received on Tuesday, 24 September 2013 05:09:11 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:32 UTC