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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 24 Sep 2013 09:31:10 -0700
Message-ID: <CAAWBYDDHLYriA2NgM6w_SD+CW9D815KgW7TEXuE1VmwBTqsNnw@mail.gmail.com>
To: John Daggett <jdaggett@mozilla.com>
Cc: Dirk Schulze <dschulze@adobe.com>, fantasai <fantasai.lists@inkedblade.net>, www-style list <www-style@w3.org>
On Mon, Sep 23, 2013 at 10:08 PM, John Daggett <jdaggett@mozilla.com> wrote:
> 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.

And you can do that with Bikeshed as well.  Like I said, I'm fast with
pull requests, but you can always make local edits if you hit a bug
and need it resolved immediately.

>> 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!!

A curl script is less steps for *everybody*.

>> 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.

I suspect you're the *only* person (besides Bert) in the group who is
using Bert's preprocessor locally.  It's far too difficult and
annoying to get running locally for anyone else, which is one of the
original reasons I wrote Bikeshed - to make it easier to do locally.

Received on Tuesday, 24 September 2013 16:32:00 UTC

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