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 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]
