[kepler-dev] Code Freeze Today

Aaron Schultz aschultz at nceas.ucsb.edu
Tue Feb 2 13:51:13 PST 2010 

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