Yep. My *ideal* would be for a release to be cut (1.a) and then there be a 1.a.x that only includes reformatting, and then any work in 1.b would land into that. We'd pick up each set of changes in turn thus making it very clear which changes are reformatting and which are functional.
So if you were to do this for 1.4, you'd cut 1.4, do a reformatting of 1.4, cut 1.4.1 (assuming 0 to no bugs introduced by reformatting) and then land 1.5 on top of that. Realizing that landing 1.5 is going to suck and probably require some additional reformatting because of the merge conflicts engendered by the reformatting of 1.4. So that makes our merges easier but it makes your 1.b merge harder. Either way someone has a painful merge. Did that make sense? - Eli On Jul 13, 2012, at 6:57 AM, Nicolaas Matthijs wrote: > Hi Eli, > > Is it fair to say that doing it straight after the 1.4.0 release would still > pose problems as the 1.5.0 branch already has a bunch of bug fixes, > internationalization changes, etc. ? > > Thanks, > Nicolaas > > > On 12 Jul 2012, at 16:46, Eli Cochran wrote: > >> Sorry, mistyping. Berkeley *does NOT* have an issue if it is done early in >> the dev cycle… >> >> - Eli >> >> On Jul 12, 2012, at 8:37 AM, Eli Cochran wrote: >> >>> I'm confused as to what the timing would be? I guess Berkeley does have an >>> issue if it is done early in the dev cycle and not right at the end. >>> >>> It might make sense if it was done as it's own release then we can isolate >>> functional changes from style changes but that might be more trouble than >>> it's worth. >>> >>> Thanks for asking. >>> >>> - Eli >>> >>> >>> >>> On Jul 11, 2012, at 12:25 AM, Nicolaas Matthijs wrote: >>> >>>> Hi everyone, >>>> >>>> At last week's UI dev call, we discussed doing a full sweep over the >>>> entire codebase, cleaning up all places that do not adhere to our >>>> style guide (spacing issues, double quotes instead of single quotes, >>>> CSS not expanded, etc.). >>>> >>>> In the last weeks, various pull requests have been re-opened and >>>> slowed down because of the styling issues they had, and therefore we'd >>>> like to do one focussed pass and then continue with a commit hook and >>>> unit tests that checks for violations of the style guide. >>>> >>>> However, before we go ahead, I wanted to check whether the >>>> institutions running Sakai OAE in production are fine with this, as >>>> there will be an increased likelihood of merge conflicts in areas >>>> where custom code is present. The potential merge conflicts should be >>>> fairly easy to resolve, but we still wanted to check first. >>>> >>>> Any objections? >>>> >>>> Thanks, >>>> Nicolaas >>>> _______________________________________________ >>>> oae-dev mailing list >>>> [email protected] >>>> http://collab.sakaiproject.org/mailman/listinfo/oae-dev >>> >>> ...... .... ... .. . . . . . . . . . . >>> >>> Eli Cochran >>> project manager, CalCentral project >>> Educational Technology Services, UC Berkeley >>> >>> >>> >>> >>> >>> >> >> . . . . . . . . . . . . . . . . . . >> . >> >> Eli Cochran >> project manager, CalCentral project >> Educational Technology Services, UC Berkeley >> >> "Do not solve the problem that’s asked of you. It’s almost always the wrong >> problem." >> - Don Norman >> >> >> >> > . . . . . . . . . . . . . . . . . . . Eli Cochran project manager, CalCentral project Educational Technology Services, UC Berkeley "Progressive Enhancement: An escalator can never break, it can only become stairs." - Mitch Hedberg _______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
