[general] Deciding a date for Milestone 4

[Tim Ellison <t....@gmail.com>]

I think we should agree a date to release our fourth stable milestone
build.  There have been lots of good fixes and enhancements made
throughout the code, and while we have been doing well at maintaining
stability in 'head', I believe that many users wait for a declared
milestone before moving up.

I propose that we aim for declaring M4 on Friday Dec 14th.  That is
three weeks from today.

That date gives us some buffer to overrun if we need it before the
holiday period gets into full swing.  Once get near the end of December
and start of January there are many people taking a well-earned break,
and it will be harder to close out a release.

To get in practice for an official release, I suggest we also try to
complete the full set of rel eng tasks, like release notes, download
signing, and announcements that we haven't been so good at in the past.

What do you think?
Tim

Re: [general] Deciding a date for Milestone 4

[Alexey Petrenko <al...@gmail.com>]

This date looks reasonable for me.

SY, Alexey

2007/11/23, Tim Ellison <t....@gmail.com>:
> I think we should agree a date to release our fourth stable milestone
> build.  There have been lots of good fixes and enhancements made
> throughout the code, and while we have been doing well at maintaining
> stability in 'head', I believe that many users wait for a declared
> milestone before moving up.
>
> I propose that we aim for declaring M4 on Friday Dec 14th.  That is
> three weeks from today.
>
> That date gives us some buffer to overrun if we need it before the
> holiday period gets into full swing.  Once get near the end of December
> and start of January there are many people taking a well-earned break,
> and it will be harder to close out a release.
>
> To get in practice for an official release, I suggest we also try to
> complete the full set of rel eng tasks, like release notes, download
> signing, and announcements that we haven't been so good at in the past.
>
> What do you think?
> Tim
>

Re: [general] Deciding a date for Milestone 4

[Xiao-Feng Li <xi...@gmail.com>]

Agreed.

On Nov 23, 2007 4:49 PM, Tim Ellison <t....@gmail.com> wrote:
> I think we should agree a date to release our fourth stable milestone
> build.  There have been lots of good fixes and enhancements made
> throughout the code, and while we have been doing well at maintaining
> stability in 'head', I believe that many users wait for a declared
> milestone before moving up.
>
> I propose that we aim for declaring M4 on Friday Dec 14th.  That is
> three weeks from today.
>
> That date gives us some buffer to overrun if we need it before the
> holiday period gets into full swing.  Once get near the end of December
> and start of January there are many people taking a well-earned break,
> and it will be harder to close out a release.
>
> To get in practice for an official release, I suggest we also try to
> complete the full set of rel eng tasks, like release notes, download
> signing, and announcements that we haven't been so good at in the past.
>
> What do you think?
> Tim
>



-- 
http://xiao-feng.blogspot.com

Re: [general] Deciding a date for Milestone 4

[Mikhail Loenko <ml...@gmail.com>]

Right

2007/11/30, Tim Ellison <t....@gmail.com>:
> I see HARMONY-5098 has been committed.  AFAIK there are no more major
> changes due for this milestone iteration from anyone, right?
>
> Regards,
> Tim
>
> Ilya Berezhniuk wrote:
> > Moreover, HARMONY-5098 is the last chunk to add uncompressed
> > references support to GC_GEN.
> >
> > Other components (VM and JITs) are already corrected to support
> > uncompressed references, and those changes did not introduce any
> > regressions.
> >
> > 2007/11/28, Rana Dasgupta <rd...@gmail.com>:
> >> I think that we should feel quite confident about it. All tests etc.pass at
> >> this point, if we find bugs with larger benchmarks/apps, we will fix them.
> >> So we should be OK :-)
> >>
> >> Rana
> >>
> >> On Nov 28, 2007 8:51 AM, Tim Ellison <t....@gmail.com> wrote:
> >>
> >>> Rana Dasgupta wrote:
> >>>>  One of the new features in DRLVM in this milestone is support for
> >>> native 64
> >>>> bit references( we only supported 32 bit compressed references on 64 bit
> >>>> architecture before and therefore accessibility upto 4GB ). Almost all
> >>> the
> >>>> feature work is done and committed The pending change is in
> >>> Harmony-5098.
> >>>> Pretty sure that it will be done reviewing/changes and will get
> >>> committed by
> >>>> Nov 30, but it may spill over by a day or two. Just a heads up.
> >>> Is this something we (collectively) are happy to put in at the last
> >>> minute?  Is it something you would prefer people to use for a few weeks
> >>> before declaring good enough for a milestone build?
> >>>
> >>> There should be no shame in moving it into the next milestone (which is
> >>> why we want to hold them quite frequently, but I won't go on about that
> >>> again :-) ).
> >>>
> >>> Regards,
> >>> Tim
> >>>
> >>>
> >
> >
>

