| *** jed3 has joined #cc | 01:27 | |
| *** mlinksva has quit IRC | 04:33 | |
| *** everton137 has quit IRC | 04:46 | |
| *** Roderick_ has quit IRC | 05:21 | |
| *** sama has joined #cc | 06:18 | |
| *** parkerhiggins has joined #cc | 06:27 | |
| *** parkerhiggins_ has quit IRC | 06:44 | |
| *** nkinkade has quit IRC | 06:51 | |
| *** paulproteus has quit IRC | 07:05 | |
| *** paulproteus has joined #cc | 07:06 | |
| *** funky_cold has joined #cc | 08:41 | |
| *** balor has joined #cc | 09:39 | |
| *** sama has quit IRC | 09:46 | |
| *** Danny_B has joined #cc | 10:24 | |
| *** sama has joined #cc | 10:38 | |
| *** tvol has joined #CC | 13:58 | |
| *** jed3 has quit IRC | 14:22 | |
| *** johndoigiii has joined #cc | 14:23 | |
| *** mlinksva has joined #cc | 15:09 | |
| *** nathany has joined #cc | 15:24 | |
| *** luisv has joined #cc | 15:26 | |
| *** nkinkade has joined #cc | 15:40 | |
| *** stevel has joined #cc | 16:15 | |
| nathany | morning, nkinkade | 16:21 |
|---|---|---|
| nathany | what's your day look like? | 16:24 |
| nkinkade | nathany: good morning. | 16:31 |
| nkinkade | The early part answering email, then I was going to think about the wikis. | 16:31 |
| nkinkade | Which I wanted to talk to you about. | 16:32 |
| nathany | nkinkade: right, just saw your email | 16:38 |
| *** luisv has quit IRC | 16:44 | |
| *** rohitj has quit IRC | 16:51 | |
| nathany | nkinkade: i just replied; let me know if it doesn't make sense | 16:52 |
| nathany | morning, johndoigiii -- welcome :) | 16:52 |
| johndoigiii | good morning to you as well | 16:53 |
| nkinkade | Hi johndoigiii. | 16:53 |
| johndoigiii | hello nkinkade | 16:53 |
| nkinkade | johndoigiii: Are you in SF now? | 16:54 |
| johndoigiii | No, still in Raleigh NC | 16:54 |
| nathany | he'll be in the office next week | 16:54 |
| paulproteus | Howdy doody, all. | 16:59 |
| *** jgay has joined #cc | 16:59 | |
| nkinkade | How do, paulproteus. | 17:00 |
| nkinkade | ? | 17:00 |
| paulproteus | Well! | 17:00 |
| paulproteus | Welcome johndoigiii (I'm the Asheesh who chatted with you on the phone). | 17:01 |
| johndoigiii | Hello Asheesh | 17:01 |
| *** nathany_ has joined #cc | 17:02 | |
| *** nathany has quit IRC | 17:03 | |
| *** nathany_ is now known as nathany | 17:03 | |
| johndoigiii | so does the issues@creativecommons.org submissions work? nathany described it as "bonked" and I am having difficulties submitting an issue | 17:04 |
| johndoigiii | i could very easily be formatting these message incorrectly though | 17:05 |
| nathany | johndoigiii: still borked | 17:05 |
| nathany | the problem is that we require a project and priority to create issues | 17:05 |
| *** stevel_ has joined #cc | 17:05 | |
| johndoigiii | nathany: ahh yes, thats what my return messages are stating | 17:05 |
| nathany | and don't have a sane default for project, i guess since that's the field we added to their schema | 17:05 |
| nathany | i'm trying to remember if the default schema has a default for priority | 17:05 |
| nathany | actually i'll take a quick look at that now that you mention it | 17:06 |
| johndoigiii | alrighty | 17:06 |
| *** TRD has joined #cc | 17:08 | |
| *** everton137 has joined #cc | 17:12 | |
| *** stevel has quit IRC | 17:18 | |
| *** sama has quit IRC | 17:19 | |
| *** stevel_ has quit IRC | 17:20 | |
| *** stevel has joined #cc | 17:20 | |
| nathany | johndoigiii: it should work now | 17:20 |
| nathany | it'll create an issue w/o a project but won't let you edit it through the web interface w/o adding one. | 17:20 |
| johndoigiii | nathany: oh okay, I had one go through just a moment ago, but I specified a proj | 17:21 |
| nathany | cool | 17:21 |
| nathany | yeah, you can definitely do that | 17:21 |
| nathany | (and it's probably a little better, fwiw, but it's nice to be able to cc the tracker on "normal" email) | 17:21 |
| johndoigiii | cool, I'll go ahead and delete my issue | 17:23 |
| *** Bovinity has joined #cc | 17:35 | |
| *** robmyers has joined #cc | 17:58 | |
| *** sama has joined #cc | 18:35 | |
| *** K`Tetch_ has joined #cc | 18:55 | |
| *** everton137 has quit IRC | 19:14 | |
| *** rohitj has joined #cc | 19:33 | |
| nkinkade | nathany: Any reason I shouldn't add languages to the ccnetwork project in Poolte? | 19:54 |
| nkinkade | *Pootle | 19:56 |
| greg-g | ew, pool tea doesn't sound good at all | 19:57 |
| Bovinity | only from the freshest pool water | 20:03 |
| paulproteus | freshpool.net | 20:09 |
| nkinkade | donewith.pooltea | 20:14 |
| nathany | nkinkade: non | 20:18 |
| nathany | no, that | 20:19 |
| nathany | is | 20:19 |
| nkinkade | I figured, so I already added the language. | 20:19 |
| nkinkade | paulproteus: Your modified git-mergetool, I forgot how it worked. Something about "theirs," right? | 20:39 |
| nkinkade | Nevermind, I found the email. Forgot you had emailed me directions. | 20:42 |
| nkinkade | paulproteus: nathany: In trying to merge MW REL1_14_0 in the cc_skeleton branch of mediawiki.git, I get 277 conflicts. | 20:54 |
| nkinkade | This is not unlike the experience with CiviCRM. | 20:55 |
| nkinkade | A lot of the conflicts are in the Messages<lang code>.php files, but it's hard for me to know which changes we need to keep. | 20:56 |
| nkinkade | And it's only merging from 1_13_2 to 1_14_0. This process of using git seems like a hassle in many ways. | 20:57 |
| nathany | I can just about guarantee they're all spurious -- those are the equivalent of PO files, IIRC | 20:57 |
| nathany | paulproteus: thoughts? | 20:57 |
| nkinkade | Right, but there are other legitimate files and I don't know which changes were done by us. | 20:57 |
| nkinkade | I could find out by looking through history, but that seems crazy and laborious. | 20:57 |
| nkinkade | I wouldn't have been able to do the git merge for CiviCRM without the intervention of paulproteus. | 20:58 |
| nkinkade | And him making some changes to git-mergetool. | 20:58 |
| nathany | my understanding was that using git-svn meant git was aware of the changes between, say, 1.13.2 and 1.14.0, so that it would be able to merge sanely; paulproteus? | 20:59 |
| nkinkade | That was my thought as well, but this Mediawiki merge and the CiviCRM merge were packed with conflicts. | 20:59 |
| nathany | let's wait for him to get back and see if he has insight into why that is | 21:00 |
| nathany | maybe we should be rebasing instead of merging | 21:00 |
| johndoigiii | hey everyone, I having been trying to get commoner to build out, but keep receiving errors when trying to fetch the lxml dependency. | 21:00 |
| nkinkade | nathany: I'm just going to do the monitor install from the git repository, but rather than any merging, I'll just do a checkout of 1.14.0 | 21:01 |
| johndoigiii | anyone have experience installing this library on Mac OSX? | 21:01 |
| nkinkade | nathany: That will mean that we'll miss out on any mods to the code that we have in cc_skeleton, but I don't know how many we have anyway. | 21:01 |
| nkinkade | We could also do this with subversion, and just track their tree directly and at upgrade time do an svn switch. | 21:02 |
| nkinkade | Why are we doing it with git-svn, again? | 21:02 |
| nkinkade | Honestly, I can't remember. | 21:02 |
| nkinkade | I've learning to detest Mediawiki as it is, but things like this make me dislike it even more. | 21:03 |
| nathany | nkinkade: we're doing it because it lets us do patching/mods as needed which svn:externals doesn't | 21:03 |
| nathany | johndoigiii: what error are you getting? | 21:04 |
| nathany | i have built it on OS X, but i think my setup is a little non-standard | 21:04 |
| paulproteus | nathany, rehi | 21:04 |
| paulproteus | So that we can have local commits, for example. | 21:04 |
| paulproteus | Also because I'm a git fan. | 21:04 |
| paulproteus | I can give other reasons I'm a git fan, like it's fast, and I Really Understand it. | 21:04 |
| paulproteus | For example, we have that source patch in the ccLearn wiki. | 21:04 |
| paulproteus | Except that one's not gitified, so it just sits there as an uncommitted change in an svn repo. | 21:04 |
| paulproteus | nkinkade, iirc upgrading between point releases was very easy. | 21:04 |
| nkinkade | paulproteus: Then maybe upgrades of Mediawiki are something that you can handle. | 21:05 |
| nkinkade | Seriously. | 21:05 |
| johndoigiii | nathany: http://pastebin.com/m71ab8ac8 | 21:05 |
| paulproteus | The history with git-svn plus branch switches by upstream gets messy because of differences in the git and svn history model, I suppose. | 21:06 |
| nkinkade | I Don't Really Understand git, nor do I have a strong desire to. | 21:06 |
| nkinkade | I only want to know enough to use it for basic things, and beyond that I'm donewith.git | 21:07 |
| nathany | johndoigiii: i'm looking at it now | 21:07 |
| nathany | i suspect the problem is either a) missing headers or b) version issues | 21:07 |
| nathany | are you running using the Python interpreter Apple ships? | 21:08 |
| paulproteus | Whoa, a Mac user? Freaky-deaky. | 21:08 |
| paulproteus | nkinkade, I don't want you to live a life of aggravation any more than you have to. | 21:08 |
| nkinkade | paulproteus: So you think the conflicts are the result of something being lost in translation with git-svn? | 21:09 |
| paulproteus | It's the opposite; it's that git-svn uses information svn ignores.... | 21:09 |
| paulproteus | But 'rebase' might be a better plan than 'merge'. | 21:09 |
| paulproteus | Let me give that a shot to see how it goes. | 21:09 |
| nkinkade | Thanks. | 21:09 |
| nathany | johndoigiii: so it's *at least* a version issue; according to the pastebin (thanks for that, btw) you have lxml 1.1.12 and lxml needs 1.1.15 (http://codespeak.net/lxml/installation.html) | 21:10 |
| paulproteus | nkinkade, But on the other hand, if you understood git, you would gain more effective access to its power. | 21:12 |
| *** rohitj has quit IRC | 21:12 | |
| nathany | johndoigiii: i tend to build a non-stock Python on OS X and install libraries like libxml2 and libxslt1 into my home directory (--prefix=~) | 21:13 |
| nathany | i'm on a call right now, but maybe creating a new user to test that with would be one way forward? | 21:14 |
| johndoigiii | alright I will give that a try | 21:14 |
| nathany | (if you don't want to pollute your current home) | 21:14 |
| nathany | i'll ping you when i'm done with the call to see where you are with it | 21:14 |
| johndoigiii | sounds good, thx | 21:14 |
| *** TRD has quit IRC | 21:15 | |
| nkinkade | paulproteus: Did rebase help? | 21:34 |
| paulproteus | nkinkade, I'm going to have to finally do what I hoped I wouldn't have to do, which is devise a sound, sane workflow for git-svn based upgrades. | 21:34 |
| paulproteus | I'm experimenting with that now. | 21:34 |
| paulproteus | I believe I understand the problem well, anyway. | 21:34 |
| nkinkade | Cool. Thanks. | 21:35 |
| nkinkade | I've got 6 MW installs in the queue, which makes me somewhat sick in itself, but the thought of having to upgrade a dozen or so MW installs every so often is even more sickening. | 21:35 |
| nkinkade | Actually, installing is easy, it's the upgrading that is just time-consuming. | 21:36 |
| paulproteus | Yeah. | 21:38 |
| paulproteus | I'm doing: | 21:39 |
| paulproteus | $ git diff origin/tags/REL1_13_2..cc_skeleton | less | 21:39 |
| paulproteus | just to get a sense of what the patch entails. | 21:39 |
| paulproteus | Oops, piping to less is a mistake. | 21:40 |
| nathany | paulproteus: does the .. syntax mean between 1.13.2 and cc_skeleton? | 21:41 |
| nathany | i haven't seen that before | 21:41 |
| paulproteus | Yes. | 21:41 |
| paulproteus | Looks like I can drop the ".." and just put a space there. | 21:41 |
| paulproteus | That's more sane and I will always do that from now on. | 21:41 |
| paulproteus | So ignore the new syntax you learned and pass in separate arguments, I'd say. | 21:42 |
| paulproteus | nkinkade, Because we have the local commits, here's what I imagine would be a reasonable UI. | 21:43 |
| paulproteus | First you get presented each patch we have against the current release and the commit log message explaining it. | 21:44 |
| paulproteus | You get asked, "Do you want to ditch this?" | 21:44 |
| paulproteus | Since we here in reality, where upstream takes some things but not others, the more patches you ditch, the easier the merge will be. | 21:44 |
| paulproteus | And then it tried to apply each to the new release, and where there's a conflict, it lets you edit. | 21:45 |
| paulproteus | You do this once per release, and then you can just "pull" from each of the MW installations we have. | 21:46 |
| Bovinity | is it our office connection, or is support.cc.org still heinously slow? | 21:46 |
| paulproteus | Due to reality, I don't think that anything much less complex has a hope of working. | 21:46 |
| paulproteus | Seems decently fast to me from home, Bovinity. | 21:46 |
| nathany | Bovinity: seems semi-snappy | 21:47 |
| nathany | is it because you're logged in? | 21:47 |
| Bovinity | yeah, it goes a tad faster when i log out. | 21:50 |
| nkinkade | paulproteus: What changes have we ourselves made to the MW code? | 21:51 |
| paulproteus | So there's the obviously-ours stuff, which is files we added that aren't in upstream (like LocalSettings.php). | 21:52 |
| paulproteus | But we've modified EditPage.php and GlobalFunctions.php with trivial whitespace modifications. | 21:52 |
| * paulproteus keeps reading | 21:52 | |
| paulproteus | We seem to have added Image.php out of nowhere, presumably because it existed in an older revision of MW and we didn't lose it at an upgrade. | 21:53 |
| paulproteus | We've appended to the end of Setup.php as well as the middle of it (I have no idea why). | 21:53 |
| paulproteus | includes/SkinTemplate.php we have some odd changes to. | 21:53 |
| paulproteus | We seem to have created includes/SkinTemplate.php.copy which may contain the original SkinTemplate.php. | 21:54 |
| paulproteus | You can see this yourself with the "git diff" command I gave above, so long as you have a local branch cc_skeleton that points at the same rev as cc_skeleton in the code.creativecommons.org repo. | 21:56 |
| nkinkade | paulproteus: I do have that local branch. | 21:56 |
| paulproteus | Cool. | 21:56 |
| nkinkade | paulproteus: Earlier, before you posted your comments about git diff, I had got some diff up by doing "git checkout cc_skeleton; git diff origin/tags/REL1_13_2" and it seemed to have useful diffs. | 21:57 |
| nkinkade | But it may not have been the diffs I thought I was looking at. | 21:57 |
| paulproteus | That is what you want, though possibly reversed. | 21:58 |
| paulproteus | Same thing, except possibly reversed (and it's easy enough to tell from the diff output). | 21:58 |
| nkinkade | It seemed normal, not reversed, that is. | 21:58 |
| paulproteus | Great. | 21:58 |
| nkinkade | There were pluses by the things I new we had added. | 21:58 |
| * paulproteus nods | 21:59 | |
| nkinkade | *knew | 21:59 |
| paulproteus | We change e.g. maintenance/commandLine.inc. | 22:00 |
| nkinkade | paulproteus: So there's really no way around the conflicts and the resulting need to go through >250 of them manually, at least without special scripting each time? | 22:02 |
| paulproteus | That's not what I'm saying. | 22:02 |
| paulproteus | The language files, for example, are due to the mismatch between what git should be doing and what it is. | 22:02 |
| nkinkade | So you're saying that we blindly accept change to files we know we haven't touched, and then manually look at ones that changed that we also modified? | 22:03 |
| paulproteus | I suggested a "reasonable UI" about half a page up. | 22:03 |
| paulproteus | Would that work for you? | 22:03 |
| nkinkade | I think that would be fine. | 22:04 |
| paulproteus | Cool. I'll go back to thinking about that for a bit. | 22:04 |
| nkinkade | One potential problem is when some change implemented upstream could conflict with what we've changed. | 22:04 |
| paulproteus | That's unavoidable, yeah. | 22:04 |
| paulproteus | But I *firmly agree* with the need to not pain the user with spurious conflicts. | 22:05 |
| nkinkade | And since I have no idea whatsoever why most of the changes we made were done, then I'd have no way to how to handle things. | 22:05 |
| *** rohitj has joined #cc | 22:05 | |
| nkinkade | (to *know* how) | 22:05 |
| nathany | nkinkade: sure, but that's sort of a completely different issue :) | 22:06 |
| paulproteus | Just throw away the changes you can't justify, and email webmaster saying "this is what I did; suck it". | 22:06 |
| nathany | paulproteus: does doing a diff between the previously imported version (say, 1.12) and the newest version (1.14) give us anything useful? | 22:06 |
| nkinkade | It may be 2 issues, but they are intertwined. | 22:06 |
| nkinkade | Probably just about 300 more conflicts. | 22:07 |
| paulproteus | nathany, Well, here's the thing. git doesn't intrinsically see the difference between MW-official changes and CC additions. | 22:07 |
| nathany | right | 22:07 |
| nathany | i'm just thinking about a diff that might apply more cleanly | 22:07 |
| nathany | (for some definition of cleanly) | 22:07 |
| paulproteus | Right - you're saying, apply the diff between LAST_MERGED and LATEST_RELEASE on top of the skeleton? | 22:08 |
| nathany | right | 22:08 |
| paulproteus | Trying now. | 22:08 |
| *** sama has quit IRC | 22:08 | |
| nathany | my only thought is that it'd be good to avoid building lots of custom tooling if we can possibly avoid it (where lots is a value > 0) | 22:09 |
| nathany | johndoigiii: any luck with the lxml stuff? | 22:10 |
| *** stevel_ has joined #cc | 22:10 | |
| johndoigiii | I feel like I am getting closer, I've installed later versions of the libraries | 22:12 |
| nathany | cool | 22:12 |
| nathany | is it still barfing when it tries to build the egg? | 22:12 |
| johndoigiii | yes | 22:12 |
| johndoigiii | still seeing the older versions | 22:12 |
| nathany | hrm | 22:12 |
| johndoigiii | trying to set up aliases | 22:13 |
| johndoigiii | following these instructions http://ripary.com/libxml2_leopoard.html | 22:13 |
| *** stevel_ has quit IRC | 22:13 | |
| *** [mharrison] has quit IRC | 22:13 | |
| *** stevel_ has joined #cc | 22:13 | |
| paulproteus | nathany, Conflicts still with your approach. | 22:13 |
| johndoigiii | this isn't working for me, so I just added a new user and am going to try your idea | 22:13 |
| paulproteus | Going to not look at IRC or email for a bit and focus on this; ping me if needed. | 22:14 |
| *** stevel has quit IRC | 22:14 | |
| nathany | johndoigiii: yeah, that looks like it'll work but sort of gets you involved in Framework -hell (the distant cousin of dll-hell) | 22:14 |
| johndoigiii | yeah tell me about it | 22:15 |
| nathany | one other thing i've found useful is setting LD_LIBRARY_PATH before i run the buildout | 22:15 |
| johndoigiii | yeah I read that as well | 22:15 |
| nathany | I can't remember if that works on OS X or not... but i seem to remember it helps make it find the libraries i want first | 22:15 |
| paulproteus | nkinkade, Okay, so if you totally abandon our changes in that one massive "Added CC-specific changes to the base MW install" commit, moving our changes forward is easy. | 22:24 |
| paulproteus | For another thing, I think it makes way more sense to use the concept of rebase rather than the concept of merge, even though the vocabulary isn't as clear. | 22:25 |
| paulproteus | I can provide to you a sensible, comprehensible explanation for all of this if you're willing to stay with me and ask questions when it seems to make no sense. | 22:25 |
| paulproteus | And it requires zero custom tooling, and can be achieved mostly by right-clicking in gitk and clicking "cherry-pick this commit". | 22:25 |
| paulproteus | Note that some of the clicking could be automated away, but it's not so bad really. | 22:26 |
| paulproteus | I also think no one will miss those old changes, and if they do, then by Jove they can make commits with good commit log messages to explain why they wanted them. | 22:26 |
| nkinkade | paulproteus: That seems fine. | 22:26 |
| nkinkade | So, I could use your modified git-mergetool to just always accept their changes: "theirs" | 22:27 |
| nathany | paulproteus: can you send a message to webmaster with a link to that commit diff on viewgit? | 22:27 |
| paulproteus | nathany, Heck yes. | 22:27 |
| nathany | thanks -- that way people can skim it | 22:27 |
| paulproteus | nkinkade, No, you're going to have to move to a different workflow that doesn't involve the word merge at *all*. | 22:27 |
| nkinkade | paulproteus: Ah, rebase. | 22:27 |
| paulproteus | Bingo. | 22:27 |
| paulproteus | Unfortunately, this will require creating a new name for the CC skeleton every time we switch what we're based on. | 22:28 |
| paulproteus | Or, well, not doing that, but being careful instead. | 22:28 |
| paulproteus | You know, I need a haircut. | 22:28 |
| paulproteus | Anyway. | 22:28 |
| Bovinity | bash 4.0! | 22:28 |
| nkinkade | Is rebase not dissimilar to svn switch? | 22:28 |
| paulproteus | rebase is totally similar to svn switch. | 22:29 |
| paulproteus | nkinkade, Here, let me have you try something. | 22:29 |
| nkinkade | nathany: So, until we get some of these details hammered out, how do you suggest I proceed, since we need some of these wikis sooner than later? | 22:30 |
| nkinkade | paulproteus: Shoot. | 22:30 |
| paulproteus | I can hammer these details out right now with you. | 22:30 |
| paulproteus | nkinkade, $ git branch new-skeleton origin/tags/REL1_14_0 | 22:30 |
| paulproteus | $ git checkout new-skeleton | 22:30 |
| paulproteus | Now look in gitk --all, and look for the cc_skeleton branch pointer. | 22:30 |
| paulproteus | Note that every point you see on the left is a commit. Most of the recent history of cc_skeleton is merge commits. | 22:31 |
| paulproteus | Before the merge commits, back in July 2008, you'll see some actual commits, including the infamous "Added CC-specific changes to the base MW install". | 22:32 |
| paulproteus | The best way to go backwards is to click in the Parent: XXX links. | 22:32 |
| paulproteus | You can use the forwards and backwards buttons as if gitk were a web browser. | 22:32 |
| paulproteus | Let me know if you see or fail to see those. | 22:33 |
| nkinkade | paulproteus: I see those things. | 22:41 |
| nkinkade | So now I just cherry-pick the commits I had made? | 22:41 |
| paulproteus | Yeah! | 22:42 |
| paulproteus | You can right-click them in gitk and hit cherry-pick, even! | 22:42 |
| paulproteus | Or you can "git cherry-pick REVISION". | 22:42 |
| nkinkade | So basically I'll need to cherry-pick each commit that was made by a CCer? | 22:42 |
| paulproteus | Yeah, but now you'll have beautiful linear history rather than history that snakes into the past, tied down with merge commits. | 22:43 |
| paulproteus | Oh, and test. (-; | 22:43 |
| paulproteus | I mis-spoke earlier: "git checkout" is like "svn switch", really. | 22:44 |
| nkinkade | paulproteus: Why are the commits not chronologically ordered in gitk near the time of our changes? | 22:45 |
| paulproteus | They're in commit history order, constrained by the merges. | 22:47 |
| paulproteus | I hope that makes *some* sense? | 22:47 |
| paulproteus | For example, if I do a merge of REL1_13_1 a year after 1_13_1 happened, that shows up right on top of 1_13_1. | 22:48 |
| paulproteus | But also so does the MediaWiki commits that took place right after 1_13_1. | 22:48 |
| paulproteus | So that would cause chronological mis-ordering. | 22:48 |
| nkinkade | Ah. That makes sense. | 22:51 |
| paulproteus | Hooray, sense! | 22:51 |
| paulproteus | This is git-svn MW workflow version 2. | 22:52 |
| nkinkade | paulproteus: When I tried to cherry-pick the "Added CC-specific changes ..." I get an error popping up. Lots of conflicts, then a child process exited abnormall." | 22:52 |
| paulproteus | Yeah. | 22:52 |
| paulproteus | That one's a total nightmare. | 22:52 |
| paulproteus | Grab what you need from it, and ditch the rest. | 22:52 |
| paulproteus | Like LocalSettings.php. | 22:52 |
| nkinkade | This seems error prone. | 22:52 |
| *** johndoigiii has quit IRC | 22:52 | |
| paulproteus | Ditching that horrible commit is a *goal* of redoing the workflow. | 22:52 |
| *** johndoigiii has joined #cc | 22:52 | |
| paulproteus | No more commits in the CC MW history that can't be explained. | 22:52 |
| paulproteus | Let's end the insanity once and for all, or else it will haunt us forever. | 22:53 |
| paulproteus | I'd say "git cherry-pick" it on the command line, and as it fails, undo the parts you don't want. | 22:53 |
| paulproteus | I'd offer to do that for you, but you should probably be familiar enough with this stuff to do that. | 22:54 |
| paulproteus | I'll do it with you so I can quickly answer questions, though. | 22:54 |
| paulproteus | (Does that also make sense as a plan?) | 22:54 |
| nkinkade | How do you plan to go through it with me? | 22:55 |
| nkinkade | Verbally? | 22:55 |
| nkinkade | And you're saying I should cherry-pick that commit, let it blow up and then manually reset the files we don't want? | 22:56 |
| paulproteus | nkinkade, Yes re: "And you're..." | 22:56 |
| paulproteus | go through it with you: via IRC, I was thinking | 22:56 |
| *** robmyers has quit IRC | 22:57 | |
| paulproteus | But I'd do the same commands as you... | 23:00 |
| paulproteus | ...you know, why don't we screen-share? | 23:00 |
| paulproteus | Then you can just say "wtf" every few minutes on IRC and I'll see what's up. | 23:00 |
| *** johndoigiii has quit IRC | 23:00 | |
| paulproteus | How about I join you in a "screen -x" on one of the CC servers? | 23:00 |
| paulproteus | (or sf.creativecommons.org...) | 23:00 |
| *** johndoigiii has joined #cc | 23:00 | |
| nkinkade | paulproteus: We could do that. I'll try it here on my local copy first. | 23:01 |
| paulproteus | Okay, cool. | 23:01 |
| nkinkade | At the moment I'm just manually resolving the conflicts from the merge of that commit. | 23:01 |
| paulproteus | From the cherry-pick. | 23:02 |
| paulproteus | And hopefully you're erasing almost all of it. | 23:02 |
| paulproteus | Since that commit is the spectre that haunts our lives. | 23:02 |
| nkinkade | I'm dumping things from that commit and keeping what's in HEAD, unless it's obvious it's a change we made. | 23:05 |
| paulproteus | Super rad. | 23:06 |
| nkinkade | Bovinity: Do you know of changes that have been made to the code for wiki that need to remain, not including the CC4 skin? | 23:21 |
| nkinkade | paulproteus: nathany: I'm resolving these conflicts manually and most of them seem like things we never altered ourselves. | 23:22 |
| nkinkade | Do either of you know of any secific changes we've made to the MW codebase? | 23:22 |
| nkinkade | I'm guess what I'm wondering here is if we're better of just starting with a totally clean 1.14 checkout and go from there. | 23:23 |
| nkinkade | And then do commits as we need them, and in a more incremental fashion. | 23:24 |
| paulproteus | nkinkade, I agree, and that's my point; that's what you're doing if you cherry-pick only the changes we want. | 23:24 |
| paulproteus | The "changes we want" mostly are the submodules. | 23:24 |
| nkinkade | paulproteus: I'm saying not to cherry pick anything at all, including the submodule stuff. | 23:24 |
| nkinkade | Because I'd like to redo the submodule stuff anyway. | 23:24 |
| paulproteus | Okay, fine with me. | 23:24 |
| paulproteus | And that will be your way of getting us clean history, and throwing away all CC stuff that doesn't have clean commit history. | 23:25 |
| nkinkade | I'm just going to do it that way. We've got the git history if it turns out we needed some of those changes, but I see that as unlikely. | 23:25 |
| nkinkade | Exactly. | 23:25 |
| nkinkade | It's likely that those "CC-specific" changes were CC-specific at all and were just cruft left over from a years of upgrading. | 23:26 |
| nkinkade | *weren't | 23:26 |
| *** stevel has joined #cc | 23:30 | |
| *** mlinksva has quit IRC | 23:43 | |
| *** stevel_ has quit IRC | 23:46 | |
| paulproteus | nkinkade, Lemme know once you push, and I'll make sure we say something sensible to webmaster. | 23:49 |
| paulproteus | As we embark down the road toward sanity. | 23:49 |
| nkinkade | paulproteus: I was thinking of doing the same type of setup like we have for CiviCRM, with cc_production and cc_staging branches. | 23:50 |
| nkinkade | Does that seem right to you? | 23:50 |
| nkinkade | Also, for the submodules, I'm only going to create submodules for those extensions that actually have their code in some type of repository. | 23:51 |
| nathany | paulproteus: libapache2-mod-fastcgi is the chinese variant in ubuntu/debian? | 23:51 |
| paulproteus | No! That's the evil American one. | 23:51 |
| paulproteus | libapache2-mod-fcgid | 23:52 |
| nathany | ah | 23:52 |
| paulproteus | Note that the American one is non-free. | 23:52 |
| paulproteus | Think about *that*.... | 23:52 |
| nathany | LOL | 23:52 |
| * paulproteus giggles. | 23:52 | |
| nkinkade | If the extension is just an unversioned PHP file or code that you cut-n-paste from the MW site. | 23:52 |
| nathany | paulproteus: btw, i keep seeing http://pastebin.com/m1fe59401 on this ubuntu box i admin | 23:53 |
| nathany | (non-CC) | 23:53 |
| nathany | any ideas? | 23:53 |
| paulproteus | dpkg-reconfigure locales # and check the box for that locale | 23:53 |
| nathany | thanks | 23:54 |
| nathany | http://pastebin.com/m2220adbb | 23:54 |
| nathany | paulproteus: ^^ | 23:54 |
| nathany | (there was no box to check) | 23:54 |
| nathany | paulproteus: manually installing language-pack-en seems to have fixed it | 23:59 |
| nathany | thanks :) | 23:59 |
Generated by irclog2html.py 2.6 by Marius Gedminas - find it at mg.pov.lt!