[general] M3 milestone discussion

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

Hi,

Before M2 we agreed on 2-month milestone schedule so we are close to M3.

I'd like to start discussion
- schedule: are everybody comfort with 2-month milestone schedule(IOW,
are we ready for next milestone in the end of August)
- plans/targets: platforms, what worse to be included to the
milestone, fixed in the milestone

Thoughts?

Thanks,
Stepan Mishura
Intel Enterprise Solutions Software Division

Re: [general] M3 milestone discussion

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

2007/8/16, Yang Paulex <pa...@gmail.com>:
> [offtopic]
> I noticed there're couple of tasks still open for M2, say,
> HARMONY-4107~HARMONY-4111, are they OK to be closed?

Many of these goals were achieved on Widows only.
For example, CC reported [1] 98.93% for functional test suite
(HARMONY-4107 umbrellat task) on Windows and just 96.41%
on linux.

Should we use the same issues for M3 to get the same stability level
on Linux?

Thanks,
Mikhail

[1] http://people.apache.org/~mloenko/snapshot_testing/script/r564155/index.html


> [/offtopic]
>
> 2007/8/12, Stepan Mishura <st...@gmail.com>:
> >
> > Hi,
> >
> > Before M2 we agreed on 2-month milestone schedule so we are close to M3.
> >
> > I'd like to start discussion
> > - schedule: are everybody comfort with 2-month milestone schedule(IOW,
> > are we ready for next milestone in the end of August)
> > - plans/targets: platforms, what worse to be included to the
> > milestone, fixed in the milestone
> >
> > Thoughts?
> >
> > Thanks,
> > Stepan Mishura
> > Intel Enterprise Solutions Software Division
> >
>
>
>
> --
> Paulex Yang
> China Software Development laboratory
> IBM
>

Re: [general] M3 milestone discussion

[Yang Paulex <pa...@gmail.com>]

[offtopic]
I noticed there're couple of tasks still open for M2, say,
HARMONY-4107~HARMONY-4111, are they OK to be closed?
[/offtopic]

2007/8/12, Stepan Mishura <st...@gmail.com>:
>
> Hi,
>
> Before M2 we agreed on 2-month milestone schedule so we are close to M3.
>
> I'd like to start discussion
> - schedule: are everybody comfort with 2-month milestone schedule(IOW,
> are we ready for next milestone in the end of August)
> - plans/targets: platforms, what worse to be included to the
> milestone, fixed in the milestone
>
> Thoughts?
>
> Thanks,
> Stepan Mishura
> Intel Enterprise Solutions Software Division
>



-- 
Paulex Yang
China Software Development laboratory
IBM

Re: [general] M3 milestone discussion

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

+1 for 3-mo

since we have long tests to check code quality we have to have long
enough freeze time. And it now takes significant time comparing to development
time that is not very convenient. Since we strive to maintain code
base in a good
shape between the milestones too (with our CC testing), it won't
negatively affect
code base integrity.

Thanks,
Mikhail

2007/8/13, Mikhail Fursov <mi...@gmail.com>:
> +1 here to have 3-months period per release instead of 2 months.
> For me, as for developer, it will be easier to integrate and test new
> features.
> For a Harmony every new release will have more changes and improvements and
> will be more noticeable for end-users
> Those who interested in fresh and tested builds every day - AFAIK we already
> do them regardless of milestone.
>
> On 8/13/07, Weldon Washburn <we...@gmail.com> wrote:
> >
> > hmm... Its August and lots of folks are on vacation.  How about move
> > M3 to the end of September?  This will give us a few weeks to discuss
> > what should (and should not) go into M3.
> >
> > On 8/12/07, Stepan Mishura <st...@gmail.com> wrote:
> > > Hi,
> > >
> > > Before M2 we agreed on 2-month milestone schedule so we are close to M3.
> > >
> > > I'd like to start discussion
> > > - schedule: are everybody comfort with 2-month milestone schedule(IOW,
> > > are we ready for next milestone in the end of August)
> > > - plans/targets: platforms, what worse to be included to the
> > > milestone, fixed in the milestone
> > >
> > > Thoughts?
> > >
> > > Thanks,
> > > Stepan Mishura
> > > Intel Enterprise Solutions Software Division
> > >
> >
> >
> > --
> > Weldon Washburn
> >
>
>
>
> --
> Mikhail Fursov
>

Re: [general] M3 milestone discussion

[Mikhail Fursov <mi...@gmail.com>]

+1 here to have 3-months period per release instead of 2 months.
For me, as for developer, it will be easier to integrate and test new
features.
For a Harmony every new release will have more changes and improvements and
will be more noticeable for end-users
Those who interested in fresh and tested builds every day - AFAIK we already
do them regardless of milestone.

On 8/13/07, Weldon Washburn <we...@gmail.com> wrote:
>
> hmm... Its August and lots of folks are on vacation.  How about move
> M3 to the end of September?  This will give us a few weeks to discuss
> what should (and should not) go into M3.
>
> On 8/12/07, Stepan Mishura <st...@gmail.com> wrote:
> > Hi,
> >
> > Before M2 we agreed on 2-month milestone schedule so we are close to M3.
> >
> > I'd like to start discussion
> > - schedule: are everybody comfort with 2-month milestone schedule(IOW,
> > are we ready for next milestone in the end of August)
> > - plans/targets: platforms, what worse to be included to the
> > milestone, fixed in the milestone
> >
> > Thoughts?
> >
> > Thanks,
> > Stepan Mishura
> > Intel Enterprise Solutions Software Division
> >
>
>
> --
> Weldon Washburn
>



-- 
Mikhail Fursov

Re: [general] M3 milestone discussion

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

Stepan Mishura wrote:
> On 8/22/07, Mikhail Loenko wrote:
>> Basing on M2 experience I think 2-mo is a too short for Harmony:
>> 25% of the whole time we would have our workspace somehow frozen.
>> And we couldn't shorten freeze time since we have long running
>> suites and scenarios.
>>
>> IMHO it negatively affects progress of the project.
>> So I'm +1 for having fixed schedule, but 2-mo schedule does not leave
>> enough time for normal development
> 
> I agree with Mikhail - 2 month schedule looks too short.

Why?  How long should we go before checking stability is maintained?  I
see lots of work going on daily, things look good from here.

Regards,
Tim

Re: [general] M3 milestone discussion

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

On 8/22/07, Mikhail Loenko wrote:
> Basing on M2 experience I think 2-mo is a too short for Harmony:
> 25% of the whole time we would have our workspace somehow frozen.
> And we couldn't shorten freeze time since we have long running
> suites and scenarios.
>
> IMHO it negatively affects progress of the project.
> So I'm +1 for having fixed schedule, but 2-mo schedule does not leave
> enough time for normal development

I agree with Mikhail - 2 month schedule looks too short.

