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