/irc-logs / w3c / #css / 2012-03-03 / end

Options:

# Session Start: Sat Mar 03 00:00:00 2012
# Session Ident: #css
# [00:26] * miketaylr is now known as miketaylr|
# [00:26] * miketaylr| is now known as miketaylr||
# [00:42] <fantasai> plinss: Yes, perfect!
# [00:42] <fantasai> plinss: Thanks!
# [00:42] <plinss> np
# [00:43] <fantasai> plinss: Is there a way to grab a link to the shepherd record of a test
# [00:43] <fantasai> plinss: without hacking the URL of a search result?
# [00:43] <jet> interesting: http://gopollgo.com/vendor-prefixes-dot-how-do-you-deal-with-them
# [00:43] <plinss> what's wrong with the URL of the search result?
# [00:44] <plinss> effectively any view of a test is a search result...
# [00:44] <fantasai> if I want to link someone to a test report
# [00:44] <fantasai> I don't want to give them all the baggage of my searches...
# [00:44] * fantasai thinks actually the search result part of it should be a query string, maybe
# [00:44] <fantasai> er
# [00:44] <fantasai> search parameters
# [00:45] <plinss> ok, no current way, but how about I make the title of the test a link to the plain test?
# [00:45] <fantasai> Hmmm
# [00:46] <plinss> have another suggestion?
# [00:46] <fantasai> Well, the other thing I'd like a direct link to would be the test itself
# [00:46] <fantasai> Not sure how to balance those two things
# [00:46] <plinss> click on the source file
# [00:46] <fantasai> I do think the search parameters should be a query string, in general, though. They're name-value pairs.
# [00:46] <plinss> (actually the plan is to have a tab interface with a view of the test in the same page)
# [00:47] <fantasai> ah
# [00:47] <plinss> replacing the history view
# [00:48] <plinss> having the search param as path components keeps the URLs search engine friendly
# [00:48] <plinss> fwiw
# [00:48] <plinss> fantasai: btw, nice work on the hg docs. I'm doing another pass now...
# [00:49] <fantasai> Wouldn't it make more sense for the search engine to treat http://test.csswg.org/shepherd/testcase/height-width-table-001/name/height-width-table-001/ and http://test.csswg.org/shepherd/testcase/height-width-table-001/ as the same thing?
# [00:49] <plinss> small re-org and adding conflict resolution
# [00:49] <plinss> possibly
# [00:49] <fantasai> ?
# [00:49] <plinss> (^^ to the hg docs)
# [00:49] <fantasai> I think the only thing that's missing is an example of what hg says when there's a conflict
# [00:49] <plinss> working on that now
# [00:49] <fantasai> and what a conflicted doc looks like so you can find and fix it
# [00:50] <fantasai> cool
# [00:50] <plinss> re the search params, it's all actually params under the hood, so switching between paths and query strings is a config option...
# [00:50] <plinss> I'll play with it a bit as Shepherd matures
# [00:51] <fantasai> k, so I would suggest to let the search results listing be a path, and the test's search params (which are really only there to keep track of your next/previous links) to be query string... is that reasonable?
# [00:51] <fantasai> because the report on a single testcase should always have the same URL, and be recognizeable to the search engine as the same page
# [00:51] <plinss> I have to give it some thought...
# [00:51] <plinss> but not unreasonable
# [00:52] <plinss> I want to evolve the functionality a bit and figure out all the possible states before making a final call there
# [00:52] <fantasai> k
# [00:52] <fantasai> just something to keep in mind then
# [00:52] <plinss> sure
# [00:53] <plinss> as I said, that's all configurable
# [01:29] * Joins: nimbu (Adium@24.18.47.160)
# [01:34] * Parts: jet (jet@159.63.23.38)
# [01:34] * Joins: jet (jet@159.63.23.38)
# [02:19] <plinss> fantasai: you probably already got the email, but I just checked in my changes to the hg docs
# [02:20] <plinss> if all is well, I'll send an email to the wg list and schedule the changeover for Monday evening (unless someone screams)
# [02:21] <plinss> Mike has the new repo all set (with automatic checked out view) and is standing by on the reverse proxy setup
# [02:24] <fantasai> plinss: hmmm
# [02:24] <fantasai> plinss: I don't like the new reorganization
# [02:24] <fantasai> plinss: It makes things harder to understand imho
# [02:24] <plinss> somehow I knew you woudn't, that's why I added the summary section
# [02:25] <fantasai> plinss: And that helps how?
# [02:26] <plinss> I know you wanted a "what do I actually do to make edits" view, but this explains each operation in the proper order that users will need them.
# [02:26] <fantasai> plinss: You're looking at this from a "I'm setting up a repository for my project, oh and here's how I can sync with other people and here's the theory of distributed version control"
# [02:26] <fantasai> plinss: I want a "I want to make a change to a spec. How do I do that?" view
# [02:26] <plinss> right, but that's actually what you have
# [02:27] <plinss> if you follow each step
# [02:27] <fantasai> plinss: Committing changes locally should be advanced topic
# [02:28] <plinss> ? that's kind of fundamental...
# [02:28] <fantasai> plinss: From an "I want to make changes" point of view, it's only relevant to pushing them
# [02:28] <plinss> no, people should get used to committing changes in logical increments
# [02:28] <fantasai> plinss: My goal is to make things as simple as possible, first.
# [02:28] <plinss> all commits _are_ local by definition
# [02:29] <fantasai> plinss: And the mental model that's simplest is "There's stuff on the server. I get the stuff from the server. I make changes to it. I send it back to the server."
# [02:29] <plinss> sure, but that mental model is wrong
# [02:30] <plinss> and if people don't understand that, they will get _really_ confused when they have to merge
# [02:31] <fantasai> plinss: There's not much merging happening if you pull, commit, and push all within 1 minute
# [02:31] <plinss> that's not exactly the most likely scenario, is it?
# [02:31] <fantasai> it is if that's how you're working
# [02:31] <plinss> I thought there was value in giving people a mental model of what's actually going on
# [02:32] <fantasai> I think the highest value is creating the lowest bar to people being able to *start* to get their work done.
# [02:32] <plinss> fwiw, you can't pull and update with uncommitted work
# [02:33] <plinss> so you have to pull, update, edit, then commit, then push
# [02:33] <plinss> (you can pull, but your update will fail)
# [02:35] <fantasai> okay, but there are wayyyyy too many commands that you're throwing at people here all at once
# [02:35] <fantasai> Read *all of this* and then you can fix a typo.
# [02:36] <fantasai> You're asking me to read through all of
# [02:36] <plinss> I didn't add any commands to the doc except hg resolve
# [02:36] <fantasai> hg status, hg diff, hg revert, add, remove, move, copy, commit, outgoing, incoming, pull
# [02:36] <fantasai> update, mrege, and resolve
# [02:36] <plinss> ok, in and out
# [02:36] <fantasai> before I can even push
# [02:36] <fantasai> Yes, but you dumped some of the structure
# [02:37] <fantasai> so all the file management commands, for example, which are totally irrelevant ot someone editing an existing doc, are grouped together with everything else
# [02:37] <plinss> I imagine most readers know how to skim...
# [02:37] <fantasai> how can they skim? They have no idea which commands are required to learn and which aren't
# [02:38] <fantasai> because you're not making any distinction between what things they're used for
# [02:38] <fantasai> when I learned CVS, add and remove were in an Advanced Topics section, effectively
# [02:38] <plinss> ?? I think the section headings are fairly self explanatory
# [02:38] <fantasai> because to edit things, you don't need to know them
# [02:39] <plinss> until you rename a file and didn't know you had to use an hg command...
# [02:39] <fantasai> well it won't work
# [02:39] <plinss> Ok, how about I expand the summary section and move it before "working locally"
# [02:39] <fantasai> Also
# [02:39] <fantasai> you have a tendency to give too many options
# [02:40] <plinss> it can be the "really quick overview to change a single line real quick"
# [02:40] <fantasai> You coudl do it this way, or if you are in this conditoin you could do it this way
# [02:40] <fantasai> or this way
# [02:40] <fantasai> Just explain One Way.
# [02:40] <fantasai> If people want to be clever, they can read the manual. this is not the manual.
# [02:41] <plinss> I didn't add any options except the abbreviations and the rebase section (which you wanted)
# [02:41] <plinss> example?
# [02:41] <fantasai> The summary section has two workflows, that I have to decide between
# [02:41] <fantasai> somehow
# [02:41] <fantasai> not clear how
# [02:42] <plinss> no, it's the same workflow, with the error that people may encounter...
# [02:42] <fantasai> There were quite a few other things in the doc, that I removed...
# [02:42] <fantasai> where do you hit the error?
# [02:42] <fantasai> what's the error?
# [02:42] <plinss> error on push
# [02:42] <plinss> "hg push # resulting in an error"
# [02:42] <fantasai> so instead of having two different workflows, have one
# [02:43] <plinss> fine, I can simplify that section
# [02:43] <fantasai> this is the work flow
# [02:43] <fantasai> if you get an error here, you need to do this additional commands
# [02:44] * fantasai hates all Mercurial documentation she's ever seen, it all sucks, and it's all confusing.
# [02:49] <fantasai> In my ideal world, switching from CVS to Mercurial will only cost editors half an hour.
# [02:49] <fantasai> When I switched from CVS to Mercurial, it took me an entire day.
# [02:50] <fantasai> And, clearly, I still don't get it.
# [02:52] * fantasai wrote a perl script at the end of that day to translate from her notes on how to perform the relevant operations to the actual hg commands to perform said operations
# [02:57] <plinss> ok, how about now. I can't make it much simpler than that...
# [03:00] * Quits: nimbu (Adium@24.18.47.160) (Quit: Leaving.)
# [03:00] <fantasai> plinss: Thanks, that's a good overview. I think having that up front will help people understand the rest of the document, too, because it sets the context for what's going on.
# [03:01] * fantasai switches you to an ordered list, however :)
# [03:01] <plinss> np, thanks for the input
# [03:02] <fantasai> Other things I'd change (you can change, or I can change):
# [03:02] <fantasai> put add/remove/move under heading "Managing Files", like before
# [03:03] <fantasai> call hg commit "Saving Your Changes as a Changeset" or somesuch, same level as "Managing Files"
# [03:03] <fantasai> fold 'hg outgoing' into 'hg pull' section, as an afterthought about previewing what's going to happen -- it doesn't really need its own section, it's just a preview of hg pull
# [03:04] <fantasai> s/outgoing/incoming/
# [03:04] <fantasai> similarly, 'hg outgoing' into 'hg push'
# [03:05] <plinss> I thought having in/out separate was useful as it lets people preview the state of their repo vs the server before getting into merging situations...
# [03:05] <fantasai> in what case would that change my behavior?
# [03:05] <fantasai> if there's stuff to merge, there's stuff to merge
# [03:05] <fantasai> whether I preview it or not
# [03:05] <plinss> hg pull ; hg merge vs hg pull -u
# [03:06] <plinss> if hg in is empty, you can just push
# [03:06] <fantasai> unless between the time I type hg in and hg push someone checks in :)
# [03:08] * fantasai also concludes that since resolving rebase conflicts is beyond the scope of the document, we should probably not document it and just defer to appropriate documentation
# [03:08] <plinss> yes, but if your rebase "just works", then you're good to go
# [03:09] <fantasai> what happens if it doesn't?
# [03:09] <plinss> then you can abort, as listed
# [03:09] <fantasai> and then what?
# [03:09] <plinss> go back and merge, as listed
# [03:09] <fantasai> ok, let's say so
# [03:09] <plinss> I did
# [03:10] <fantasai> ah, I see. It's in reverse-chronological order, so I missed it
# [03:10] <plinss> at least it's not reverse polish notation
# [03:10] <fantasai> :)
# [03:16] <fantasai> plinss: btw, what's the deal with teh username = bit?
# [03:16] <fantasai> plinss: would a csswg.org username make sense for someone pushing to dvcs.w3.org?
# [03:17] <fantasai> plinss: what if the email address on the wiki is different from the one used at W3C?
# [03:17] <plinss> Shepherd uses it to sync changesets and owners with it's user DB
# [03:17] <plinss> then you use the appropriate username/email for each repo in the config
# [03:17] <fantasai> plinss: how do you do that?
# [03:18] <plinss> in the auth section, it already lists different usernames...
# [03:18] <fantasai> not under the [ui] section
# [03:18] <plinss> under [auth]
# [03:18] <fantasai> yes, I know
# [03:18] <plinss> oh, wait, I see what you're getting at...
# [03:18] <fantasai> But under [ui] your docs said to use either your csswg.org email address or username
# [03:18] * fantasai didn't understand that part
# [03:19] <plinss> right, it's under [ui]
# [03:19] <plinss> (doing too many things at once, can't multitask like when I was your age…)
# [03:19] * fantasai can't multitask either
# [03:20] <plinss> you can set different [ui] sections in the .hg/hgrc file in each repo if you have different emails you want to use
# [03:20] <fantasai> how does that work?
# [03:20] <plinss> there is the link to advanced config file instructions...
# [03:21] <plinss> each repo has a .hg directory in it
# [03:21] <fantasai> ah
# [03:21] <plinss> in that .hg directory you can put another hgrc that overrides your home dir on a per repo basis
# [03:21] <fantasai> right
# [03:21] <fantasai> so
# [03:21] <plinss> you can override anything, even extensions...
# [03:22] <fantasai> how does one decide between username = Your Full Name <your@email.address>
# [03:22] <fantasai> and username = your_csswg.org_username?
# [03:23] <plinss> either works
# [03:23] <fantasai> why would I use one over the other?
# [03:23] <plinss> that bit is really only for what show up in the hg log
# [03:23] <plinss> personal preference
# [03:23] <fantasai> so does it matter what's put there at all?
# [03:23] <plinss> don't want your email in the hg logs...
# [03:23] <plinss> it's generally arbitrary
# [03:23] <fantasai> so I can put anything?
# [03:23] <plinss> but as I said, Shepherd cares
# [03:24] <plinss> it tries to match the email adds or username to it's user db
# [03:24] <plinss> s/it's/its/ (grr)
# [03:24] <fantasai> does it check the login name first, or it only checks the [ui] username?
# [03:25] <plinss> checking code...
# [03:25] * fantasai doesn't like branches in the documentation when there's no clear conditional for which branch to take
# [03:25] <plinss> username first
# [03:26] <fantasai> but falls back to login name?
# [03:26] <plinss> then email
# [03:26] <fantasai> so, csswg.username then [ui] username?
# [03:27] <plinss> no, Shepherd doesn't look at the [auth] name
# [03:27] <plinss> that's the person doing the push, which may not be the same person that did the commit
# [03:27] <plinss> the [ui] name is what's in the hg log with the commit
# [03:29] <plinss> sorry, we were cross talking...
# [03:29] <fantasai> k
# [03:29] <plinss> Shepherd only looks at the name listed in [ui]
# [03:29] <fantasai> ok
# [03:29] <plinss> that name can be "your name <email@addr>"
# [03:30] <plinss> or "your wiki username"
# [03:30] <fantasai> ok
# [03:30] <plinss> if the username matches, that's you, otherwise it looks for the email adds to find the account
# [03:30] <plinss> s/adds/addr/
# [03:30] <fantasai> got it
# [03:30] <fantasai> k
# [03:30] <fantasai> I think... I'm going to take a break now
# [03:31] <plinss> k
# [03:31] <plinss> edits done to the hg doc btw, thanks again for your help
# [03:31] * fantasai is going into suspend or something
# [03:31] <fantasai> thank you!
# [03:31] <plinss> np
# [03:31] * fantasai will look over it later
# [03:31] <fantasai> But we should really get Tantek to test it
# [03:31] <fantasai> the doc, I mean :)
# [03:31] <plinss> I'll send an announce to the wg list
# [03:33] * Quits: jet (jet@159.63.23.38) (Quit: jet)
# [04:24] * Quits: dbaron (dbaron@159.63.23.38) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [04:30] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
# [04:47] * Joins: krit (Adium@24.6.231.253)
# [04:47] * Joins: krit1 (Adium@24.6.231.253)
# [04:50] * Quits: krit (Adium@24.6.231.253) (Ping timeout)
# [05:23] * Quits: krit1 (Adium@24.6.231.253) (Quit: Leaving.)
# [05:25] * Quits: myakura (myakura@110.233.178.43) (Client exited)
# [05:33] * Joins: myakura (myakura@110.233.178.43)
# [05:35] * Quits: myakura (myakura@110.233.178.43) (Client exited)
# [07:01] * Quits: miketaylr|| (miketaylr@68.203.0.108) (Quit: dflk;adfslkj;alsiekfj;laiskdf)
# [10:33] * Joins: Ms2ger (Ms2ger@91.181.184.71)
# [14:16] * Joins: SimonSapin (simon@82.232.219.95)
# [15:06] * Joins: myakura (myakura@110.233.178.43)
# [16:21] * Joins: krit (Adium@24.6.231.253)
# [16:43] * Joins: jet (jet@67.169.43.128)
# [17:24] * Quits: jet (jet@67.169.43.128) (Quit: jet)
# [18:10] * Quits: myakura (myakura@110.233.178.43) (Client exited)
# [18:37] * Quits: krit (Adium@24.6.231.253) (Quit: Leaving.)
# [21:47] * Joins: SimonSapin1 (simon@82.232.219.95)
# [21:47] * Quits: SimonSapin (simon@82.232.219.95) (Connection reset by peer)
# [21:50] * Quits: arronei (arronei@131.107.0.118) (Connection reset by peer)
# [21:50] * Joins: arronei (arronei@131.107.0.118)
# [22:23] * Joins: myakura (myakura@110.233.178.43)
# [23:35] * Quits: Ms2ger (Ms2ger@91.181.184.71) (Quit: nn)
# Session Close: Sun Mar 04 00:00:00 2012

The end :)