-Stepan.

>
> Thanks,
> Mikhail
>
> 2007/8/22, Tim Ellison <t....@gmail.com>:
> > Weldon Washburn wrote:
> > > hmm... Its August and lots of folks are on vacation.
> >
> > True, I just got back from vacation myself, but I don't see that as a
> > reason to delay a stability drive and declaring a stable build as M3.
> > Indeed, it could be easier if there is less churn in the code!
> >
> > > How about move
> > > M3 to the end of September?  This will give us a few weeks to discuss
> > > what should (and should not) go into M3.
> >
> > The content of M3 is whatever is in SVN at the point we declare it
> > stable.  If there is code that is misbehaving then we would take it out
> > to achieve stability across the codebase.  IMHO extending the period to
> > decide what is in it doesn't make sense.
> >
> > So I say let's start to chill down the code in the next few days, and
> > freeze next week to test and declare an M3 at the end of the month.  I
> > believe that producing regular, predictable milestones is one
> > characteristic of a healthy project.
> >
> > Regards,
> > Tim

Re: [general] M3 milestone discussion

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

Mikhail Loenko wrote:
> 2007/8/23, Tim Ellison <t....@gmail.com>:
>> Mikhail Loenko wrote:
>>> 2007/8/22, Tim Ellison <t....@gmail.com>:
>>>> Mikhail Loenko wrote:
>>>>> Basing on M2 experience I think 2-mo is a too short for Harmony:
>>>>> 25% of the whole time we would have our workspace somehow frozen.
>>>>> And we couldn't shorten freeze time since we have long running
>>>>> suites and scenarios.
>>>> That's not my memory, looking back in the list you froze the code on 24
>>>> June, and unfroze it on 30 June.
>>> There was also "feature freeze" message on June, 14th. So it's not 10%.
>> Rather than get into a debate about the %'s, let's decide whether we
>> have the right balance between open development and ensuring
>> stability/demonstrating progress.
>>
>> I'm sure we agree that we would like to minimize the disruption on
>> on-going development, but agree that we need these stability
>> checkpoints.  This (thread) is the first time I see a call for longer
>> open development periods.
>>
>>> We need that length of time to run
>>>> tests and check stability as you mention, but it was more like 10% which
>>>> I think is reasonable given our current state.
>>>>
>>>>> IMHO it negatively affects progress of the project.
>>>>> So I'm +1 for having fixed schedule, but 2-mo schedule does not leave
>>>>> enough time for normal development
>>>> Can you explain what you mean here?  I see lots of 'normal development'
>>>> taking place, with hundreds of commits in each milestone.
>>> We declare that our milestone builds are "best so far". That actually mean
>>> that we should not have (at least known) regressions.
>> Agreed.
>>
>>> We have a huge amount of tests and it's impossible to run them all
>>> before each commit. For that reason many commits introduce regressions.
>> Well hopefully not 'many commits' but it is a possibility yes<g>
>>
>>> Now the question is what %% of time we may focus on development of new
>>> features vs time on fixing regressions. Basing on CC results, it might take
>>> up to 2-3 weeks to fix regressions introduced by a commit (some scenarios are
>>> down for even longer time).
>> Is that because people are not looking at the CC results and fixing
>> them, or that we are short of machines to crunch through the scenarios?
> 
> the more machines the better. Currently BTI scenarios run on ~30 machines,
> but still it may take up to a week to notice a regression, the reasons are:
> 
> we have many long-running scenarios
> some failures are intermittent and thus not necessary regressions
> some failures caused by side effects (e.g. we have tests that read/write files)
> there are failures that are not reproducible when a single test is run
> (they reproducible only when the whole suite runs)
> and more
> 
> Tim has mentioned how many commits we make, so it takes time to identify
> guilty commit and find a reason of regression...
> 
> Well it does not always takes that long to fix the regression, but still
> it's not a 5-minute task.

Doesn't that imply that we check stability more often, rather than let
the side-effects build up over a longer period of time?

>>> So that actually mean that in the 2-mo schedule
>>> we may do full-swing development during ~1 month, do very careful development
>>> 2 more weeks, and be mostly blocked 2 remaining weeks.
>> If we have introduced regressions, then fixing them in those two weeks
>> would seem like a good idea rather than continued open development.  How
>> long do you think is a reasonable time to let regressions ride?
> 
> for short cycle tests (like classlib, drlvm-test) it should be hours.
> For long-running
> scenarios one week is "OK". But sometimes it may take more...
> 
> The problem is we have more than one developer :)

Indeed, so while I have sympathy for Mikhail F' saying that his work
pace may need to adjust to the timing of a milestone, it needs to be set
in the context of everyone else's work affecting him and him affecting
everyone else.

> If there is a single person working on the code and he sees a regression,
> he might stop and fix it.
> 
> If we have two people, A and B, working on
> area1 and area2 and e.g. A has introduced a regression into area1, so that
> for example scenarioX now fails then the question is should B stop his
> work until
> area1 is fixed?
> 
> If it's "hacking time" then B should probably continue development,
> if it's "stabilizing time" then B should probably stop and wait until
> it's fixed.

Agreed, and we don't want to leave it unfixed for too long.

>>> This is what I see in VM, API is definitely different: most changes are rather
>>> isolated.
>> We can certainly tweak the current practice if people feel it is
>> inhibiting the progress they could be making, I just want to ensure we
>> are not trading stability for more hacking :-)
> 
> I think we should maintain stability even when we are hacking. If a new feature
> introduced regressions we should fix them even if it's not "milestone time"

Agreed.

> So IMHO we should base our decision on
> - what ratio between "open development" and "constrained development"
> we'd like to have
> - what is mean time to repair regressions = R
> - how long is our full testing cycle = T
> 
> then milestone shedule would ideally be something like:
> T for code freeze
> R + T for feature freeze
> 
> and period would be
> (R + 2T)/(constrained%)
> adjusted by:
> - how often we think community wants to see stable builds
> 
> ;)

I agree with all that, and if somebody thinks that two months' work is
not enough then let them propose an alternative.  It works for me but we
should seek concensus.

Regards,
Tim

Re: [general] M3 milestone discussion

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