Re: [general] Deciding a date for Milestone 4

[Tim Ellison <t....@gmail.com>]

I see HARMONY-5098 has been committed.  AFAIK there are no more major
changes due for this milestone iteration from anyone, right?

Regards,
Tim

Ilya Berezhniuk wrote:
> Moreover, HARMONY-5098 is the last chunk to add uncompressed
> references support to GC_GEN.
> 
> Other components (VM and JITs) are already corrected to support
> uncompressed references, and those changes did not introduce any
> regressions.
> 
> 2007/11/28, Rana Dasgupta <rd...@gmail.com>:
>> I think that we should feel quite confident about it. All tests etc.pass at
>> this point, if we find bugs with larger benchmarks/apps, we will fix them.
>> So we should be OK :-)
>>
>> Rana
>>
>> On Nov 28, 2007 8:51 AM, Tim Ellison <t....@gmail.com> wrote:
>>
>>> Rana Dasgupta wrote:
>>>>  One of the new features in DRLVM in this milestone is support for
>>> native 64
>>>> bit references( we only supported 32 bit compressed references on 64 bit
>>>> architecture before and therefore accessibility upto 4GB ). Almost all
>>> the
>>>> feature work is done and committed The pending change is in
>>> Harmony-5098.
>>>> Pretty sure that it will be done reviewing/changes and will get
>>> committed by
>>>> Nov 30, but it may spill over by a day or two. Just a heads up.
>>> Is this something we (collectively) are happy to put in at the last
>>> minute?  Is it something you would prefer people to use for a few weeks
>>> before declaring good enough for a milestone build?
>>>
>>> There should be no shame in moving it into the next milestone (which is
>>> why we want to hold them quite frequently, but I won't go on about that
>>> again :-) ).
>>>
>>> Regards,
>>> Tim
>>>
>>>
> 
> 

Re: [general] Deciding a date for Milestone 4

[Ilya Berezhniuk <il...@gmail.com>]

Moreover, HARMONY-5098 is the last chunk to add uncompressed
references support to GC_GEN.

Other components (VM and JITs) are already corrected to support
uncompressed references, and those changes did not introduce any
regressions.

2007/11/28, Rana Dasgupta <rd...@gmail.com>:
> I think that we should feel quite confident about it. All tests etc.pass at
> this point, if we find bugs with larger benchmarks/apps, we will fix them.
> So we should be OK :-)
>
> Rana
>
> On Nov 28, 2007 8:51 AM, Tim Ellison <t....@gmail.com> wrote:
>
> > Rana Dasgupta wrote:
> > >  One of the new features in DRLVM in this milestone is support for
> > native 64
> > > bit references( we only supported 32 bit compressed references on 64 bit
> > > architecture before and therefore accessibility upto 4GB ). Almost all
> > the
> > > feature work is done and committed The pending change is in
> > Harmony-5098.
> > > Pretty sure that it will be done reviewing/changes and will get
> > committed by
> > > Nov 30, but it may spill over by a day or two. Just a heads up.
> >
> > Is this something we (collectively) are happy to put in at the last
> > minute?  Is it something you would prefer people to use for a few weeks
> > before declaring good enough for a milestone build?
> >
> > There should be no shame in moving it into the next milestone (which is
> > why we want to hold them quite frequently, but I won't go on about that
> > again :-) ).
> >
> > Regards,
> > Tim
> >
> >
>


-- 

Ilya

Re: [general] Deciding a date for Milestone 4

[Rana Dasgupta <rd...@gmail.com>]

I think that we should feel quite confident about it. All tests etc.pass at
this point, if we find bugs with larger benchmarks/apps, we will fix them.
So we should be OK :-)

Rana

On Nov 28, 2007 8:51 AM, Tim Ellison <t....@gmail.com> wrote:

> Rana Dasgupta wrote:
> >  One of the new features in DRLVM in this milestone is support for
> native 64
> > bit references( we only supported 32 bit compressed references on 64 bit
> > architecture before and therefore accessibility upto 4GB ). Almost all
> the
> > feature work is done and committed The pending change is in
> Harmony-5098.
> > Pretty sure that it will be done reviewing/changes and will get
> committed by
> > Nov 30, but it may spill over by a day or two. Just a heads up.
>
> Is this something we (collectively) are happy to put in at the last
> minute?  Is it something you would prefer people to use for a few weeks
> before declaring good enough for a milestone build?
>
> There should be no shame in moving it into the next milestone (which is
> why we want to hold them quite frequently, but I won't go on about that
> again :-) ).
>
> Regards,
> Tim
>
>

