[kepler-dev] Code Freeze Today

Aaron Schultz aschultz at nceas.ucsb.edu
Tue Feb 2 14:18:03 PST 2010 

OK then we stand at

-- Tally --
Reformat: 2 for, 2 against
Imports: 3 for, 1 against

P.S.  Isn't this fun!?  :)  Let's see some more votes!


David Welker wrote:
> 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