2007/8/23, Tim Ellison <t....@gmail.com>:
> Mikhail Loenko wrote:
> > 2007/8/22, Tim Ellison <t....@gmail.com>:
> >> Mikhail Loenko wrote:
> >>> Basing on M2 experience I think 2-mo is a too short for Harmony:
> >>> 25% of the whole time we would have our workspace somehow frozen.
> >>> And we couldn't shorten freeze time since we have long running
> >>> suites and scenarios.
> >> That's not my memory, looking back in the list you froze the code on 24
> >> June, and unfroze it on 30 June.
> >
> > There was also "feature freeze" message on June, 14th. So it's not 10%.
>
> Rather than get into a debate about the %'s, let's decide whether we
> have the right balance between open development and ensuring
> stability/demonstrating progress.
>
> I'm sure we agree that we would like to minimize the disruption on
> on-going development, but agree that we need these stability
> checkpoints.  This (thread) is the first time I see a call for longer
> open development periods.
>
> > We need that length of time to run
> >> tests and check stability as you mention, but it was more like 10% which
> >> I think is reasonable given our current state.
> >>
> >>> IMHO it negatively affects progress of the project.
> >>> So I'm +1 for having fixed schedule, but 2-mo schedule does not leave
> >>> enough time for normal development
> >> Can you explain what you mean here?  I see lots of 'normal development'
> >> taking place, with hundreds of commits in each milestone.
> >
> > We declare that our milestone builds are "best so far". That actually mean
> > that we should not have (at least known) regressions.
>
> Agreed.
>
> > We have a huge amount of tests and it's impossible to run them all
> > before each commit. For that reason many commits introduce regressions.
>
> Well hopefully not 'many commits' but it is a possibility yes<g>
>
> > Now the question is what %% of time we may focus on development of new
> > features vs time on fixing regressions. Basing on CC results, it might take
> > up to 2-3 weeks to fix regressions introduced by a commit (some scenarios are
> > down for even longer time).
>
> Is that because people are not looking at the CC results and fixing
> them, or that we are short of machines to crunch through the scenarios?

the more machines the better. Currently BTI scenarios run on ~30 machines,
but still it may take up to a week to notice a regression, the reasons are:

we have many long-running scenarios
some failures are intermittent and thus not necessary regressions
some failures caused by side effects (e.g. we have tests that read/write files)
there are failures that are not reproducible when a single test is run
(they reproducible only when the whole suite runs)
and more

Tim has mentioned how many commits we make, so it takes time to identify
guilty commit and find a reason of regression...

Well it does not always takes that long to fix the regression, but still
it's not a 5-minute task.

>
> > So that actually mean that in the 2-mo schedule
> > we may do full-swing development during ~1 month, do very careful development
> > 2 more weeks, and be mostly blocked 2 remaining weeks.
>
> If we have introduced regressions, then fixing them in those two weeks
> would seem like a good idea rather than continued open development.  How
> long do you think is a reasonable time to let regressions ride?

for short cycle tests (like classlib, drlvm-test) it should be hours.
For long-running
scenarios one week is "OK". But sometimes it may take more...

The problem is we have more than one developer :)

If there is a single person working on the code and he sees a regression,
he might stop and fix it.

If we have two people, A and B, working on
area1 and area2 and e.g. A has introduced a regression into area1, so that
for example scenarioX now fails then the question is should B stop his
work until
area1 is fixed?

If it's "hacking time" then B should probably continue development,
if it's "stabilizing time" then B should probably stop and wait until
it's fixed.

>
> > This is what I see in VM, API is definitely different: most changes are rather
> > isolated.
>
> We can certainly tweak the current practice if people feel it is
> inhibiting the progress they could be making, I just want to ensure we
> are not trading stability for more hacking :-)

I think we should maintain stability even when we are hacking. If a new feature
introduced regressions we should fix them even if it's not "milestone time"

So IMHO we should base our decision on
- what ratio between "open development" and "constrained development"
we'd like to have
- what is mean time to repair regressions = R
- how long is our full testing cycle = T

then milestone shedule would ideally be something like:
T for code freeze
R + T for feature freeze

and period would be
(R + 2T)/(constrained%)
adjusted by:
- how often we think community wants to see stable builds

;)

Thanks,
Mikhail

>
> Regards,
> Tim
>
> > Thanks,
> > Mikhail
> >
> > For sure,
> >> there is a balance between getting work done and ensuring that we don't
> >> go too long without a stability check.  Can you describe any piece of
> >> work that has been negatively affected?
> >>
> >> Regards,
> >> Tim
> >>
> >>
> >
>

Re: [general] M3 milestone discussion

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

Mikhail Loenko wrote:
> 2007/8/22, Tim Ellison <t....@gmail.com>:
>> Mikhail Loenko wrote:
>>> Basing on M2 experience I think 2-mo is a too short for Harmony:
>>> 25% of the whole time we would have our workspace somehow frozen.
>>> And we couldn't shorten freeze time since we have long running
>>> suites and scenarios.
>> That's not my memory, looking back in the list you froze the code on 24
>> June, and unfroze it on 30 June.
> 
> There was also "feature freeze" message on June, 14th. So it's not 10%.

Rather than get into a debate about the %'s, let's decide whether we
have the right balance between open development and ensuring
stability/demonstrating progress.

I'm sure we agree that we would like to minimize the disruption on
on-going development, but agree that we need these stability
checkpoints.  This (thread) is the first time I see a call for longer
open development periods.

> We need that length of time to run
>> tests and check stability as you mention, but it was more like 10% which
>> I think is reasonable given our current state.
>>
>>> IMHO it negatively affects progress of the project.
>>> So I'm +1 for having fixed schedule, but 2-mo schedule does not leave
>>> enough time for normal development
>> Can you explain what you mean here?  I see lots of 'normal development'
>> taking place, with hundreds of commits in each milestone.
> 
> We declare that our milestone builds are "best so far". That actually mean
> that we should not have (at least known) regressions.

Agreed.

> We have a huge amount of tests and it's impossible to run them all
> before each commit. For that reason many commits introduce regressions.

Well hopefully not 'many commits' but it is a possibility yes<g>

> Now the question is what %% of time we may focus on development of new
> features vs time on fixing regressions. Basing on CC results, it might take
> up to 2-3 weeks to fix regressions introduced by a commit (some scenarios are
> down for even longer time).

Is that because people are not looking at the CC results and fixing
them, or that we are short of machines to crunch through the scenarios?

> So that actually mean that in the 2-mo schedule
> we may do full-swing development during ~1 month, do very careful development
> 2 more weeks, and be mostly blocked 2 remaining weeks.

If we have introduced regressions, then fixing them in those two weeks
would seem like a good idea rather than continued open development.  How
long do you think is a reasonable time to let regressions ride?

> This is what I see in VM, API is definitely different: most changes are rather
> isolated.

We can certainly tweak the current practice if people feel it is
inhibiting the progress they could be making, I just want to ensure we
are not trading stability for more hacking :-)

Regards,
Tim

> Thanks,
> Mikhail
> 
> For sure,
>> there is a balance between getting work done and ensuring that we don't
>> go too long without a stability check.  Can you describe any piece of
>> work that has been negatively affected?
>>
>> Regards,
>> Tim
>>
>>
> 

Re: [general] M3 milestone discussion

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