Re: [general] Deciding a date for Milestone 4

[Tim Ellison <t....@gmail.com>]

Rana Dasgupta wrote:
>  One of the new features in DRLVM in this milestone is support for native 64
> bit references( we only supported 32 bit compressed references on 64 bit
> architecture before and therefore accessibility upto 4GB ). Almost all the
> feature work is done and committed The pending change is in Harmony-5098.
> Pretty sure that it will be done reviewing/changes and will get committed by
> Nov 30, but it may spill over by a day or two. Just a heads up.

Is this something we (collectively) are happy to put in at the last
minute?  Is it something you would prefer people to use for a few weeks
before declaring good enough for a milestone build?

There should be no shame in moving it into the next milestone (which is
why we want to hold them quite frequently, but I won't go on about that
again :-) ).

Regards,
Tim

Re: [general] Deciding a date for Milestone 4

[Rana Dasgupta <rd...@gmail.com>]

Tim,
 One of the new features in DRLVM in this milestone is support for native 64
bit references( we only supported 32 bit compressed references on 64 bit
architecture before and therefore accessibility upto 4GB ). Almost all the
feature work is done and committed The pending change is in Harmony-5098.
Pretty sure that it will be done reviewing/changes and will get committed by
Nov 30, but it may spill over by a day or two. Just a heads up.

Thanks,
Rana


On 11/25/07, Tim Ellison <t....@gmail.com> wrote:
>
> So if we agree on producing M4 on Fri Dec 14th, then working back from
> that date we have:
>
> Code freeze on Fri Dec 7th.  Feature freeze on Fri Nov 30th .
>
> So this coming week is the last chance to consider any new features or
> major areas of functionality for inclusion in this milestone.
>
> After Fri 30 Nov our focus is on bug fixing, testing, and stabilizing
> the code ready for the milestone.
>
> After Fri Dec 7th the code is frozen, meaning we are all testing and
> discussing must-fix bugs that have a serious impact on declaring the
> milestone.  Defining a bug as "must-fix" requires (at least) two
> committers during the freeze period (of course, everyone's opinion is
> encouraged).  We aim that this period is no more than a week, but we
> will move the date if necessary to achieve the required quality.
>
> i.e., business as usual <g>
>
> Regards,
> Tim
>
> Spark Shen wrote:
> > Agree.
> >
> > 2007/11/23, Tim Ellison <t....@gmail.com>:
> >> I think we should agree a date to release our fourth stable milestone
> >> build.  There have been lots of good fixes and enhancements made
> >> throughout the code, and while we have been doing well at maintaining
> >> stability in 'head', I believe that many users wait for a declared
> >> milestone before moving up.
> >>
> >> I propose that we aim for declaring M4 on Friday Dec 14th.  That is
> >> three weeks from today.
> >>
> >> That date gives us some buffer to overrun if we need it before the
> >> holiday period gets into full swing.  Once get near the end of December
> >> and start of January there are many people taking a well-earned break,
> >> and it will be harder to close out a release.
> >>
> >> To get in practice for an official release, I suggest we also try to
> >> complete the full set of rel eng tasks, like release notes, download
> >> signing, and announcements that we haven't been so good at in the past.
> >>
> >> What do you think?
> >> Tim
> >>
> >
> >
> >
>

Re: [general] Deciding a date for Milestone 4

[Stepan Mishura <st...@gmail.com>]

+1

-Stepan.

On 11/25/07, Tim Ellison <t....@gmail.com> wrote:
> So if we agree on producing M4 on Fri Dec 14th, then working back from
> that date we have:
>
> Code freeze on Fri Dec 7th.  Feature freeze on Fri Nov 30th .
>
> So this coming week is the last chance to consider any new features or
> major areas of functionality for inclusion in this milestone.
>
> After Fri 30 Nov our focus is on bug fixing, testing, and stabilizing
> the code ready for the milestone.
>
> After Fri Dec 7th the code is frozen, meaning we are all testing and
> discussing must-fix bugs that have a serious impact on declaring the
> milestone.  Defining a bug as "must-fix" requires (at least) two
> committers during the freeze period (of course, everyone's opinion is
> encouraged).  We aim that this period is no more than a week, but we
> will move the date if necessary to achieve the required quality.
>
> i.e., business as usual <g>
>
> Regards,
> Tim
>
> Spark Shen wrote:
> > Agree.
> >
> > 2007/11/23, Tim Ellison <t....@gmail.com>:
> >> I think we should agree a date to release our fourth stable milestone
> >> build.  There have been lots of good fixes and enhancements made
> >> throughout the code, and while we have been doing well at maintaining
> >> stability in 'head', I believe that many users wait for a declared
> >> milestone before moving up.
> >>
> >> I propose that we aim for declaring M4 on Friday Dec 14th.  That is
> >> three weeks from today.
> >>
> >> That date gives us some buffer to overrun if we need it before the
> >> holiday period gets into full swing.  Once get near the end of December
> >> and start of January there are many people taking a well-earned break,
> >> and it will be harder to close out a release.
> >>
> >> To get in practice for an official release, I suggest we also try to
> >> complete the full set of rel eng tasks, like release notes, download
> >> signing, and announcements that we haven't been so good at in the past.
> >>
> >> What do you think?
> >> Tim
> >>

