|
Grex > Coop > #284: Grex Town Hall -- How do we move forward? - Fall, 2010 |  |
|
| Author |
Message |
| 25 new of 334 responses total. |
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!
|
kentn
|
|
response 294 of 334:
|
Dec 13 23:13 UTC 2010 |
Yup, svn up works on my end. So, we're good to go, I think.
|
veek
|
|
response 295 of 334:
|
Dec 15 14:43 UTC 2010 |
I was wondering, what was the reason for 'validate' in the sense that..
when Grex was hit by Chad, what used to happen.. the box would hang
with cpu at 98%, then someone had to go to reset the box? or call
provide to have it rest?? So what's wrong with that..?? Provide didn't
want to rest the box?? Or did the File-system conk-out after the
reset?? What was the actual task that was sucking up staff time and
causing so much inconvenience.. could someone clarify..
I took a look at the FS:
/dev/wd0a 1008M 115M 843M 12% /
/dev/wd0d 492M 9.6M 458M 2% /suid
/dev/wd0f 31.5G 15.7G 14.3G 52% /usr
/dev/wd0g 39.4G 13.2G 24.2G 35% /var
/dev/wd0j 9.8G 5.5G 3.9G 58% /a
/dev/wd0k 9.8G 2.8G 6.6G 30% /c
/dev/wd0m 15.7G 5.8M 15.0G 0% /tmp
/dev/wd0o 19.7G 845M 17.9G 4% /cyberspace
/dev/nnpfs0 10.6G 0B 10.6G 0% /afs
/dev/wd0a is what is critical to getting the box to boot right?? It's
the rootFS so if the box is not shutdown cleanly it gets corrupted and
fsck will bitch. It's also the smallest FS at 115MB on a 1GB partition.
IF disk corruption and having to run to provide was the problem, why
not install 2 root filesystems (mirror/duplicate - using dump/dd, /dev/
wd0a). Obviously you can only boot off one rootFS! But, lets say we
bootup from wd0a because that's the default. Once Grex is running,
point the bootloader to /dev/wd0b (our backup rootFS). Now chad comes
along and crashes the box. You call provide, tell them reset please.
They reset, and BECAUSE you've changed the boot order when Grex was
running, it will load via the secondFS and come online.
Presto! someone remote logsin, run fsck on the broken partition and you
are up and running!! (it works on linux, and i could try downloading
OBSD.. and checking.. but, is that the problem?)
----------------
Or, switch to using a journal?? Right now we are using OBSD's Fast file
system..
http://www.freebsd.org/doc/handbook/geom-gjournal.html (but that would
take time me thinks since we are on OpenBSD right now)
|
veek
|
|
response 296 of 334:
|
Dec 15 14:44 UTC 2010 |
also if i upload patches, could someone patch?? Or do I have to wait
till cross gets back.. 1 month he said.. worst case scenario..
|
jgelinas
|
|
response 297 of 334:
|
Dec 15 15:16 UTC 2010 |
I don't remember the details of what the vandals were doing, but the
result was several days of downtime. We've some pretty capable
sysadmins around here, and they could not find a way to keep the box or
get it back up quickly, as motivated as they were to find a solution.
If something as simple as you've suggested would have worked, it would
have been implemented.
|
veek
|
|
response 298 of 334:
|
Dec 15 16:09 UTC 2010 |
I've uploaded: ~veek/latest.diff could someone patch? Just to remind
you, you should also know how to rollback :p
|