2007/8/22, Tim Ellison <t....@gmail.com>:
> Mikhail Loenko wrote:
> > Basing on M2 experience I think 2-mo is a too short for Harmony:
> > 25% of the whole time we would have our workspace somehow frozen.
> > And we couldn't shorten freeze time since we have long running
> > suites and scenarios.
>
> That's not my memory, looking back in the list you froze the code on 24
> June, and unfroze it on 30 June.

There was also "feature freeze" message on June, 14th. So it's not 10%.

We need that length of time to run
> tests and check stability as you mention, but it was more like 10% which
> I think is reasonable given our current state.
>
> > IMHO it negatively affects progress of the project.
> > So I'm +1 for having fixed schedule, but 2-mo schedule does not leave
> > enough time for normal development
>
> Can you explain what you mean here?  I see lots of 'normal development'
> taking place, with hundreds of commits in each milestone.

We declare that our milestone builds are "best so far". That actually mean
that we should not have (at least known) regressions.

We have a huge amount of tests and it's impossible to run them all
before each commit. For that reason many commits introduce regressions.
Now the question is what %% of time we may focus on development of new
features vs time on fixing regressions. Basing on CC results, it might take
up to 2-3 weeks to fix regressions introduced by a commit (some scenarios are
down for even longer time). So that actually mean that in the 2-mo schedule
we may do full-swing development during ~1 month, do very careful development
2 more weeks, and be mostly blocked 2 remaining weeks.

This is what I see in VM, API is definitely different: most changes are rather
isolated.

Thanks,
Mikhail

For sure,
> there is a balance between getting work done and ensuring that we don't
> go too long without a stability check.  Can you describe any piece of
> work that has been negatively affected?
>
> Regards,
> Tim
>
>

Re: [general] M3 milestone discussion

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

Mikhail Loenko wrote:
> Basing on M2 experience I think 2-mo is a too short for Harmony:
> 25% of the whole time we would have our workspace somehow frozen.
> And we couldn't shorten freeze time since we have long running
> suites and scenarios.

That's not my memory, looking back in the list you froze the code on 24
June, and unfroze it on 30 June.  We need that length of time to run
tests and check stability as you mention, but it was more like 10% which
I think is reasonable given our current state.

> IMHO it negatively affects progress of the project.
> So I'm +1 for having fixed schedule, but 2-mo schedule does not leave
> enough time for normal development

Can you explain what you mean here?  I see lots of 'normal development'
taking place, with hundreds of commits in each milestone.  For sure,
there is a balance between getting work done and ensuring that we don't
go too long without a stability check.  Can you describe any piece of
work that has been negatively affected?

Regards,
Tim

Re: [general] M3 milestone discussion

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

Basing on M2 experience I think 2-mo is a too short for Harmony:
25% of the whole time we would have our workspace somehow frozen.
And we couldn't shorten freeze time since we have long running
suites and scenarios.

IMHO it negatively affects progress of the project.
So I'm +1 for having fixed schedule, but 2-mo schedule does not leave
enough time for normal development

Thanks,
Mikhail

2007/8/22, Tim Ellison <t....@gmail.com>:
> Weldon Washburn wrote:
> > hmm... Its August and lots of folks are on vacation.
>
> True, I just got back from vacation myself, but I don't see that as a
> reason to delay a stability drive and declaring a stable build as M3.
> Indeed, it could be easier if there is less churn in the code!
>
> > How about move
> > M3 to the end of September?  This will give us a few weeks to discuss
> > what should (and should not) go into M3.
>
> The content of M3 is whatever is in SVN at the point we declare it
> stable.  If there is code that is misbehaving then we would take it out
> to achieve stability across the codebase.  IMHO extending the period to
> decide what is in it doesn't make sense.
>
> So I say let's start to chill down the code in the next few days, and
> freeze next week to test and declare an M3 at the end of the month.  I
> believe that producing regular, predictable milestones is one
> characteristic of a healthy project.
>
> Regards,
> Tim
>

Re: [general] M3 milestone discussion

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

Mikhail Fursov wrote:
> Tim, here is the description of my problems with 2-mo schedule:
> Usually I spent a half of my time to work on bugs or testing, reviewing and
> committing various JIT patches. Another
> half of my time I'm trying to develop new features.

...and it is all very much appreciated!  I promise I'm not trying to
make life difficult, but ensure we are all working as efficiently as
possible while maintaining the integrity of everyone's combined efforts.

> Writing code for new
> features is not an issue: but performance and regression
> testing consumes most of the time.
> When I'm limited by a short time period and I want new feature to be
> included to the next release I need to hurry and as a result I reduce the
> time for testing and documentation.
> For example in M2 milestone we were not able to turn "lazy resolution"
> feature on because we didn't have enough time to test it. We turned it on in
> the first week after codebase was unfrozen.

There will always be the problem of 'no time left in this milestone' no
matter how long we make it of course; if we make it too long we may get
numerous big changes introduced then have to spend an incredibly long
time stabilizing.

So if we think of it this way, assuming we don't want to increase the
current freeze duration before a milestone, how much open development
could we expect to stabilize and test for performance/regression etc in
that time?

> I agree with Salikh and others who says that we need stable schedule.
> But what is the reason for official milestones that are so frequent that
> have no differences from each other?

I hope that is a joke?!  Doing a svn diff from M2 shows that in classlib
and drlvm there were ~1100 files changed (not to mention the Java 6
branch, BTI, jdktools, etc, etc) and ~320 JIRAs resolved -- I don't
think there is much danger of having no differences between two month
interval milestones.

Regards,
Tim

Re: [general] M3 milestone discussion

[Mikhail Fursov <mi...@gmail.com>]

Tim, here is the description of my problems with 2-mo schedule:
Usually I spent a half of my time to work on bugs or testing, reviewing and
committing various JIT patches. Another
half of my time I'm trying to develop new features. Writing code for new
features is not an issue: but performance and regression
testing consumes most of the time.
When I'm limited by a short time period and I want new feature to be
included to the next release I need to hurry and as a result I reduce the
time for testing and documentation.
For example in M2 milestone we were not able to turn "lazy resolution"
feature on because we didn't have enough time to test it. We turned it on in
the first week after codebase was unfrozen.

I agree with Salikh and others who says that we need stable schedule.
But what is the reason for official milestones that are so frequent that
have no differences from each other?




On 8/22/07, Salikh Zakirov <sa...@gmail.com> wrote:
>
> Tim Ellison wrote:
> > Weldon Washburn wrote:
> >> How about move
> >> M3 to the end of September?  This will give us a few weeks to discuss
> >> what should (and should not) go into M3.
> >
> > The content of M3 is whatever is in SVN at the point we declare it
> > stable.  If there is code that is misbehaving then we would take it out
> > to achieve stability across the codebase.  IMHO extending the period to
> > decide what is in it doesn't make sense.
>
> FWIW, I think that keeping 2-month cycle is better for the project.
>
> For an external observer, postponing the release schedule will most likely
> mean that either
> (1) SVN trunk has serious stability problems, or
> (2) development stalled and no differences from M3 are there to warrant a
> new release
> To my knowledge, both are not true, and neither is the message we would
> want
> to send to the world.
>
> As I reasoned elsewhere, I think the most beneficial strategy for Harmony
> project
> now would be release _officially_ (rather than doing developer snapshots)
> and keep to the schedule,
> so as the distributions could start including Harmony into the 'unstable'
> areas.
>
>