Re: [general] Deciding a date for Milestone 4

[Tim Ellison <t....@gmail.com>]

So if we agree on producing M4 on Fri Dec 14th, then working back from
that date we have:

Code freeze on Fri Dec 7th.  Feature freeze on Fri Nov 30th .

So this coming week is the last chance to consider any new features or
major areas of functionality for inclusion in this milestone.

After Fri 30 Nov our focus is on bug fixing, testing, and stabilizing
the code ready for the milestone.

After Fri Dec 7th the code is frozen, meaning we are all testing and
discussing must-fix bugs that have a serious impact on declaring the
milestone.  Defining a bug as "must-fix" requires (at least) two
committers during the freeze period (of course, everyone's opinion is
encouraged).  We aim that this period is no more than a week, but we
will move the date if necessary to achieve the required quality.

i.e., business as usual <g>

Regards,
Tim

Spark Shen wrote:
> Agree.
> 
> 2007/11/23, Tim Ellison <t....@gmail.com>:
>> I think we should agree a date to release our fourth stable milestone
>> build.  There have been lots of good fixes and enhancements made
>> throughout the code, and while we have been doing well at maintaining
>> stability in 'head', I believe that many users wait for a declared
>> milestone before moving up.
>>
>> I propose that we aim for declaring M4 on Friday Dec 14th.  That is
>> three weeks from today.
>>
>> That date gives us some buffer to overrun if we need it before the
>> holiday period gets into full swing.  Once get near the end of December
>> and start of January there are many people taking a well-earned break,
>> and it will be harder to close out a release.
>>
>> To get in practice for an official release, I suggest we also try to
>> complete the full set of rel eng tasks, like release notes, download
>> signing, and announcements that we haven't been so good at in the past.
>>
>> What do you think?
>> Tim
>>
> 
> 
> 

Re: [general] Deciding a date for Milestone 4

[Spark Shen <sm...@gmail.com>]

Agree.

2007/11/23, Tim Ellison <t....@gmail.com>:
>
> I think we should agree a date to release our fourth stable milestone
> build.  There have been lots of good fixes and enhancements made
> throughout the code, and while we have been doing well at maintaining
> stability in 'head', I believe that many users wait for a declared
> milestone before moving up.
>
> I propose that we aim for declaring M4 on Friday Dec 14th.  That is
> three weeks from today.
>
> That date gives us some buffer to overrun if we need it before the
> holiday period gets into full swing.  Once get near the end of December
> and start of January there are many people taking a well-earned break,
> and it will be harder to close out a release.
>
> To get in practice for an official release, I suggest we also try to
> complete the full set of rel eng tasks, like release notes, download
> signing, and announcements that we haven't been so good at in the past.
>
> What do you think?
> Tim
>



-- 
Spark Shen
China Software Development Lab, IBM

Re: [general] Deciding a date for Milestone 4

[Andrew Zhang <zh...@gmail.com>]

On Nov 23, 2007 4:49 PM, Tim Ellison <t....@gmail.com> wrote:

> I think we should agree a date to release our fourth stable milestone
> build.  There have been lots of good fixes and enhancements made
> throughout the code, and while we have been doing well at maintaining
> stability in 'head', I believe that many users wait for a declared
> milestone before moving up.
>
> I propose that we aim for declaring M4 on Friday Dec 14th.  That is
> three weeks from today.
>
> That date gives us some buffer to overrun if we need it before the
> holiday period gets into full swing.  Once get near the end of December
> and start of January there are many people taking a well-earned break,
> and it will be harder to close out a release.
>
> To get in practice for an official release, I suggest we also try to
> complete the full set of rel eng tasks, like release notes, download
> signing, and announcements that we haven't been so good at in the past.
>
> What do you think?


Sounds great!

>
> Tim
>



-- 
Best regards,
Andrew Zhang

http://zhanghuangzhu.blogspot.com/