[kepler-dev] Code Freeze Today

Aaron Schultz aschultz at nceas.ucsb.edu
Tue Feb 2 14:08:01 PST 2010 

Also, some history on this subject...
Here is the last time we did it:
http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/2009-January/013669.html

The consensus then was that most people didn't care one way or the 
other.  Managers I spoke to (and have private emails from but won't 
forward) tended to think it was a good idea for the core modules but 
thought it was a bad idea to reformat anything outside of that.

Aaron


Aaron Schultz wrote:
>
> Thanks David, Until we hear something from management, I'll interpret 
> that as
>
> -- Tally --
> Reformat: 2 for, 3 against
> Imports: 4 for, 1 against
>
> The imports are important for dependency analysis programs such as 
> STAN4J and jdepend.
> The formatting only matters for readability and general team 
> solidity.  As an example it drives me crazy whenever I see a few two 
> space indented lines in my nicely tab indented files.  My first 
> thought is; "Darn that Chad guy and his archaic two space 
> indentations!"  Whereas if we were using similar formatting I wouldn't 
> have these negative thoughts so often but would just get used to doing 
> it one way or the other...  :)
>
> Aaron
>
>
> David Welker wrote:
>> Actually, this has already been decided by management. We don't get 
>> to vote on it. And management has decided that code shall be 
>> formatted according to the preferences of individual developers, on 
>> the theory that the individuals who actually work with and modify 
>> code are more productive when they get to format it according to 
>> their own preferences instead of conforming to a one-size fits all 
>> philosophy.
>>
>> As far as the issue of optimizing imports, I don't think that is 
>> important one way or another, since this will not affect developer 
>> productivity. If there is a technical reason to organize imports (for 
>> example, it helps tools analyze the code) it probably should be done.
>>
>> As for code formatting, I decline to vote, on the grounds that 
>> management has already made a decision and it is up to management, 
>> not developers, to change that decision.
>>
>> -David
>>
>>
>>
>> On Feb 2, 2010, at 12:53 PM, Sean Riddle wrote:
>>
>>> I don't care for some of the auto-reformatted code I've seen, so I'm 
>>> all for having some guidelines, but I think we need to figure out 
>>> what they are first; I have to vote against an automatic 
>>> reformatting. Imports, though, organize the heck out of those.
>>>
>>> - Sean
>>>
>>> --Tally--
>>> Reformat: 2 for, 2 against
>>> Imports: 3 for, 1 against
>>>
>>>
>>> On Feb 2, 2010, at 11:45 AM, Aaron Schultz wrote:
>>>
>>>>
>>>> Hi Chad,
>>>>
>>>> I thought we had agreed over a year ago that the solution to this 
>>>> problem was to allow everyone to use any format they wanted with 
>>>> periodic formatting of the code base.  I enjoy working in this kind 
>>>> of freelance environment as much as everyone else but I do think we 
>>>> should have some standards around here.  I remember learning from 
>>>> my CSC professors back in school that I should be prepared to adapt 
>>>> to writing code in whatever format that the company had decided 
>>>> on.  I specifically remember one professor saying "Don't get too 
>>>> attached to any code formatting style because every company does it 
>>>> differently.  But be assured that you will have to write code in a 
>>>> format different than the style you are used to because it makes it 
>>>> easier for a team to work together and every company has code 
>>>> formatting standards."  Something to that effect.  The fact that 
>>>> our management hasn't taken a stand on this leaves it up to us to 
>>>> decide.
>>>>
>>>> So far there are 2 votes for and 1 vote against.  Anyone else want 
>>>> to chime in?  Any managers that have an opinion?
>>>>
>>>> Lets break the vote into 2 parts too
>>>>
>>>> formatting the code  -2 for -1against
>>>> organizing imports -2 for -1 against
>>>>
>>>> I'll wait until 6pm tomorrow (Wed) to tally the votes and perform 
>>>> the actions.
>>>>
>>>> Aaron
>>>>
>>>>
>>>> Chad Berkley wrote:
>>>>> Hi,
>>>>>
>>>>> See my comments below.
>>>>>
>>>>> Christopher Brooks wrote:
>>>>>> Hi Aaron,
>>>>>> I agree, I'd like to see the Kepler code formatted before the 
>>>>>> release.
>>>>>> However, I'm not so sure everyone agrees with this.  My latest 
>>>>>> understanding
>>>>>> was that reformatting was ok on a per-file basis.  I don't have a 
>>>>>> suggestion
>>>>>> for how to reach consensus on this.
>>>>>
>>>>> Yeah, unless there's a real reason to reformat all of the code, 
>>>>> I'd prefer if you just format the files you "own" or have a vested 
>>>>> interest in.  If a file is a huge mess or something, that's fine, 
>>>>> but I don't think we should be reformatting entire modules.  We've 
>>>>> never come to a decision on standard style and I doubt we will, so 
>>>>> I prefer to stick with the status quo for now.
>>>>>
>>>>>>
>>>>>> At a minimum, it would be good to at least fix the imports.  One 
>>>>>> issue is that
>>>>>> if any of the files are copyright 2009, then modifying them would 
>>>>>> mean changing
>>>>>> the copyright. However, I think most files will have a 2010 
>>>>>> copyright.
>>>>>
>>>>> I updated all of the copyrights on all of the source in the kepler 
>>>>> suite last week.  They should now be all XXXX-2010 or just 2010 if 
>>>>> the file was created this year or did not have a previous 
>>>>> copyright.  FYI, there's now a task to do this in the build 'ant 
>>>>> update-copyright' which is documented in the build documentation.
>>>>>
>>>>> chad
>>>>>
>>>>>
>>>>>>
>>>>>> I have notes about how I clean the ptII tree at
>>>>>> kepler/ptolemy/src/doc/coding/releasemgt.htm
>>>>>>
>>>>>> _Christopher
>>>>>>
>>>>>>
>>>>>> On 2/1/10 7:42 PM, Aaron Schultz wrote:
>>>>>>>
>>>>>>> Hi Chad,
>>>>>>>
>>>>>>> I'd like to do a default eclipse reformat and organize imports 
>>>>>>> before
>>>>>>> freezing the core module code. I can do it tomorrow night around 
>>>>>>> 6pm if
>>>>>>> that's ok, giving folks a chance to check in their code before that
>>>>>>> happens.
>>>>>>> Or if you could do it before the branch that'd be good too.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Aaron
>>>>>>>
>>>>>>>
>>>>>>> Chad Berkley wrote:
>>>>>>>> Just the Kepler suite modules I think.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Feb 1, 2010, at 9:38, Timothy McPhillips 
>>>>>>>> <tmcphillips at mac.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Chad,
>>>>>>>>>
>>>>>>>>> What would the SVN branch be over? Everything in kepler/trunk/,
>>>>>>>>> including all modules?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Tim
>>>>>>>>>
>>>>>>>>> On Feb 1, 2010, at 8:51 AM, Chad Berkley wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I'm just checking in one last time to see if there is any 
>>>>>>>>>> objection
>>>>>>>>>> to doing the code freeze today. The bug list is looking 
>>>>>>>>>> pretty good
>>>>>>>>>> and I think we got all of the features in that we meant to. 
>>>>>>>>>> If there
>>>>>>>>>> is anything outstanding that you think warrants pushing the code
>>>>>>>>>> freeze, please let me know ASAP.
>>>>>>>>>>
>>>>>>>>>> Because of our module system, there are two different ways we 
>>>>>>>>>> can do
>>>>>>>>>> the release branch. We can do an old fashioned SVN branch, or 
>>>>>>>>>> we can
>>>>>>>>>> just create a kepler-2.0.0 release suite with versioned 
>>>>>>>>>> sub-modules.
>>>>>>>>>> What does everyone think is the best route to go? I would 
>>>>>>>>>> probably
>>>>>>>>>> lean toward an SVN branch, myself, but I think there are other
>>>>>>>>>> opinions out there.
>>>>>>>>>>
>>>>>>>>>> chad
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Kepler-dev mailing list
>>>>>>>>>> Kepler-dev at kepler-project.org
>>>>>>>>>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Kepler-dev mailing list
>>>>>>>> Kepler-dev at kepler-project.org
>>>>>>>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Kepler-dev mailing list
>>>>>>> Kepler-dev at kepler-project.org
>>>>>>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Kepler-dev mailing list
>>>> Kepler-dev at kepler-project.org
>>>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>>
>>> _______________________________________________
>>> Kepler-dev mailing list
>>> Kepler-dev at kepler-project.org
>>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at kepler-project.org
>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>
>
>

More information about the Kepler-dev mailing list