-- 
Mikhail Fursov

Re: [general] M3 milestone discussion

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

On 8/27/07, Tim Ellison <t....@gmail.com> wrote:
> Salikh Zakirov wrote:
> > Tim Ellison wrote:
> >> Agreed, and the problems with getting a JCK license to certify official
> >> releases have been well-documented.  We want to release a Java
> >> implementation, not something that is not quite Java.
> >
> > Somehow I cannot understand how the "official" status of the release
> > is related to the "certification with JCK" status.
>
> The 'official' goal of the project is to create Java SE, and the only
> way to do that is to pass the corresponding JCK.
>
> > I understand the desire of releasing certified 1.0 (or is it 5.0?)
> > version, however, I cannot see why alpha or beta releases should
> > not be done before JCK certification.
>
> When we pass the JCK for 5.0 we can call the result Java SE 5.0, we
> wouldn't use 1.0.

Tim,

It's Java SE 5.0, but it's not necessarily Harmony 5.0. I see no
problem to call it Harmony 1.0 (or else) when it passes JCK for 5.0.

As a software project, I think Harmony deserves its own versioning
scheme. It it a little bit uncomfortable to see M3, M4, ..., M100,
then see a 5.0. Current Mx naming scheme is hard to get an impression
on the project status.

Thanks,
xiaofeng

> We are producing builds milestone towards that goal, but the
> certification is all or nothing.
>
> > Careful reading of Apache licensing policy [1] says that this is the
> > sort of decision done by PMC.
>
> The PMC are all on this list, though with summer vacations etc. things
> are quiet.
>
> > However, it also says that anything
> > with non-released status should not be advertised outside of the mailing
> > list (i.e. on the web site), and therefore, should not be packaged
> > for end-users (i.e. Debian or Gentoo packages).
> >
> > Thus, I understand what you are saying as "we should not yet advertise ourselves
> > outside of our mailing list". This is exactly opposite of my opinion, that
> > Harmony project need to start recruiting beta-testers (alpha-testers?)
> > in a wider audience.
>
> I agree that we should be recruiting further testers and early adopters.
>  They are most likely to be developers on other significant Java
> projects, and in fairness we have been very responsive to them.  Feel
> free to try some apps and discuss the results.
>
> > This is also in contradiction with the fact of stable builds being announced
> > on the web site.
>
> <shrug/> We have enough warnings and caveats on there.
>
> > What I am suggesting, is
> > (1) come up with a stable versioning scheme (FWIW, M1 has happened to DRLVM twice already),
>
> It did?
>
> > (2) decide if the current status is alpha or beta
>
> Alpha or beta towards what?  We cal them development snapshots which is
> what they are.
>
> > (3) release the next stable snapshot officially (following all the requirements [1])
> >     with either of alpha and beta status
> >     and all necessary notices about non-compatibility and non-certified status.
> > (4) remove the "they are not official releases of the Apache Harmony project" notices
> >     from the download page.
> > (5) and finally, encourage (rather than discourage) including these alpha releases
> >     to "unstable" areas of the popular Linux distributions
>
> That's a proposal to bring into a wider forum (e.g. jcp-open@) since you
> are suggesting that the ASF endorse a Java look-alike runtime.  The
> ASF/Sun/JCP discussions are attempting to resolve whether we Sun will
> honor their promise to provide a suitable license.
>
> > PMC may as well disagree with this suggestion, but it would be nice to hear where exactly
> > disagreement lies:
>
> You may get more responses as people catch-up with their mail...
>
> > (a) if Harmony project should not seek for a wider tester base?
>
> I think we should, and we are.
>
> > (b) if Harmony project should not encourage packaging for distributions?
>
> again, we should and we are,
>
> > (c) if Harmony project should not do uncertified alpha and beta releases?
>
> we have the stable milestones for testing and early adopters.  As above,
> I don't know how you would declare alpha or beta status against a set of
> criteria we don't have access to at the moment.
>
> Regards,
> Tim
>
> > [1] http://www.apache.org/dev/release.html#what
> >
> > quote from Apache Releases FAQ [1]
> >> During the process of developing software and preparing a release,
> >> various packages are made available to the developer community for testing purposes.
> >> Do not include any links on the project website that might encourage non-developers
> >> to download and use nightly builds, snapshots, release candidates, or any other
> >> similar package. The only people who are supposed to know about such packages are
> >> the people following the dev list (or searching its archives) and thus aware
> >> of the conditions placed on the package. If you find that the general public
> >> are downloading such test packages, then remove them.
> >
> >
> >
> >
>


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

Re: [general] M3 milestone discussion

[Salikh Zakirov <sa...@gmail.com>]

Tim Ellison wrote:
> The 'official' goal of the project is to create Java SE, and the only
>  way to do that is to pass the corresponding JCK. ...

Tim, thanks a lot for a detailed response.
I see that generally our views are not that different,
the difference being mostly in definition of what release
must constitute to warrant an "official" status.

Seeing that inagreement is small and (hopefully) not that significant,
I will try to refrain from further flaming after giving answers
and reconciling the discussion.

>> (2) decide if the current status is alpha or beta
> 
> Alpha or beta towards what?  We call them development snapshots which
> is what they are.

Alpha/beta status is towards the stated project goal: be certified and compatible. 
We cannot assess certifiability, but we have some data on compatibility 
(application status and various test suites).

>From my point of view, the current snapshots look more like
alpha releaseas, though labeled as development snapshots.

In the end, the labeling difference may cause a fraction of potential beta testers,
who would check out the official beta build, to be scared
away by the inofficial snapshot status -- hopefully this fraction is small enough to be ignorable.

>> (5) and finally, encourage (rather than discourage) including these
>> alpha releases
>>> to "unstable" areas of the popular Linux distributions
> 
> That's a proposal to bring into a wider forum (e.g. jcp-open@) since
> you are suggesting that the ASF endorse a Java look-alike runtime.
> The ASF/Sun/JCP discussions are attempting to resolve whether we Sun
> will honor their promise to provide a suitable license.

I do not think it makes sense to bring this proposal into a wider forum
unless there is significant support for it in Harmony PMC.
Nevertheless, it captures my point of view pretty well.

> As above, I don't know how you would declare alpha or beta status
> against a set of criteria we don't have access to at the moment.

IMHO, we have the criteria: (1) Java specifications
(2) compatibility on existing applications

