Re: Re: [general] POLL : supported platforms

2006-10-18 Thread Alex Blewitt

Even better:

Yes
No
Maybe

:-)

On 18/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

Better :

Supported
Not-Supported
In-Progress


Mikhail Fursov wrote:
 Mikhail,
 I support your classification: it covers all types I can imagine.

 Here is my proposal of naming:
 1) not supported
 2) product or supported
 3) incubation


 On 10/18/06, Mikhail Loenko [EMAIL PROTECTED] wrote:

 Well, I think there are at least three categories of platforms:

 1) Platforms that we don't care about
 2) Platforms that we think work and we want them working
 3) Platforms that we want working but they still don't

 We definitely have to roll back the commits that break #2.

 We need some 'protection' policy to make it possible for platforms
 to graduate from #3 to #2

 And we need some criteria to define how #1 could become #3

 And we need names for the categories that are not misleading

 Comments?

 Thanks,
 Mikhail

 2006/10/18, Geir Magnusson Jr. [EMAIL PROTECTED]:
 
 
  Mikhail Fursov wrote:
   Mikhail,
   The situation is possible with some Linux clones.
   And if we have such a situation I propose to take into account if we
 have a
   commiter/volunteer to check this platform.
   If we have a volunteer  - we support it.
  
   Another question is: what if volunteer is gone and no one supports
 the
   platform? Will we claim that Harmony no longer supports the platform?
 
  No - to be supported, we have to agree as a community.  I'm wary about
  there being one-person-supported platforms.
 
  We can easily have two categories -
 
  a) platforms that we certify as being compatible, and support
 
  b) platforms that we certify as being compatible, but don't make any
  support promises
 
  geir
 
  
   On 10/18/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
  
   2006/10/17, Geir Magnusson Jr. [EMAIL PROTECTED]:
   
   
Mikhail Loenko wrote:
 2006/10/17, Geir Magnusson Jr. [EMAIL PROTECTED]:


 Mikhail Fursov wrote:
 I think if we decide to support a platform then we define a set
 of
   tests
 that
 must pass on that platform after each commit and we do roll back
 if
   they
 fail. That is how I understand support
   
Lets define support as passing 90% of classlib unit and
smoke/c-unit/kernel in DRLVM
  
   It might be a criteria for addition to the set of supported, but
 can't
   be a definition.
   Logically there could be a platform that we don't know, but that
 platform
   could
   pass 99% of the tests, do you think we can support a platform we
 don't
   have any
   idea about?
  
   Thanks,
   Mikhail
  
  
  
   
geir
   
   
 -
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail:
 [EMAIL PROTECTED]
For additional commands, e-mail:
 [EMAIL PROTECTED]
   
   
  
  
 -
   Terms of use : http://incubator.apache.org/harmony/mailing.html
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail:
 [EMAIL PROTECTED]
  
  
  
  
 
  -
  Terms of use : http://incubator.apache.org/harmony/mailing.html
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Re: [general] POLL : supported platforms

2006-10-18 Thread Mikhail Loenko

Good! :)

Now it's more or less clear about the categories that we have and I suggest
that we discuss policies around the categories.

Probably we will have weaker policies for the current stage of the project and
stricter policies when we are closer to release.

I suggest that we discuss current policies first.

For the category Yes or Supported we do our best to not break it with
commits. Do our best to be defined later. If a commit breaks that platform
we stop further commits and either fix or roll it back ASAP. Comments?

For the category In-progress we should probably have weaker policies
comparing to Supported, but we still need some. Ideas?
Possibly we should try not to break it and if we break then discuss
whether it was intentionally or not and may decide to roll it back or
do something
else. Other ideas?

Thanks,
Mikhail

2006/10/19, Alex Blewitt [EMAIL PROTECTED]:

Even better:

Yes
No
Maybe

:-)

On 18/10/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
 Better :

 Supported
 Not-Supported
 In-Progress


 Mikhail Fursov wrote:
  Mikhail,
  I support your classification: it covers all types I can imagine.
 
  Here is my proposal of naming:
  1) not supported
  2) product or supported
  3) incubation
 
 
  On 10/18/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
 
  Well, I think there are at least three categories of platforms:
 
  1) Platforms that we don't care about
  2) Platforms that we think work and we want them working
  3) Platforms that we want working but they still don't
 
  We definitely have to roll back the commits that break #2.
 
  We need some 'protection' policy to make it possible for platforms
  to graduate from #3 to #2
 
  And we need some criteria to define how #1 could become #3
 
  And we need names for the categories that are not misleading
 
  Comments?
 
  Thanks,
  Mikhail
 
  2006/10/18, Geir Magnusson Jr. [EMAIL PROTECTED]:
  
  
   Mikhail Fursov wrote:
Mikhail,
The situation is possible with some Linux clones.
And if we have such a situation I propose to take into account if we
  have a
commiter/volunteer to check this platform.
If we have a volunteer  - we support it.
   
Another question is: what if volunteer is gone and no one supports
  the
platform? Will we claim that Harmony no longer supports the platform?
  
   No - to be supported, we have to agree as a community.  I'm wary about
   there being one-person-supported platforms.
  
   We can easily have two categories -
  
   a) platforms that we certify as being compatible, and support
  
   b) platforms that we certify as being compatible, but don't make any
   support promises
  
   geir
  
   
On 10/18/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
   
2006/10/17, Geir Magnusson Jr. [EMAIL PROTECTED]:


 Mikhail Loenko wrote:
  2006/10/17, Geir Magnusson Jr. [EMAIL PROTECTED]:
 
 
  Mikhail Fursov wrote:
  I think if we decide to support a platform then we define a set
  of
tests
  that
  must pass on that platform after each commit and we do roll back
  if
they
  fail. That is how I understand support

 Lets define support as passing 90% of classlib unit and
 smoke/c-unit/kernel in DRLVM
   
It might be a criteria for addition to the set of supported, but
  can't
be a definition.
Logically there could be a platform that we don't know, but that
  platform
could
pass 99% of the tests, do you think we can support a platform we
  don't
have any
idea about?
   
Thanks,
Mikhail
   
   
   

 geir


  -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail:
  [EMAIL PROTECTED]
 For additional commands, e-mail:
  [EMAIL PROTECTED]


   
   
  -
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
  [EMAIL PROTECTED]
   
   
   
   
  
   -
   Terms of use : http://incubator.apache.org/harmony/mailing.html
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 
  -
  Terms of use : http://incubator.apache.org/harmony/mailing.html
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 

 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To