[kepler-dev] Code Freeze Today

[Aaron Schultz]

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
>>
>