What we don't have is a means to estimate how far we are from being
able to qualify for the Java-compatible logo.

Re: [general] M3 milestone discussion

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

Salikh Zakirov wrote:
> Tim Ellison wrote:
>> The 'official' goal of the project is to create Java SE, and the only
>> way to do that is to pass the corresponding JCK.
>> ...
> 
> Tim, thanks a lot for a detailed response.
> I see that generally our views are not that different,
> the difference being mostly in definition of what release
> must constitute to warrant an "official" status.
> 
> Seeing that inagreement is small and (hopefully) not that significant,
> I will try to refrain from further flaming after giving answers
> and reconciling the discussion.

I think we are a long way from flaming <g>

>>> (2) decide if the current status is alpha or beta
>>
>> Alpha or beta towards what?  We call them development snapshots which is
>> what they are.
> 
> Alpha/beta status is towards the stated project goal: be certified and
> compatible. We cannot assess certifiability, but we have some data on
> compatibility (application status and various test suites).

Agreed.  And I think it would serve us well to clearly demonstrate the
compatibility goals we have achieved.

> From my point of view, the current snapshots look more like an alpha
> releaseas, though labeled as development snapshots.
> 
> In the end, the labeling difference may cause a fraction of potential
> beta testers, who would check out the official beta build, to be scared
> away by the inofficial snapshot status -- hopefully this fraction is
> small enough to be ignorable.

For now, we have to continue calling them unofficial Java SE and work in
progress.

>>> (5) and finally, encourage (rather than discourage) including these
>>> alpha releases
>>> >     to "unstable" areas of the popular Linux distributions
>>
>> That's a proposal to bring into a wider forum (e.g. jcp-open@) since you
>> are suggesting that the ASF endorse a Java look-alike runtime.  The
>> ASF/Sun/JCP discussions are attempting to resolve whether we Sun will
>> honor their promise to provide a suitable license.
> 
> I do not think it makes sense to bring this proposal into a wider forum
> unless there is significant support for it in Harmony PMC.
> Nevertheless, it captures my point of view pretty well.

The Harmony PMC views must not be out of alignment with the developer
views, so we make decisions in the open on this list.  There has been no
private PMC discussion on this.

>> As above,
>> I don't know how you would declare alpha or beta status against a set of
>> criteria we don't have access to at the moment.
> 
> To the contrary, we _have_ the criteria: (1) Java specifications
> (2) compatibility on existing applications
> 
> What we don't have is a means to estimate how far we are from being
> able to qualify for the Java-compatible logo.

No, the ability to use the logo is a different agreement yet again!  We
don't have a means of measuring how close we are to the official
definition of specification compliance (i.e. passing the JCK), and then
receiving the rights that come from being compliant.

Regards,
Tim

Re: [general] M3 milestone discussion

[Salikh Zakirov <sa...@gmail.com>]

Tim Ellison wrote:
> The 'official' goal of the project is to create Java SE, and the only
> way to do that is to pass the corresponding JCK.
> ...

Tim, thanks a lot for a detailed response.
I see that generally our views are not that different,
the difference being mostly in definition of what release
must constitute to warrant an "official" status.

Seeing that inagreement is small and (hopefully) not that significant,
I will try to refrain from further flaming after giving answers
and reconciling the discussion.

>> (2) decide if the current status is alpha or beta
> 
> Alpha or beta towards what?  We call them development snapshots which is
> what they are.

Alpha/beta status is towards the stated project goal: be certified and 
compatible. We cannot assess certifiability, but we have some data on 
compatibility (application status and various test suites).

 From my point of view, the current snapshots look more like an alpha 
releaseas, though labeled as development snapshots.

In the end, the labeling difference may cause a fraction of potential 
beta testers, who would check out the official beta build, to be scared
away by the inofficial snapshot status -- hopefully this fraction is 
small enough to be ignorable.

>> (5) and finally, encourage (rather than discourage) including these alpha releases
>> >     to "unstable" areas of the popular Linux distributions
> 
> That's a proposal to bring into a wider forum (e.g. jcp-open@) since you
> are suggesting that the ASF endorse a Java look-alike runtime.  The
> ASF/Sun/JCP discussions are attempting to resolve whether we Sun will
> honor their promise to provide a suitable license.

I do not think it makes sense to bring this proposal into a wider forum 
unless there is significant support for it in Harmony PMC.
Nevertheless, it captures my point of view pretty well.

> As above,
> I don't know how you would declare alpha or beta status against a set of
> criteria we don't have access to at the moment.

To the contrary, we _have_ the criteria: (1) Java specifications
(2) compatibility on existing applications

What we don't have is a means to estimate how far we are from being
able to qualify for the Java-compatible logo.

Re: [general] M3 milestone discussion

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

Salikh Zakirov wrote:
> Tim Ellison wrote:
>> Agreed, and the problems with getting a JCK license to certify official
>> releases have been well-documented.  We want to release a Java
>> implementation, not something that is not quite Java.
> 
> Somehow I cannot understand how the "official" status of the release
> is related to the "certification with JCK" status.

The 'official' goal of the project is to create Java SE, and the only
way to do that is to pass the corresponding JCK.

> I understand the desire of releasing certified 1.0 (or is it 5.0?)
> version, however, I cannot see why alpha or beta releases should
> not be done before JCK certification.

When we pass the JCK for 5.0 we can call the result Java SE 5.0, we
wouldn't use 1.0.

We are producing builds milestone towards that goal, but the
certification is all or nothing.

> Careful reading of Apache licensing policy [1] says that this is the
> sort of decision done by PMC.

The PMC are all on this list, though with summer vacations etc. things
are quiet.

> However, it also says that anything
> with non-released status should not be advertised outside of the mailing
> list (i.e. on the web site), and therefore, should not be packaged
> for end-users (i.e. Debian or Gentoo packages).
> 
> Thus, I understand what you are saying as "we should not yet advertise ourselves
> outside of our mailing list". This is exactly opposite of my opinion, that
> Harmony project need to start recruiting beta-testers (alpha-testers?)
> in a wider audience.

I agree that we should be recruiting further testers and early adopters.
 They are most likely to be developers on other significant Java
projects, and in fairness we have been very responsive to them.  Feel
free to try some apps and discuss the results.

> This is also in contradiction with the fact of stable builds being announced
> on the web site.

<shrug/> We have enough warnings and caveats on there.

> What I am suggesting, is 
> (1) come up with a stable versioning scheme (FWIW, M1 has happened to DRLVM twice already),

It did?

> (2) decide if the current status is alpha or beta

Alpha or beta towards what?  We cal them development snapshots which is
what they are.

