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

Options:

  1. # Session Start: Sat Mar 03 00:00:00 2012
  2. # Session Ident: #css
  3. # [00:26] * miketaylr is now known as miketaylr|
  4. # [00:26] * miketaylr| is now known as miketaylr||
  5. # [00:42] <fantasai> plinss: Yes, perfect!
  6. # [00:42] <fantasai> plinss: Thanks!
  7. # [00:42] <plinss> np
  8. # [00:43] <fantasai> plinss: Is there a way to grab a link to the shepherd record of a test
  9. # [00:43] <fantasai> plinss: without hacking the URL of a search result?
  10. # [00:43] <jet> interesting: http://gopollgo.com/vendor-prefixes-dot-how-do-you-deal-with-them
  11. # [00:43] <plinss> what's wrong with the URL of the search result?
  12. # [00:44] <plinss> effectively any view of a test is a search result...
  13. # [00:44] <fantasai> if I want to link someone to a test report
  14. # [00:44] <fantasai> I don't want to give them all the baggage of my searches...
  15. # [00:44] * fantasai thinks actually the search result part of it should be a query string, maybe
  16. # [00:44] <fantasai> er
  17. # [00:44] <fantasai> search parameters
  18. # [00:45] <plinss> ok, no current way, but how about I make the title of the test a link to the plain test?
  19. # [00:45] <fantasai> Hmmm
  20. # [00:46] <plinss> have another suggestion?
  21. # [00:46] <fantasai> Well, the other thing I'd like a direct link to would be the test itself
  22. # [00:46] <fantasai> Not sure how to balance those two things
  23. # [00:46] <plinss> click on the source file
  24. # [00:46] <fantasai> I do think the search parameters should be a query string, in general, though. They're name-value pairs.
  25. # [00:46] <plinss> (actually the plan is to have a tab interface with a view of the test in the same page)
  26. # [00:47] <fantasai> ah
  27. # [00:47] <plinss> replacing the history view
  28. # [00:48] <plinss> having the search param as path components keeps the URLs search engine friendly
  29. # [00:48] <plinss> fwiw
  30. # [00:48] <plinss> fantasai: btw, nice work on the hg docs. I'm doing another pass now...
  31. # [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?
  32. # [00:49] <plinss> small re-org and adding conflict resolution
  33. # [00:49] <plinss> possibly
  34. # [00:49] <fantasai> ?
  35. # [00:49] <plinss> (^^ to the hg docs)
  36. # [00:49] <fantasai> I think the only thing that's missing is an example of what hg says when there's a conflict
  37. # [00:49] <plinss> working on that now
  38. # [00:49] <fantasai> and what a conflicted doc looks like so you can find and fix it
  39. # [00:50] <fantasai> cool
  40. # [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...
  41. # [00:50] <plinss> I'll play with it a bit as Shepherd matures
  42. # [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?
  43. # [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
  44. # [00:51] <plinss> I have to give it some thought...
  45. # [00:51] <plinss> but not unreasonable
  46. # [00:52] <plinss> I want to evolve the functionality a bit and figure out all the possible states before making a final call there
  47. # [00:52] <fantasai> k
  48. # [00:52] <fantasai> just something to keep in mind then
  49. # [00:52] <plinss> sure
  50. # [00:53] <plinss> as I said, that's all configurable
  51. # [01:29] * Joins: nimbu (Adium@24.18.47.160)
  52. # [01:34] * Parts: jet (jet@159.63.23.38)
  53. # [01:34] * Joins: jet (jet@159.63.23.38)
  54. # [02:19] <plinss> fantasai: you probably already got the email, but I just checked in my changes to the hg docs
  55. # [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)
  56. # [02:21] <plinss> Mike has the new repo all set (with automatic checked out view) and is standing by on the reverse proxy setup
  57. # [02:24] <fantasai> plinss: hmmm
  58. # [02:24] <fantasai> plinss: I don't like the new reorganization
  59. # [02:24] <fantasai> plinss: It makes things harder to understand imho
  60. # [02:24] <plinss> somehow I knew you woudn't, that's why I added the summary section
  61. # [02:25] <fantasai> plinss: And that helps how?
  62. # [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.
  63. # [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"
  64. # [02:26] <fantasai> plinss: I want a "I want to make a change to a spec. How do I do that?" view
  65. # [02:26] <plinss> right, but that's actually what you have
  66. # [02:27] <plinss> if you follow each step
  67. # [02:27] <fantasai> plinss: Committing changes locally should be advanced topic
  68. # [02:28] <plinss> ? that's kind of fundamental...
  69. # [02:28] <fantasai> plinss: From an "I want to make changes" point of view, it's only relevant to pushing them
  70. # [02:28] <plinss> no, people should get used to committing changes in logical increments
  71. # [02:28] <fantasai> plinss: My goal is to make things as simple as possible, first.
  72. # [02:28] <plinss> all commits _are_ local by definition
  73. # [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."
  74. # [02:29] <plinss> sure, but that mental model is wrong
  75. # [02:30] <plinss> and if people don't understand that, they will get _really_ confused when they have to merge
  76. # [02:31] <fantasai> plinss: There's not much merging happening if you pull, commit, and push all within 1 minute
  77. # [02:31] <plinss> that's not exactly the most likely scenario, is it?
  78. # [02:31] <fantasai> it is if that's how you're working
  79. # [02:31] <plinss> I thought there was value in giving people a mental model of what's actually going on
  80. # [02:32] <fantasai> I think the highest value is creating the lowest bar to people being able to *start* to get their work done.
  81. # [02:32] <plinss> fwiw, you can't pull and update with uncommitted work
  82. # [02:33] <plinss> so you have to pull, update, edit, then commit, then push
  83. # [02:33] <plinss> (you can pull, but your update will fail)
  84. # [02:35] <fantasai> okay, but there are wayyyyy too many commands that you're throwing at people here all at once
  85. # [02:35] <fantasai> Read *all of this* and then you can fix a typo.
  86. # [02:36] <fantasai> You're asking me to read through all of
  87. # [02:36] <plinss> I didn't add any commands to the doc except hg resolve
  88. # [02:36] <fantasai> hg status, hg diff, hg revert, add, remove, move, copy, commit, outgoing, incoming, pull
  89. # [02:36] <fantasai> update, mrege, and resolve
  90. # [02:36] <plinss> ok, in and out
  91. # [02:36] <fantasai> before I can even push
  92. # [02:36] <fantasai> Yes, but you dumped some of the structure
  93. # [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
  94. # [02:37] <plinss> I imagine most readers know how to skim...
  95. # [02:37] <fantasai> how can they skim? They have no idea which commands are required to learn and which aren't
  96. # [02:38] <fantasai> because you're not making any distinction between what things they're used for
  97. # [02:38] <fantasai> when I learned CVS, add and remove were in an Advanced Topics section, effectively
  98. # [02:38] <plinss> ?? I think the section headings are fairly self explanatory
  99. # [02:38] <fantasai> because to edit things, you don't need to know them
  100. # [02:39] <plinss> until you rename a file and didn't know you had to use an hg command...
  101. # [02:39] <fantasai> well it won't work
  102. # [02:39] <plinss> Ok, how about I expand the summary section and move it before "working locally"
  103. # [02:39] <fantasai> Also
  104. # [02:39] <fantasai> you have a tendency to give too many options
  105. # [02:40] <plinss> it can be the "really quick overview to change a single line real quick"
  106. # [02:40] <fantasai> You coudl do it this way, or if you are in this conditoin you could do it this way
  107. # [02:40] <fantasai> or this way
  108. # [02:40] <fantasai> Just explain One Way.
  109. # [02:40] <fantasai> If people want to be clever, they can read the manual. this is not the manual.
  110. # [02:41] <plinss> I didn't add any options except the abbreviations and the rebase section (which you wanted)
  111. # [02:41] <plinss> example?
  112. # [02:41] <fantasai> The summary section has two workflows, that I have to decide between
  113. # [02:41] <fantasai> somehow
  114. # [02:41] <fantasai> not clear how
  115. # [02:42] <plinss> no, it's the same workflow, with the error that people may encounter...
  116. # [02:42] <fantasai> There were quite a few other things in the doc, that I removed...
  117. # [02:42] <fantasai> where do you hit the error?
  118. # [02:42] <fantasai> what's the error?
  119. # [02:42] <plinss> error on push
  120. # [02:42] <plinss> "hg push # resulting in an error"
  121. # [02:42] <fantasai> so instead of having two different workflows, have one
  122. # [02:43] <plinss> fine, I can simplify that section
  123. # [02:43] <fantasai> this is the work flow
  124. # [02:43] <fantasai> if you get an error here, you need to do this additional commands
  125. # [02:44] * fantasai hates all Mercurial documentation she's ever seen, it all sucks, and it's all confusing.
  126. # [02:49] <fantasai> In my ideal world, switching from CVS to Mercurial will only cost editors half an hour.
  127. # [02:49] <fantasai> When I switched from CVS to Mercurial, it took me an entire day.
  128. # [02:50] <fantasai> And, clearly, I still don't get it.
  129. # [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
  130. # [02:57] <plinss> ok, how about now. I can't make it much simpler than that...
  131. # [03:00] * Quits: nimbu (Adium@24.18.47.160) (Quit: Leaving.)
  132. # [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.
  133. # [03:01] * fantasai switches you to an ordered list, however :)
  134. # [03:01] <plinss> np, thanks for the input
  135. # [03:02] <fantasai> Other things I'd change (you can change, or I can change):
  136. # [03:02] <fantasai> put add/remove/move under heading "Managing Files", like before
  137. # [03:03] <fantasai> call hg commit "Saving Your Changes as a Changeset" or somesuch, same level as "Managing Files"
  138. # [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
  139. # [03:04] <fantasai> s/outgoing/incoming/
  140. # [03:04] <fantasai> similarly, 'hg outgoing' into 'hg push'
  141. # [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...
  142. # [03:05] <fantasai> in what case would that change my behavior?
  143. # [03:05] <fantasai> if there's stuff to merge, there's stuff to merge
  144. # [03:05] <fantasai> whether I preview it or not
  145. # [03:05] <plinss> hg pull ; hg merge vs hg pull -u
  146. # [03:06] <plinss> if hg in is empty, you can just push
  147. # [03:06] <fantasai> unless between the time I type hg in and hg push someone checks in :)
  148. # [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
  149. # [03:08] <plinss> yes, but if your rebase "just works", then you're good to go
  150. # [03:09] <fantasai> what happens if it doesn't?
  151. # [03:09] <plinss> then you can abort, as listed
  152. # [03:09] <fantasai> and then what?
  153. # [03:09] <plinss> go back and merge, as listed
  154. # [03:09] <fantasai> ok, let's say so
  155. # [03:09] <plinss> I did
  156. # [03:10] <fantasai> ah, I see. It's in reverse-chronological order, so I missed it
  157. # [03:10] <plinss> at least it's not reverse polish notation
  158. # [03:10] <fantasai> :)
  159. # [03:16] <fantasai> plinss: btw, what's the deal with teh username = bit?
  160. # [03:16] <fantasai> plinss: would a csswg.org username make sense for someone pushing to dvcs.w3.org?
  161. # [03:17] <fantasai> plinss: what if the email address on the wiki is different from the one used at W3C?
  162. # [03:17] <plinss> Shepherd uses it to sync changesets and owners with it's user DB
  163. # [03:17] <plinss> then you use the appropriate username/email for each repo in the config
  164. # [03:17] <fantasai> plinss: how do you do that?
  165. # [03:18] <plinss> in the auth section, it already lists different usernames...
  166. # [03:18] <fantasai> not under the [ui] section
  167. # [03:18] <plinss> under [auth]
  168. # [03:18] <fantasai> yes, I know
  169. # [03:18] <plinss> oh, wait, I see what you're getting at...
  170. # [03:18] <fantasai> But under [ui] your docs said to use either your csswg.org email address or username
  171. # [03:18] * fantasai didn't understand that part
  172. # [03:19] <plinss> right, it's under [ui]
  173. # [03:19] <plinss> (doing too many things at once, can't multitask like when I was your ageā€¦)
  174. # [03:19] * fantasai can't multitask either
  175. # [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
  176. # [03:20] <fantasai> how does that work?
  177. # [03:20] <plinss> there is the link to advanced config file instructions...
  178. # [03:21] <plinss> each repo has a .hg directory in it
  179. # [03:21] <fantasai> ah
  180. # [03:21] <plinss> in that .hg directory you can put another hgrc that overrides your home dir on a per repo basis
  181. # [03:21] <fantasai> right
  182. # [03:21] <fantasai> so
  183. # [03:21] <plinss> you can override anything, even extensions...
  184. # [03:22] <fantasai> how does one decide between username = Your Full Name <your@email.address>
  185. # [03:22] <fantasai> and username = your_csswg.org_username?
  186. # [03:23] <plinss> either works
  187. # [03:23] <fantasai> why would I use one over the other?
  188. # [03:23] <plinss> that bit is really only for what show up in the hg log
  189. # [03:23] <plinss> personal preference
  190. # [03:23] <fantasai> so does it matter what's put there at all?
  191. # [03:23] <plinss> don't want your email in the hg logs...
  192. # [03:23] <plinss> it's generally arbitrary
  193. # [03:23] <fantasai> so I can put anything?
  194. # [03:23] <plinss> but as I said, Shepherd cares
  195. # [03:24] <plinss> it tries to match the email adds or username to it's user db
  196. # [03:24] <plinss> s/it's/its/ (grr)
  197. # [03:24] <fantasai> does it check the login name first, or it only checks the [ui] username?
  198. # [03:25] <plinss> checking code...
  199. # [03:25] * fantasai doesn't like branches in the documentation when there's no clear conditional for which branch to take
  200. # [03:25] <plinss> username first
  201. # [03:26] <fantasai> but falls back to login name?
  202. # [03:26] <plinss> then email
  203. # [03:26] <fantasai> so, csswg.username then [ui] username?
  204. # [03:27] <plinss> no, Shepherd doesn't look at the [auth] name
  205. # [03:27] <plinss> that's the person doing the push, which may not be the same person that did the commit
  206. # [03:27] <plinss> the [ui] name is what's in the hg log with the commit
  207. # [03:29] <plinss> sorry, we were cross talking...
  208. # [03:29] <fantasai> k
  209. # [03:29] <plinss> Shepherd only looks at the name listed in [ui]
  210. # [03:29] <fantasai> ok
  211. # [03:29] <plinss> that name can be "your name <email@addr>"
  212. # [03:30] <plinss> or "your wiki username"
  213. # [03:30] <fantasai> ok
  214. # [03:30] <plinss> if the username matches, that's you, otherwise it looks for the email adds to find the account
  215. # [03:30] <plinss> s/adds/addr/
  216. # [03:30] <fantasai> got it
  217. # [03:30] <fantasai> k
  218. # [03:30] <fantasai> I think... I'm going to take a break now
  219. # [03:31] <plinss> k
  220. # [03:31] <plinss> edits done to the hg doc btw, thanks again for your help
  221. # [03:31] * fantasai is going into suspend or something
  222. # [03:31] <fantasai> thank you!
  223. # [03:31] <plinss> np
  224. # [03:31] * fantasai will look over it later
  225. # [03:31] <fantasai> But we should really get Tantek to test it
  226. # [03:31] <fantasai> the doc, I mean :)
  227. # [03:31] <plinss> I'll send an announce to the wg list
  228. # [03:33] * Quits: jet (jet@159.63.23.38) (Quit: jet)
  229. # [04:24] * Quits: dbaron (dbaron@159.63.23.38) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  230. # [04:30] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
  231. # [04:47] * Joins: krit (Adium@24.6.231.253)
  232. # [04:47] * Joins: krit1 (Adium@24.6.231.253)
  233. # [04:50] * Quits: krit (Adium@24.6.231.253) (Ping timeout)
  234. # [05:23] * Quits: krit1 (Adium@24.6.231.253) (Quit: Leaving.)
  235. # [05:25] * Quits: myakura (myakura@110.233.178.43) (Client exited)
  236. # [05:33] * Joins: myakura (myakura@110.233.178.43)
  237. # [05:35] * Quits: myakura (myakura@110.233.178.43) (Client exited)
  238. # [07:01] * Quits: miketaylr|| (miketaylr@68.203.0.108) (Quit: dflk;adfslkj;alsiekfj;laiskdf)
  239. # [10:33] * Joins: Ms2ger (Ms2ger@91.181.184.71)
  240. # [14:16] * Joins: SimonSapin (simon@82.232.219.95)
  241. # [15:06] * Joins: myakura (myakura@110.233.178.43)
  242. # [16:21] * Joins: krit (Adium@24.6.231.253)
  243. # [16:43] * Joins: jet (jet@67.169.43.128)
  244. # [17:24] * Quits: jet (jet@67.169.43.128) (Quit: jet)
  245. # [18:10] * Quits: myakura (myakura@110.233.178.43) (Client exited)
  246. # [18:37] * Quits: krit (Adium@24.6.231.253) (Quit: Leaving.)
  247. # [21:47] * Joins: SimonSapin1 (simon@82.232.219.95)
  248. # [21:47] * Quits: SimonSapin (simon@82.232.219.95) (Connection reset by peer)
  249. # [21:50] * Quits: arronei (arronei@131.107.0.118) (Connection reset by peer)
  250. # [21:50] * Joins: arronei (arronei@131.107.0.118)
  251. # [22:23] * Joins: myakura (myakura@110.233.178.43)
  252. # [23:35] * Quits: Ms2ger (Ms2ger@91.181.184.71) (Quit: nn)
  253. # Session Close: Sun Mar 04 00:00:00 2012

The end :)