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

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.

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.

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.

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.

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

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

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.

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.

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

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

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.

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

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

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