> (3) release the next stable snapshot officially (following all the requirements [1])
>     with either of alpha and beta status
>     and all necessary notices about non-compatibility and non-certified status.
> (4) remove the "they are not official releases of the Apache Harmony project" notices
>     from the download page.
> (5) and finally, encourage (rather than discourage) including these alpha releases
>     to "unstable" areas of the popular Linux distributions

That's a proposal to bring into a wider forum (e.g. jcp-open@) since you
are suggesting that the ASF endorse a Java look-alike runtime.  The
ASF/Sun/JCP discussions are attempting to resolve whether we Sun will
honor their promise to provide a suitable license.

> PMC may as well disagree with this suggestion, but it would be nice to hear where exactly
> disagreement lies:

You may get more responses as people catch-up with their mail...

> (a) if Harmony project should not seek for a wider tester base?

I think we should, and we are.

> (b) if Harmony project should not encourage packaging for distributions?

again, we should and we are,

> (c) if Harmony project should not do uncertified alpha and beta releases?

we have the stable milestones for testing and early adopters.  As above,
I don't know how you would declare alpha or beta status against a set of
criteria we don't have access to at the moment.

Regards,
Tim

> [1] http://www.apache.org/dev/release.html#what 
> 
> quote from Apache Releases FAQ [1]
>> During the process of developing software and preparing a release, 
>> various packages are made available to the developer community for testing purposes. 
>> Do not include any links on the project website that might encourage non-developers
>> to download and use nightly builds, snapshots, release candidates, or any other
>> similar package. The only people who are supposed to know about such packages are
>> the people following the dev list (or searching its archives) and thus aware
>> of the conditions placed on the package. If you find that the general public
>> are downloading such test packages, then remove them.
> 
> 
> 
> 

Re: [general] M3 milestone discussion

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

I personally somehow concur with Salikh's opinion. As Tim mentioned,
"the problems with getting a JCK license to certify official releases
have been well-documented". We have to face the situation, and we
probably want to start releasing "official" Harmony with a new and
formal and stable versioning scheme till we get a certified version
released. It can be started from 0.1, for example, or something like
that.

The official release can have a little longer release cycle, say, 3
months, to give us more time to enhance Harmony in both robustness,
performance and new features, i.e., to make it worth a release. I
really think it's time to consider providing Harmony package to
various Linux distributions. If we think it's  not mature enough for
distribution packages, we can call it 0.1alpha.

Thanks,
xiaofeng

On 8/23/07, Salikh Zakirov <sa...@gmail.com> wrote:
> Tim Ellison wrote:
> > Agreed, and the problems with getting a JCK license to certify official
> > releases have been well-documented.  We want to release a Java
> > implementation, not something that is not quite Java.
>
> Somehow I cannot understand how the "official" status of the release
> is related to the "certification with JCK" status.
> I understand the desire of releasing certified 1.0 (or is it 5.0?)
> version, however, I cannot see why alpha or beta releases should
> not be done before JCK certification.
>
> Careful reading of Apache licensing policy [1] says that this is the
> sort of decision done by PMC. However, it also says that anything
> with non-released status should not be advertised outside of the mailing
> list (i.e. on the web site), and therefore, should not be packaged
> for end-users (i.e. Debian or Gentoo packages).
>
> Thus, I understand what you are saying as "we should not yet advertise ourselves
> outside of our mailing list". This is exactly opposite of my opinion, that
> Harmony project need to start recruiting beta-testers (alpha-testers?)
> in a wider audience.
>
> This is also in contradiction with the fact of stable builds being announced
> on the web site.
>
> What I am suggesting, is
> (1) come up with a stable versioning scheme (FWIW, M1 has happened to DRLVM twice already),
> (2) decide if the current status is alpha or beta
> (3) release the next stable snapshot officially (following all the requirements [1])
>     with either of alpha and beta status
>     and all necessary notices about non-compatibility and non-certified status.
> (4) remove the "they are not official releases of the Apache Harmony project" notices
>     from the download page.
> (5) and finally, encourage (rather than discourage) including these alpha releases
>     to "unstable" areas of the popular Linux distributions
>
> PMC may as well disagree with this suggestion, but it would be nice to hear where exactly
> disagreement lies:
>
> (a) if Harmony project should not seek for a wider tester base?
> (b) if Harmony project should not encourage packaging for distributions?
> (c) if Harmony project should not do uncertified alpha and beta releases?
>
> [1] http://www.apache.org/dev/release.html#what
>
> quote from Apache Releases FAQ [1]
> > During the process of developing software and preparing a release,
> > various packages are made available to the developer community for testing purposes.
> > Do not include any links on the project website that might encourage non-developers
> > to download and use nightly builds, snapshots, release candidates, or any other
> > similar package. The only people who are supposed to know about such packages are
> > the people following the dev list (or searching its archives) and thus aware
> > of the conditions placed on the package. If you find that the general public
> > are downloading such test packages, then remove them.
>
>
>
>


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

Re: [general] M3 milestone discussion

[Salikh Zakirov <sa...@gmail.com>]

Tim Ellison wrote:
> Agreed, and the problems with getting a JCK license to certify official
> releases have been well-documented.  We want to release a Java
> implementation, not something that is not quite Java.

Somehow I cannot understand how the "official" status of the release
is related to the "certification with JCK" status.
I understand the desire of releasing certified 1.0 (or is it 5.0?)
version, however, I cannot see why alpha or beta releases should
not be done before JCK certification.

Careful reading of Apache licensing policy [1] says that this is the
sort of decision done by PMC. However, it also says that anything
with non-released status should not be advertised outside of the mailing
list (i.e. on the web site), and therefore, should not be packaged
for end-users (i.e. Debian or Gentoo packages).

Thus, I understand what you are saying as "we should not yet advertise ourselves
outside of our mailing list". This is exactly opposite of my opinion, that
Harmony project need to start recruiting beta-testers (alpha-testers?)
in a wider audience.

This is also in contradiction with the fact of stable builds being announced
on the web site.

What I am suggesting, is 
(1) come up with a stable versioning scheme (FWIW, M1 has happened to DRLVM twice already),
(2) decide if the current status is alpha or beta
(3) release the next stable snapshot officially (following all the requirements [1])
    with either of alpha and beta status
    and all necessary notices about non-compatibility and non-certified status.
(4) remove the "they are not official releases of the Apache Harmony project" notices
    from the download page.
(5) and finally, encourage (rather than discourage) including these alpha releases
    to "unstable" areas of the popular Linux distributions

PMC may as well disagree with this suggestion, but it would be nice to hear where exactly
disagreement lies:

(a) if Harmony project should not seek for a wider tester base?
(b) if Harmony project should not encourage packaging for distributions?
(c) if Harmony project should not do uncertified alpha and beta releases?

[1] http://www.apache.org/dev/release.html#what 

