[kepler-dev] Code Freeze Today

David Welker david.v.welker at gmail.com
Tue Feb 2 14:11:59 PST 2010 

Actually, you should interpret me declining to vote because I think  
developers voting on an issue that management has already decided is  
illegitimate as declining to vote. So, if I say I decline to vote, I  
would prefer that my vote not be added to either side of a vote that I  
think is illegitimate. If management instructs us to vote on this  
issue, THEN I will make my decision on that issue and vote.

As far as imports, I simply think that issue is outside of scope of  
the management decisions that have already been taken on this,  
therefore, I think it would be permissible to handle those.

Thanks!

On Feb 2, 2010, at 2:51 PM, 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