|
Grex > Coop > #284: Grex Town Hall -- How do we move forward? - Fall, 2010 |  |
|
| Author |
Message |
| 25 new of 334 responses total. |
cross
|
|
response 269 of 334:
| 
Dec 12 17:15 UTC 2010 |
While it's true that steady incremental progress is better than perfection
that never comes, I also think that attention to detail is extremely
important. What we're doing right now, for lack of a better term, is
refactoring the web site. A lot of what's wrong with it is that it tried to
do too much, and in that, lots of little details are wrong. The web site is
basically dead right now, and we're trying to bring it back to life. But it
died the death of a thousand paper cuts through neglect and lack of updates.
We have an opportunity now to start fixing those little things, and making
the details right.
So pay attention to stuff like what's deprecated, and what's not, and also
to the little things: proper spacing, making sure that lines don't get too
long (try to keep them around 72 characters or less, so they'll look good in
a diff in a standard terminal window). Keep things professional: no extra
blank spaces at the ends of lines and things like that. Spell words out.
Use proper grammar. Don't overuse punctuation!!! Keep things short, succinct
and correct.
|
kentn
|
|
response 270 of 334:
|
Dec 12 17:23 UTC 2010 |
Ow! Those papercuts hurt!
Thanks to both of you for working on the site. As Dan has pointed out
to me at least once or twice, we have xmlwf installed to check the xml
code for issues. Also, it's a good idea to run 'spell' or 'aspell' on
the files to look for misspelled words (and correct them).
|
veek
|
|
response 271 of 334:
|
Dec 12 19:03 UTC 2010 |
resp:269 i think i am following (spacing, indentation etc).
The U tag are depreciated in HTML4, which means that when browsers
switch to html5 we'll have a problem BUT it also means that many of the
HTML5 tags don't work now! I know that what you are saying about not
using depreciated tags is technically correct.. but tell me something..
faq.xhtml was patched recently but blockquotes was left as is.. when it
encloses Unix shell commands. Strictly speaking we should be using
code, pre, samp.. also, the list tags don't render in FF on linux..
(and i'm not blaming you and shit like that)
My point is:
1. the browser world is all about making compromises! U tags if left as
is for the time being, won't kill anyone and can be fixed once we have
a handle on the rest of the layout!
2. You yourself work in increments! (the blockquotes). It looks good in
lynx but code/samp should be used or styles. You didn't fix it
overnight now did you?? But somehow you expect me to fix everything in
one go??
And I AM WILLING TO DO THAT! Problem is, while i spend a month fixing
stuff in my local copy (on my home PC), you will continue to push your
incremental patches SO when I try to sync with Grex the document will
have changed by then, and I'll have to spend quality time staring at
diff's.. wondering what has changed and where, and try to retype your
work into my "old" code.. (this has happened when you made changes to
faq.xhtml pine->Alpine. I had the whole thing ready to sync and I had
to look at diffs to see what had changed. Finally i just redid my work
with the "new" page.)
It makes far more sense to just patch it quickly once a substantial amt
of work is done - and bug fix quickly. Maybe an expert in reading diffs
will have no problem, and when you get someone like that who actually
does some work.. then we can follow a slower patch policy..
|
veek
|
|
response 272 of 334:
|
Dec 12 19:06 UTC 2010 |
'course i could be missing some sekret svn command to solve all this :p
|
veek
|
|
response 273 of 334:
|
Dec 12 19:14 UTC 2010 |
or let me put it in a much simpler way.. you didn't ask for volunteers
at a CS PhD program at Harvard. I know what you are saying about U tags
is correct, but I think I would find it easier to work with quick
patches and rollbacks. It's way more satisfying/gratifying in any case!
:) unless it's a root hole.. in which case feel free to point it out
strenuously..
|
kentn
|
|
response 274 of 334:
|
Dec 12 20:00 UTC 2010 |
Hi veek. What we've been doing is working on HTML code that has been
in place since the dawn of time. Dan fixed it up for formatting and
made it work for xhtml a few years back. But there are still a ton of
old-style/version tags and ways of doing things in there. And bear
in mind, too, that way back, probably a dozen people worked on the
site off and on over the years, so that probably introduced some other
inconsistencies. Do the best you can and if you run into issues let us
all know as you have been, and maybe something can be done (or ignored).
I appreciate what you are doing to make it better!
|
tsty
|
|
response 275 of 334:
|
Dec 13 08:19 UTC 2010 |
w0w .. veek/squeak is a asset ... tnx
|
veek
|
|
response 276 of 334:
|
Dec 13 13:14 UTC 2010 |
This response has been erased.
|
veek
|
|
response 277 of 334:
|
Dec 13 13:21 UTC 2010 |
*tackles tsty and sits on his head* :p thanks. hey kent, those old
pages.. are they some place i can dl?? I'll send the latest patch soon.
|
kentn
|
|
response 278 of 334:
|
Dec 13 13:51 UTC 2010 |
Since the grex web site is in SVN, I suspect you an get the really old
stuff from the repository. Just pull an older revision of a file.
However, what I was referring to was the state of the current site.
Just about any directory off the root is likely to have seen less work
and be in an older state of development.
Note that some pages should remain with old content, such as the
original bylaws and other historical documents (e.g. lawsuit and
incorporation documents). But that's not to say we shouldn't fix the
HTML code for those if it's out of date or out of compliance.
|
kentn
|
|
response 279 of 334:
|
Dec 13 14:17 UTC 2010 |
In terms of downloading the files, I've been tar.gz'ing a local copy of
the repository and downloading that for testing with other browsers.
|
veek
|
|
response 280 of 334:
|
Dec 13 14:22 UTC 2010 |
patch is uploaded (~veek/latest.diff), will send mail now. (no u tag
and other updates)
thanks kent, will do. Ah! tar.gz yeah me too! I was pondering that, but
it's best vs rsync at least for now.
--
http://www.cyberspace.org/~veek/ if there's a problem with da patch.
|
veek
|
|
response 281 of 334:
|
Dec 13 14:25 UTC 2010 |
also, what kind of mail quotas do we have??
|
cross
|
|
response 282 of 334:
|
Dec 13 14:31 UTC 2010 |
resp:271 Whoa, simmer down there, veek. What you are describing is just
the reality of working in a shared development environment. That's one reason
it's often easier to submit patches rapidly, with small changes in them. When
you talk about integrating changes out of the head branch, use the tools to
help you do that automatically; svn update is a handy thing. If there's a
conflict between something in the trunk and what you've done, then it will tell
you and you can fix the conflict. Otherwise, it'll just merge it in
automatically.
As far as deprecated tags, it's incremental improvement. Nothing happens over
night, but if you're digging into it, maybe it's good to fix those at the same
time.
This web stuff is not that hard; certainly, nothing one would find in the CS
PhD program at Harvard or any decent school.
|
cross
|
|
response 283 of 334:
|
Dec 13 14:34 UTC 2010 |
resp:281 I think the max mailbox size is like 50 megs or so.
resp:280 Looking now.
|
cross
|
|
response 284 of 334:
|
Dec 13 14:46 UTC 2010 |
resp:280 Hmm, a lot of chunks got rejected; I put most of them in
~cross/*.rej.
Veek, and Kent, I'd recommend using subversion to download a copy of the
repository directly to the machine you are doing the work on. This could look
something like:
% svn co svn+ssh://you@grex.org/var/svn/trunk/grex/web
Then, you can do an "svn update" in your local copy and automatically pick
up changes that have been synced to the mainline repository.
|
veek
|
|
response 285 of 334:
|
Dec 13 15:23 UTC 2010 |
This response has been erased.
|
cross
|
|
response 286 of 334:
|
Dec 13 15:40 UTC 2010 |
resp:285 [re: svn] Yeah, basically; it will merge whatever you have done
with whatever is in the repository. So, suppose I make a change at the top of
a file and you make a change at the bottom. The changes don't conflict. Then,
I submit my change; you do an "svn update" and pull in my latest changes. Then
my change is automatically patched into the file, and your change is
unaffected.
Suppose that the changes do conflict, though; then Subversion will tell you
there's a conflict and let you resolve it.
So it won't clobber your changes.
I think we shouldn't be underlining text at all. <u>'s should just go away
and be replaced with emphasized or strong text.
|
veek
|
|
response 287 of 334:
|
Dec 13 15:50 UTC 2010 |
resp:286 hmm.. well, maybe the diff will work now.. i did an update to
the latest 1017 and then did svn diff.. it's copied: 'latest.diff'
could you check?
|
veek
|
|
response 288 of 334:
|
Dec 13 15:51 UTC 2010 |
it ought to work now! it gave me no errors when i did the update..
|
cross
|
|
response 289 of 334:
|
Dec 13 15:51 UTC 2010 |
Yeah, give me a sec.
|
veek
|
|
response 290 of 334:
|
Dec 13 15:53 UTC 2010 |
there could be a problem with the revision tags? I removed them from my
html because svn was inserting span revision tags.. maybe if it's
pattern matching.. it might fail
|
cross
|
|
response 291 of 334:
|
Dec 13 16:32 UTC 2010 |
Yeah, it was the "$Id:$" tags screwing things up. I patched in your changes
and pushed them to production.
|
kentn
|
|
response 292 of 334:
|
Dec 13 18:34 UTC 2010 |
Thanks, Dan. I was able to checkout the current web files and now can
update them easily, I think. That will make this whole exercise much
easier!
|
cross
|
|
response 293 of 334:
|
Dec 13 23:05 UTC 2010 |
Huzzah!
|