[kepler-dev] Code Freeze Today

David Welker david.v.welker at gmail.com
Tue Feb 2 12:29:22 PST 2010 

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

More information about the Kepler-dev mailing list