[kepler-dev] Code Freeze Today
Aaron Schultz
aschultz at nceas.ucsb.edu
Wed Feb 3 15:22:22 PST 2010
I won't be doing anything at 6pm tonight with formatting or organizing
imports.
Sounds like management is addressing the issue.
Aaron
Aaron Schultz wrote:
>
> 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
>>>>
>>>
>>
>
> _______________________________________________
> 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