Build and Integration schedule -- skip weeks

Xiomara Jayasena Xiomara.Jayasena at Sun.COM
Fri May 8 14:29:32 PDT 2009



Joe Darcy wrote:
> On 05/08/09 02:12 PM, Xiomara Jayasena wrote:
>>
>>
>> Joseph D. Darcy wrote:
>>> Xiomara Jayasena wrote:
>>>>
>>>> There is no really point in doing a promotion if nothing has 
>>>> changed.  Would a link for the skipped build to the previous build 
>>>> number suffice, instead?
>>>
>>> The appropriate state of the source code in the repositories should 
>>> also be tagged for both builds in this situation.
>>>
>>> Basically, places where people get the build from, source, binaries, 
>>> etc., should have a conceptual link from the skipped build to the 
>>> prior one.
>>
>> In the long term the above could become quite confusing.
>> I do not quite understand the need to skip build numbers or 
>> re-build.  I believe in the past RE has done neither, we just update 
>> whatever documents need to be updated.
>>
>> I can see that publishing a calendar in advance and knowing what 
>> build number to target for, is very useful for gatekeepers, so if we 
>> must do one of the two options above then skipping numbers maybe the 
>> best alternative, from RE's perspective.
>
> I find skipped build numbers to have a very high long-term cognitive 
> cost.  Nine months, or a year or two years after JDK7 m3 when someone 
> is trying to track down in which build a bug was introduced, how 
> likely is it that he or she will remember, "Ah yes, b60 was skipped 
> because that was the stopper build for JDK 7 m3 and there were no 
> problems to fix!"  Missing build numbers create questions rather than 
> answers and complicate attempts to perform things like binary search 
> on the builds.
>
> I think the set of build numbers should be a dense sequence of 
> consecutive integers.  There are multiple ways of achieving this and I 
> don't have a strong preference between:
>
> * Rename b61 as b60 if m03 doesn't need a stopped build

Renaming in RE terms translates to re-building.

> * Make b60 a duplicate of b59 if no stopper fixes are needed

Again, that pretty much means rebuilding, to have bundle names, etc. 
include the new build number.

-Xiomara

>
> -Joe
>
>>
>> -Xiomara
>>
>>>
>>> -Joe
>>>
>>>>
>>>> -Xiomara
>>>>
>>>>
>>>> Paul Hohensee wrote:
>>>>> Could also just build b60 to be identical to b59.  I.e., the only 
>>>>> difference
>>>>> between b59 and b60 bundles would be the build number.
>>>>>
>>>>> Paul
>>>>>
>>>>> Joseph D. Darcy wrote:
>>>>>> Mark Reinhold wrote:
>>>>>>>> Date: Fri, 08 May 2009 08:20:13 -0700
>>>>>>>> From: xiomara.jayasena at sun.com
>>>>>>>>     
>>>>>>>
>>>>>>>  
>>>>>>>> I was under the impression that b60 was going to be the last 
>>>>>>>> build for
>>>>>>>> M3 and according to the Calendar here:
>>>>>>>> http://openjdk.java.net/projects/jdk7/calendar/
>>>>>>>> it shows that b60 is the last build for M3.  Are we saying that 
>>>>>>>> b59 is
>>>>>>>> now going to be the last build in M3 then?
>>>>>>>>     
>>>>>>>
>>>>>>> Build 60 is the last scheduled build for M3.  It's the 
>>>>>>> showstopper build.
>>>>>>> If we need it, we'll do it; if we don't, then we'll skip it.  I 
>>>>>>> suggest
>>>>>>> you leave 60 in the schedule until we make that decision.
>>>>>>>
>>>>>>> If we skip 60 then that does raise the question of whether 
>>>>>>> what's now
>>>>>>> called 61 should be renamed to 60, and so forth for all 
>>>>>>> following builds.
>>>>>>> Personally I'd prefer to keep the present numbering and just 
>>>>>>> document the
>>>>>>> fact that we skipped 60.  I tend to view build numbers as part 
>>>>>>> of the
>>>>>>> calendar.  If you don't do something on a particular day then that
>>>>>>> doesn't mean you remove the day from the calendar, it just means 
>>>>>>> that
>>>>>>> you do it on some later day.
>>>>>>>
>>>>>>> What do others think?
>>>>>>>
>>>>>>>
>>>>>>>   
>>>>>>
>>>>>> I'd prefer to renumber b61 to b60 is b60 is skipped.
>>>>>>
>>>>>> I think it is less confusing long term to have the build numbers 
>>>>>> be a dense consective sequence of integers.
>>>>>>
>>>>>> -Joe
>>>>>>
>>>
>



More information about the jdk7-rt mailing list