quote from Apache Releases FAQ [1]
> During the process of developing software and preparing a release, 
> various packages are made available to the developer community for testing purposes. 
> Do not include any links on the project website that might encourage non-developers
> to download and use nightly builds, snapshots, release candidates, or any other
> similar package. The only people who are supposed to know about such packages are
> the people following the dev list (or searching its archives) and thus aware
> of the conditions placed on the package. If you find that the general public
> are downloading such test packages, then remove them.

Re: [general] M3 milestone discussion

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

Salikh Zakirov wrote:
> Tim Ellison wrote:
>> Weldon Washburn wrote:
>>> How about move
>>> M3 to the end of September?  This will give us a few weeks to discuss
>>> what should (and should not) go into M3.
>> The content of M3 is whatever is in SVN at the point we declare it
>> stable.  If there is code that is misbehaving then we would take it out
>> to achieve stability across the codebase.  IMHO extending the period to
>> decide what is in it doesn't make sense.
> 
> FWIW, I think that keeping 2-month cycle is better for the project.
> 
> For an external observer, postponing the release schedule will most likely
> mean that either
> (1) SVN trunk has serious stability problems, or
> (2) development stalled and no differences from M3 are there to warrant a new release
> To my knowledge, both are not true, and neither is the message we would want
> to send to the world.
> 
> As I reasoned elsewhere, I think the most beneficial strategy for Harmony project
> now would be release _officially_ (rather than doing developer snapshots) and keep to the schedule,
> so as the distributions could start including Harmony into the 'unstable' areas.

Agreed, and the problems with getting a JCK license to certify official
releases have been well-documented.  We want to release a Java
implementation, not something that is not quite Java.

I assure you that fixing this is something the ASF is actively working on.

Regards,
Tim

Re: [general] M3 milestone discussion

[Salikh Zakirov <sa...@gmail.com>]

Tim Ellison wrote:
> Weldon Washburn wrote:
>> How about move
>> M3 to the end of September?  This will give us a few weeks to discuss
>> what should (and should not) go into M3.
> 
> The content of M3 is whatever is in SVN at the point we declare it
> stable.  If there is code that is misbehaving then we would take it out
> to achieve stability across the codebase.  IMHO extending the period to
> decide what is in it doesn't make sense.

FWIW, I think that keeping 2-month cycle is better for the project.

For an external observer, postponing the release schedule will most likely
mean that either
(1) SVN trunk has serious stability problems, or
(2) development stalled and no differences from M3 are there to warrant a new release
To my knowledge, both are not true, and neither is the message we would want
to send to the world.

As I reasoned elsewhere, I think the most beneficial strategy for Harmony project
now would be release _officially_ (rather than doing developer snapshots) and keep to the schedule,
so as the distributions could start including Harmony into the 'unstable' areas.

Re: [general] M3 milestone discussion

[Salikh Zakirov <sa...@gmail.com>]

Alexey Varlamov wrote:
> It well might went unnoticed, but there are src snapshots released
> along with the dev binaries, since 8/15. Looks like it is the right
> time to update downloads page on the website :)

Thanks, that's good to know. I found the source snapshots in the
particular revision snapshot directories, like

   http://people.apache.org/builds/harmony/snapshots/r567890/apache-harmony-src-r567890-snapshot.tar.gz

Re: [general] M3 milestone discussion

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

Salikh,

It well might went unnoticed, but there are src snapshots released
along with the dev binaries, since 8/15. Looks like it is the right
time to update downloads page on the website :)

2007/8/22, Salikh Zakirov <sa...@gmail.com>:
> Tim Ellison wrote:
> > So I say let's start to chill down the code in the next few days, and
> > freeze next week to test and declare an M3 at the end of the month.  I
> > believe that producing regular, predictable milestones is one
> > characteristic of a healthy project.
>
> One more thing that I am looking forward to, besides the official release status,
> is the source release availability.
> It will allow to create a proper Gentoo ebuild file.
>
>

Re: [general] M3 milestone discussion

[Salikh Zakirov <sa...@gmail.com>]

Tim Ellison wrote:
> So I say let's start to chill down the code in the next few days, and
> freeze next week to test and declare an M3 at the end of the month.  I
> believe that producing regular, predictable milestones is one
> characteristic of a healthy project.

One more thing that I am looking forward to, besides the official release status,
is the source release availability. 
It will allow to create a proper Gentoo ebuild file.

Re: [general] M3 milestone discussion

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

Weldon Washburn wrote:
> hmm... Its August and lots of folks are on vacation.

True, I just got back from vacation myself, but I don't see that as a
reason to delay a stability drive and declaring a stable build as M3.
Indeed, it could be easier if there is less churn in the code!

> How about move
> M3 to the end of September?  This will give us a few weeks to discuss
> what should (and should not) go into M3.

The content of M3 is whatever is in SVN at the point we declare it
stable.  If there is code that is misbehaving then we would take it out
to achieve stability across the codebase.  IMHO extending the period to
decide what is in it doesn't make sense.

So I say let's start to chill down the code in the next few days, and
freeze next week to test and declare an M3 at the end of the month.  I
believe that producing regular, predictable milestones is one
characteristic of a healthy project.

Regards,
Tim

Re: [general] M3 milestone discussion

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

On 8/13/07, Weldon Washburn wrote:
> hmm... Its August and lots of folks are on vacation.  How about move
> M3 to the end of September?  This will give us a few weeks to discuss
> what should (and should not) go into M3.
>

Yes, I see that most of folks are on vacation so there are no
objections for shifting M3 to September :-)

Thanks,
Stepan.

> On 8/12/07, Stepan Mishura wrote:
> > Hi,
> >
> > Before M2 we agreed on 2-month milestone schedule so we are close to M3.
> >
> > I'd like to start discussion
> > - schedule: are everybody comfort with 2-month milestone schedule(IOW,
> > are we ready for next milestone in the end of August)
> > - plans/targets: platforms, what worse to be included to the
> > milestone, fixed in the milestone
> >
> > Thoughts?
> >
> > Thanks,
> > Stepan Mishura
> > Intel Enterprise Solutions Software Division
> >
>
>
> --
> Weldon Washburn
>

Re: [general] M3 milestone discussion

[Weldon Washburn <we...@gmail.com>]

hmm... Its August and lots of folks are on vacation.  How about move
M3 to the end of September?  This will give us a few weeks to discuss
what should (and should not) go into M3.

On 8/12/07, Stepan Mishura <st...@gmail.com> wrote:
> Hi,
>
> Before M2 we agreed on 2-month milestone schedule so we are close to M3.
>
> I'd like to start discussion
> - schedule: are everybody comfort with 2-month milestone schedule(IOW,
> are we ready for next milestone in the end of August)
> - plans/targets: platforms, what worse to be included to the
> milestone, fixed in the milestone
>
> Thoughts?
>
> Thanks,
> Stepan Mishura
> Intel Enterprise Solutions Software Division
>


-- 
Weldon Washburn