Perl 6 - the future is here, just unevenly distributed

IRC log for #webwork, 2013-02-26

| Channels | #webwork index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
04:08 rbeezer joined #webwork
13:38 mgage joined #webwork
14:04 goehle_ joined #webwork
17:58 Paul__ joined #webwork
20:12 Paul__ joined #webwork
21:59 goehle_ hey mgage
21:59 mgage hi
21:59 goehle_ I'm taking a look at the achievements stuff now
21:59 mgage k
21:59 goehle_ the file TestCourse_achievemetns.axp in templates/achievements
21:59 goehle_ should be removed
22:00 mgage ok -- I can do that pretty easily
22:01 goehle_ you should probably go into curvature.at and remove the set specific stuff
22:01 goehle_ just change Set10
22:01 goehle_ and Set11
22:01 goehle_ to SetNameHere
22:01 mgage ok -- guess I missed that
22:02 goehle_ its not the biggest deal
22:02 goehle_ this is actually your recommendation
22:02 goehle_ but a lot of those .at files dont have corresponding entries in default_achievements.axp
22:02 goehle_ I just put the .at files and icons in there to help anyone who was poking around and wanted some extra stuff
22:03 goehle_ umm
22:03 mgage ok -- so I didn't quite know what to do with the default_achievements.axp -- whether to add or remove entries from it -- does it look ok as it is?
22:03 goehle_ its_all_relative.at should have TestSet changed to SetNameHere
22:04 goehle_ the only thing that could be changed is that the challenge achievements might be removed
22:04 goehle_ techinically they are course specific, since they only work if you have a "Challenge" set
22:04 goehle_ but I think its clear that they wont work for your course if you dont have challenge problems
22:04 goehle_ so it wont cause confusion
22:04 goehle_ what do you think?
22:04 mgage I think we can leave those -- you explain what to do in your blog post.
22:04 goehle_ right
22:05 goehle_ hmmm
22:05 goehle_ defaults coudl use some work
22:05 goehle_ hmm
22:06 goehle_ yeesh, sorry, I thought I had these cleaner
22:06 goehle_ lines_and_planes.at should have SetNameHere
22:07 goehle_ so should partial_derivatives.at
22:07 goehle_ hmm
22:07 goehle_ maybge I should change
22:07 goehle_ all this stuff
22:07 goehle_ upload it to my account
22:07 goehle_ and then do a pull request
22:09 mgage actually that's a good idea -- just for practice -- I was just starting to make some changes.
22:10 mgage do a git pull from openwebwork/webwork2-dev branch ww2.5.1.3 before you start work so that the pull request will merge smoothly.
22:11 mgage also I'm putting all of this stuff in ww2.5.1.3 and trying to make as few changes as possible to ww2.5.1.1   -- is that ok with you?
22:11 goehle_ yeah thats fine
22:11 goehle_ I think I reference ww2.5.1.3 in my blog post
22:11 goehle_ so its ok if thats the one that matches
22:11 mgage we might have to change the version number in your post that people have to get ww2.5.1.3 to get the latest version of your achievements
22:12 mgage I think it was ww2.5.1.1 -- but I don't think it will make a big difference -- ww2.5.1.1 has achievements just not the latest changes you've made
22:13 mgage I think you had ww2.5.1.1 in your blog post.
22:13 mgage (very nice by the way)
22:13 mgage thanks
22:13 goehle_ oh
22:13 goehle_ ah well
22:13 goehle_ its probably fine
22:13 mgage it's easy to edit -- shall I change the reference in the blog post?
22:14 goehle_ yeah
22:14 goehle_ on of the cs students here tells me hes going to hack webwork
22:15 mgage done
22:16 mgage hack in which sense?
22:16 goehle_ he was unspecific
22:17 goehle_ hmm
22:17 goehle_ it occurs to me that I should mention in my blog post
22:17 mgage we've had very few security breaches -- I can't tell whether it's because no one has been able to or no-one has tried
22:17 goehle_ that unless its a fresh install
22:17 goehle_ you probably dont have those files in your folders
22:17 goehle_ then again I do explain where to get the stuff if you dont have it
22:18 goehle_ did you change the course admin stuff so that it copies over things in html ?
22:19 goehle_ I just created a new course
22:19 goehle_ and the achievements made it over
22:19 goehle_ but the icons didn't
22:19 mgage yes -- it does do that -- and it creates the achievements table if it is not present
22:19 mgage I think -- let me check
22:20 mgage what doesn't happen is for the new version of modelCourse to be updated from courses.dist   -- so that might puzzle people for a bit.
22:20 goehle_ right
22:20 goehle_ but I copied my courses.dist model course
22:20 goehle_ into the course directory
22:23 mgage I verified the bug -- it creates the achievements directory but it doesn't copy over the contents.
22:23 goehle_ ok, good to know
22:29 goehle_ how long does it take for commits to show up on git
22:29 goehle_ shouldn't they be there quickly?
22:31 mgage on your github they should be there immediately
22:32 mgage which branch did you push your changes to?
22:33 goehle_ eh git
22:33 goehle_ I"m confused
22:34 mgage you have a git repository on your own machine -- to publish those to a wider audience you push your changes up to your github account.
22:34 goehle_ I know
22:34 goehle_ but I might have been in the wrong branch
22:34 goehle_ but when I switched branches my chagnes were gone
22:34 goehle_ and I have to figure out how to pull changes from one branch to another
22:35 mgage git remote -v   will show you your remote aliases
22:35 mgage git branch -vv   is handy -- it shows you your branches and which branch they are connected to upstream
22:35 goehle_ bah, now it wont pull from your thing because I have files
22:36 mgage do git stash    ,  git pull openwebworkalias   ww2.5.1.3
22:36 mgage then I think  it's    git stash pop (this will take your changes and overwrite what you just pulled if neceesary)
22:37 mgage first make sure you are on your local ww2.5.1.3 branch with   git branch -vv
22:37 goehle_ yeah, I think I've switched to that nwo
22:38 mgage about copying over to html -- do you think I should copy over everything in the html directory?  or just achievements?
22:38 mgage maybe everything except the html/tmp directory if that exists.
22:38 goehle_ yeah,
22:38 goehle_ that woudl be my idea
22:38 goehle_ other people might eventually put flash there or something
22:39 goehle_ how do I list conflicts again
22:39 mgage what does git status show you?
22:40 goehle_ no conflicts
22:40 mgage when you do the git pull   you will get a list of conflicts if there are any -- I'm not sure off the top of my head how to get it again.
22:40 goehle_ but I am getting stuff about codemirror2
22:40 goehle_ not being added to the repo
22:40 goehle_ Not sure what that is
22:41 mgage I think you can ignore that for now.  I believe that is because it not really part of our git repository -- it's a pointer to another git repository from which you can grab code mirror.
22:41 goehle_ ah got it
22:41 goehle_ for all that messyness the pull request to your repo is pretty clean
22:41 goehle_ only the files I changed are showing up
22:42 mgage codemirror is supposed to allow us text highlighting, for example in the PGeditor.  Djun Kim added it -- isn't quite ready for prime time yet
22:42 goehle_ ah ok
22:42 goehle_ well I put my pull request through
22:42 goehle_ it deletes TestCourse_Achievements.axp
22:42 goehle_ changes default to be better (removes the calculus specific stuff)
22:42 goehle_ and fixes all the other things I thought I had fixed before
22:43 mgage you probably did -- I might have messed some stuff up as I got it ready to be applied to openwebwork
22:44 goehle_ no worries.  Live an learn.  (especially with git in my case)_
22:44 goehle_ the pull request to you *should* be clean
22:44 goehle_ let me know if there are any issues
22:44 mgage me too -- but I don't see your pull request yet on openwebwork
22:44 goehle_ oh, I pulled to mgage
22:44 goehle_ want me to do one to open webwork?
22:44 mgage ah -- ok I see it to me.
22:45 mgage yes -- put the pull request to openwebwork too -- then I can pull it in there
22:45 mgage the nice thing about using github (and not just git) is that there is a reasonably open record of what has been happening
22:46 mgage so people can look at a repo and decide for themselves whether they think it's stable or that there have been a lot big changes made recently
22:46 goehle_ ok, now the pull requrest to open webwork has a some stuff that was in your mgage 2.5.1.3
22:46 goehle_ is that ok?
22:46 mgage I think so -- just a se
22:48 mgage yes -- it will merge cleanly.  I think the commit numbers are still the same -- so it just skips patches it has already applied
22:48 goehle_ ok
22:48 goehle_ great
22:48 goehle_ well hopefully that all works
22:49 goehle_ I should head home though
22:49 goehle_ let me know if there are any issues
22:49 goehle_ and what should I work on next, now that I got the blog post (finally) done
22:49 goehle_ I was thinking sending comments to essayAnswers via email
22:50 mgage ah -- I see.  since you pulled from me instead of from openwebwork there is a base64 commit for knowls that I submitted to openwebwork but hadn't pulled yet -- I'm trying to set a precedent (eventually at least) that no-one merges their own pull request
22:51 goehle_ ah
22:51 goehle_ sure
22:51 mgage one more thing -- can you see whether your pull request will merge cleanly?  I thought one couldn't see that on github unless one had write access to the repository
22:52 mgage but I may be confused about this.  for example what do you see at https://github.com/openwebwork/webwork2-dev/pull/93
22:52 goehle_ how should I check that
22:52 goehle_ I see the list of files changed and whatnot
22:52 goehle_ most of it is achievement stuff
22:52 mgage I see  a green bar with "this pull request can be automatically merged"
22:52 goehle_ but there are some other edits
22:52 goehle_ I dont see that
22:52 goehle_ but I dont have write permission to openwebwork
22:53 mgage ok -- you mentioned something about merging cleanly -- but I guess you said "should" merge cleanly
22:54 goehle_ well
22:54 goehle_ on my machine I am up to date with you, openwebwork, and my repo
22:55 mgage so I had the right I idea -- you can't see the little green light sign I get.  it's too bad in a way because it would be nice if some submitting a pull request could tell if it was going to be a clean merge.  if it wasn't they could take it back, do some clean up and try again.
22:55 goehle_ yeah exactly
22:55 goehle_ all I can really do is check to see tha tthey merge on my machine
22:56 mgage right -- well I'll look around and maybe ask -- because it would be a nice feature for github.
22:56 mgage github has a couple of things that are kind of useful for what we are doing -- for example click on the "branches" tab:
22:56 mgage https://github.com/openwebwork/webwork2-dev/branches
22:57 goehle_ thats nice that it shows how far ahead things are
22:57 goehle_ and you can compare
22:57 mgage exactly -- and once we figure this out a bit and write instructions people can look at github and make intelligent decisions about where they feel comfortable on the development cycle.
22:58 mgage that's  one reason I'm trying to figure out a workflow in which the last stages all take place on github so that people can keep track of what is being uploaded easily.
22:59 goehle_ that would be especially good for pg stuff I think, where the console git commands aren't as native
22:59 mgage people doing bleeding edge development can do all the tricks they want with git and their githubs but the last steps are all public submissions to github.com/openwebwork
22:59 goehle_ yeah, it would be nice if you could restrict pull requests to ones that merge cleanly
23:00 mgage I think that is the principle -- I don't always follow it just yet -- because I want to help people out who are just starting to contribute, but eventually we'll make it a rule.
23:01 goehle_ yeah
23:01 goehle_ it would also be good to set some protocols for things
23:01 goehle_ like the devel branch is the wild wild west
23:01 goehle_ but things have to be stable before they moved into a named branch
23:01 goehle_ e.g. ww2.5.1.3
23:02 mgage organizing a workflow and training/encouraging some people who want to be maintainers -- not necessarily develop stuff, but willing to spend some time looking over submissions and making reasonably sure they fit before they are accepted and merged.
23:02 mgage yes.
23:02 goehle_ thats tough though, because people have to use that workflow in order for everyone to be on the same page
23:02 goehle_ it gets mucked up by someone who is just starting out with git and always does things on master
23:02 goehle_ <----
23:03 goehle_ Still, the threads and comments stuff cna help with that
23:03 goehle_ if you get a pull request that doesnt merge cleanly
23:03 goehle_ you can always comment that you are rejecting it and they should make sure it merges
23:03 mgage There is a protocol that was developed for open source called PC3  take a look at http://hintjens.com/blog:24  and see what you think
23:04 goehle_ yeah, I was thinking about this the other day
23:04 goehle_ its not clear to what extent forking and branching are accomplishing the same stuff
23:04 goehle_ like, I have a webwork and webwork-dev fork
23:04 goehle_ but should those be branches?
23:05 mgage another idea (from David Gage) is to create a separate github   openwebworkdev  and fork webwork2 and pg from openwebwork to openwebwork2    -- then develop on openwebworkdev   -- only issue pull requests to openwebwork  repos when you have a super stable version.
23:05 goehle_ yeah, but then why have webwork2
23:05 goehle_ *and* webwork2-dev on openwebwork
23:06 mgage in this case you would only have webwork2 on openwebwork
23:06 goehle_ I guess it depends on what is doing what.  I always through of the account as idenifying the person
23:07 goehle_ and the repository as identifing the fork
23:07 goehle_ so openwebwork is the main public account
23:07 goehle_ and it has a webwork2 fork, which is what people should use for install
23:07 mgage the advantage is that openwebwork2dev/webwork2  would be a clean fork from openwebwork/webwork2   and you could issue a pull request to openwebwork2/webwork2    -- you can't  fork yourself
23:07 mgage so to speak
23:08 goehle_ you cant issue pull requests to openwebwork/webwokr2?
23:08 mgage yes -- and openwebwork would only have repos that standard users would use for install
23:08 mgage -- e.g.  webwork2, pg, libraries  and that would be it -- download all of those and get started.
23:09 goehle_ aaah, nevermind
23:09 goehle_ I see now
23:09 goehle_ you can't issue pull requests to webwork2 from webwork2-dev
23:09 mgage yes
23:09 goehle_ that is a problem
23:09 mgage so you  can transfer through your own machine -- but that's less transparent
23:10 goehle_ right
23:10 goehle_ and especially when we are doing the last stage
23:10 mgage exactly
23:10 goehle_ of moving things from webwork2-dev to webwork2
23:10 goehle_ we want those to be public
23:11 goehle_ ah yeah, I agree
23:11 mgage so I think some combination of implementing some of the suggestions in PC3 and having openwebwork and openwebworkdev githubs might create something that we could explain more simply to people just learning git.
23:11 goehle_ so your idea is
23:12 goehle_ openwebwork/webwork2
23:12 mgage anyone wanting to develop would for   openwebworkdev/webwork2  etc.   and send pull requests back to there
23:12 goehle_ is the main thing people install too
23:12 goehle_ and only a few people can write to it
23:12 goehle_ and it would only have one branch, master
23:12 mgage the main thing people install from  yes -- and it only accepts pull requests from openwebworkdev
23:12 goehle_ if people want to develop then they issue pull requests to openwebworkdev
23:12 mgage yes only one branch
23:12 goehle_ but which branch?
23:13 goehle_ so would openwebworkdev have a devel branch
23:13 goehle_ that has all the latest
23:13 goehle_ and then a collection of version branches
23:13 goehle_ for when we are preparing to pull to openwebwork/webwork2/
23:14 mgage ok -- so I think openwebworkdev would have a master branch (which is pretty stable -- about ready to be issued as a pull request to openwebwork -- this would be done twice a year maybe)
23:14 goehle_ why not version branches?
23:14 mgage a devel branch -- which would accept nearly anything that compiled and merged and was ready to be looked at by webwork developers
23:15 goehle_ (I mean, even now you are working on two versions, 2.5.1.3 which is an incremental update, and preparing to get things ready for 2.5.2
23:15 goehle_ putting all of that in master could get messy
23:16 mgage I'm not sure yet about the version branches -- that is what I was trying but it was getting pretty confusing -- and one looses track of which version branches have which updates.  -- you'll note that I"ve tried to cut way back on the number of branches in the current openwebwork/webwork2
23:16 goehle_ right
23:16 goehle_ that is confusing, but its kind of a necessary confusion if  you are going to work on multiple versions
23:18 mgage so ww2.5.1.1 is my surrogate for a stable development branch,  ww2.5.1.3 is the feature branch -- which is pretty stable but still allowing small increments for features.    devel is the wild west and ww2.5.2 is mostly just there for the time being -- will probably be merged into devel if it isn't already
23:18 goehle_ so you are looking at more of a rolling set of branches then
23:19 goehle_ where master is the branch that is eventually going to be pulled into openwebwork and only really accepts bugfixes
23:19 goehle_ why not master, beta and devel branches
23:19 goehle_ then beta will be for things which are more or less feature complete, but need to be tweaked or maybe have little things added
23:20 mgage well I was thinking that one could use tags instead -- so as your ww2.5.1.3 nears completion you merge it into master (ww2.5.1.1. at the moment) -- and tag it.    (also merge into devel to make sure that any bug fixes are kept)   Then you start a new feature development branch whenyou are ready to pull some things out of devel and stabilize them.
23:20 goehle_ I guess the problem with that is how do I move a single (ready for public consumption) feature over from devel to ww2.5.1.3 or something
23:20 goehle_ tag?
23:20 mgage yes -- that's pretty much my idea -- except that beta will have a specific name -- which will eventually become a tag on master
23:20 goehle_ ah ok
23:21 goehle_ will that specific name then change periodically
23:22 mgage so when master gets moved over to the super stable  master on the openwebwork (non dev) github it might actually have several tags.  So even though you are on master if something goes horribly wrong you could back up the chain to a previous tag.
23:22 mgage yes.
23:23 goehle_ so I guess things brings me back to my other question.  I've been developing something super great, say discussionForums, and its part of devel
23:23 goehle_ we want to begin the process of moving discussionForums over to master (and then on to super stable master)
23:23 goehle_ so we create a branch (which will later become a tag)
23:23 mgage that was one of the problems -- the feature was in beta -- but was it in beta at this time? or that time? -- and I have beta on three different git repos on three different machines -- including one I haven't worked on for 3 months -- are they all in sync?  --  that' s the kind of problem I was having
23:24 mgage exactly
23:24 goehle_ but now how do we move just discussionForums over to this new branch without brining along all of the other stuff floating aroudn in devel?
23:24 mgage so 2.5.1.3  is 2.5.1.1 plus essay questions and a few other small additions.
23:24 goehle_ right
23:25 mgage (also we'll try to move this back to 3 version numbers.
23:25 goehle_ so how did you just add essay questions, but not all of the ui upgrades, for example
23:25 mgage in the future -- just not quite there yet
23:25 goehle_ does someone have to checkout master
23:25 goehle_ create a new branch
23:25 goehle_ and then ... its unclear.
23:26 mgage there are lots of ways it can be  done but I'm not sure the best work flow yet.
23:26 goehle_ can you pull only a certain set of commits?
23:27 goehle_ probably not since they will be (eventually) mixed together with other commits
23:28 mgage I think what you do is check out devel (but perhaps from many commits back from the head of devel) where most of the features are available.  maybe you cherry pick a few of the more recent commits
23:28 mgage and you make a new branch which push to your github   as   ww2.5.5  let's say.
23:29 mgage you can cherry pick commits (using git) but I don't think you can do that on github -- which is probably a good thing -- since that keeps the public changes on github simple
23:29 goehle_ Hmm, thats getting confusing to me I guess
23:30 mgage it may be that to start a new feature branch someone with write access to openwebworkdev has to push that branch from their machine.  but after that others can send pull requests to it.
23:30 goehle_ right
23:30 mgage me too -- I'm still working some of this stuff out.
23:30 goehle_ I guess what's confusing for me is the devel branch
23:31 mgage so I'm sure I could create a new branch from devel on my machine -- push it to github/openwebworkdev
23:31 goehle_ I suppose the point of versioning is to keep development of different features separate
23:31 goehle_ so that two features only really come into contact when they are merged into the stable product
23:32 goehle_ but if you aren't using branches, then it gets hard to pull just one feature from devel to a feature branch
23:32 mgage others could then update, obtaining that branch,   fix, tweak and add, and send pull requests back to openwebworkdev   -- so 2.5.5 would stay usable but would still be receiving compatible updates at a steady pace
23:34 mgage yes -- it's possible that we will eventually want two feature branches on github -- but I'm going to try to avoid it for now -- or at least avoid having two branches one of which is really just an advanced version of the other -- that was getting difficult to manage.
23:34 goehle_ yeah
23:34 goehle_ what about this
23:34 goehle_ we dont have a devel branch
23:34 goehle_ just a master branch
23:34 mgage for those doing bleeding edge development on their own machines there will probably be lots of feature branches -- but there won't be that may on openwebwork
23:35 mgage I mean openwebworkdev
23:35 goehle_ and then, ocassionally, a feature branch which exists only to get a feature ready to be pulled into openwewebworkdev/master
23:35 goehle_ so, like you said, bleeding edge devel stuff happens on individual forks
23:35 goehle_ so I have my fork, and maybe I only use master because I dont understand branches
23:35 goehle_ and my feature is ready to be integrated
23:35 goehle_ so you create a feature branch on openwebwork2dev
23:36 goehle_ and I issue a pull request from my fork/master to openwebwork2dev/feature
23:36 goehle_ and the feature branch is usable, and recieving updates, and eventually gets merged into master with a tag
23:36 goehle_ and (hopefully) there wont be more than one feature branch active at a time
23:37 mgage that is how I work on my own git repository but I don't think it is quite right for this use case.
23:37 goehle_ how come?
23:38 mgage my version would be:  you have a feature that is ready -- submit it to devel on openwebworkdev and lobby for it to be included  --
23:38 mgage a maintainer branches off from devel -- with your feature and perhaps a few others and creates a release candidate - 2.5.x
23:39 goehle_ its the "with your feature and perhaps a few others" that I dont understand, I guess
23:39 mgage then people test 2.5.x for a bit and announce that it's pretty stable
23:39 goehle_ once two features have been integrated into a single code base its unclear to me how you seperate them again
23:40 mgage and then we get a fair number of people -- say twenty or so, who are prepared to use 2.5.x in their courses -- feeling fairly secure because if something goes wrong they can switch back to openwebworkdev master which has nearly everything except for these newest features
23:40 goehle_ yeah, thats a good plan
23:40 goehle_ especially considering testing webwork is non trivial
23:40 goehle_ you need to have a server
23:41 goehle_ which means you need a git branch to keep that server up to date
23:42 goehle_ Still though.  I pulled devel from webwork2-dev to see what was up.  And if I didn't have a ww2.5.1.3 branch hanging around I would have had a heck of a time seperating essay answers back out
23:42 mgage the main point of the "feature(s)" branch is to have something sufficiently stable that people who are somewhat aware of what they are doing can use it in front of a class with reasonable safety -- or at least a way to back out ---- otherwise the features pile up,  nothing gets tested until summer (when it also doesn't really get tested because no students are involved) and then there is a rush in the fall when many bugs surface
23:43 goehle_ I definitely agree with that
23:43 goehle_ sort of a pre-release
23:43 goehle_ that is stable enough to run on production machines if you are brave
23:44 goehle_ so we can get testing done before it moves into openwebworkdev/master, which is probably run on quite  a few prouduction machines
23:44 mgage exactly
23:44 mgage right -- but we need a testing cycle that is faster than -- once each summer -- by that time the author may have moved on -- mentally or physically
23:45 mgage so we need this candidate release branch -- that is slowly accumulating features and being tested.
23:45 goehle_ So, if I, as a motivated new user, want to create a feature, what do I fork?
23:46 mgage perhaps you don't add really big features to the candidate release -- just ones that will incrementally improve things.
23:46 mgage so I'm not completely sure yet.  -- and it might be in consultation with the maintainer
23:47 goehle_ I'm thinking it has to be openwebworkdev/master
23:47 mgage I'm having people who are adding polish to what is currently the 2.5.1.3 release fork from there --
23:47 goehle_ right, but that is for polish/bugfixing right?
23:47 goehle_ in which case they should have a copy of the branch
23:47 goehle_ because they should be pushing right back to the branch
23:47 mgage but the UI overhaul that Peter Staab is doing is being stashed in devel
23:48 mgage actually they'll have copies of all branches
23:48 goehle_ right
23:49 mgage in general I think a new, unsolicited feature would go into devel first and then be moved into a feature branch by one of the maintainers
23:49 mgage a solicited feature/fix etc. might go straight into the feature branch -- so I'm doing that with essayAnswers, with using knowls for hints and solutions and for adding maketext() tags to PG
23:50 mgage (which was something of a bear :-) )
23:50 goehle_ heh, I suppose I'll have to trust you on that :)  If I had started with the current devel as a base when I wrote essayAnswers, I really dont see how you could reliably separate essayAnswers from the UI stuff and all the other madness going on there right now
23:51 mgage I should probably freeze 2.5.1.3 pretty soon -- and put most stuff from Raleigh into devel and/or a new feature branch
23:51 mgage that's a point --
23:52 mgage I think we still need to think about this a bit -- look at the link above and see what you think.
23:52 goehle_ I"ve been reading it on and off
23:52 mgage I've got to take off -- pretty soon.  Thanks for the discussion though.  I think we'll want to discuss this at Raleigh and see if we can nail down a workflow
23:53 goehle_ Yeah, If we do then someone (and I could do it) should write a "day in the life of" blog
23:53 goehle_ where they go through the whole process of creating a new feature and have it integrated into webwork
23:53 mgage yes  -- that would be really useful
23:54 goehle_ but we need to decide what the workflow is first :)
23:54 mgage true enough.
23:54 mgage ttyl
23:54 goehle_ later

| Channels | #webwork index | Today | | Search | Google Search | Plain-Text | summary