You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Rob Weir <ro...@apache.org> on 2013/01/01 17:59:42 UTC
What does "supported" mean for us?
When a commercial software vendor says a configuration is "supported"
it means something, typically that to the extent the software license
includes an entitlement to support, that the vendor will provide that
service for that configuration. So saying something is "supported" is
essentially an obligation.
With a volunteer-run, open source project, "supported" cannot mean
quite the same thing. We're not obligated, in any contractual sense,
to provide anyone with anything. That's the nature of a volunteer
effort.
However, users and organizations considering OpenOffice will naturally
think in terms of "support", even if they user that term loosely. We
use that term as well, in our release notes, etc. But I think we
ought to have a more precise definition of what we mean when we say
something is "supported", in order to avoid any confusion. This
question has come up recently, with regards to the status of Windows
8, where that OS had not been released at the time AOO 3.4.1 was
released.
So here's a strawman proposal for what "supported" means for us.
1) "Supported" is a statement we make about a specific version of AOO
used with a specific platform, e.g., AOO 3.4.1 with Windows XP SP3 or
AOO 3.4 with Ubuntu 12.04 LTS.
2) "Supported" means we encourage use of AOO in that configuration.
We have high confidence that the combination is stable, that it works
well and is safe.
3) Our confidence in stating something is supported should have a
solid basis in testing. Something is not "supported" by us guessing
it should work. It is supported only after we have successfully
completed testing of that release with that platform. We probably
should define exactly what level of testing is required.
4) "Supported" also implies that the supported configuration is
sufficiently available and there is sufficient expertise that we have
confidence that users will have a high quality experience seeking
support on the forums and user list.
5) "Supported" also implies that we stand behind that release and will
take necessary steps to correct *critical* bugs, especially security
flaws, via rapidly produced point releases where necessary.
Note that these are all expectations that a user might have, though
any given user might think that "supported" means only a subset of
these.
What we probably really need is more of a lifecycle statement,
including when support for a configuration ends.
-Rob
Re: What does "supported" mean for us?
Posted by Roberto Galoppini <rg...@geek.net>.
On Wed, Jan 2, 2013 at 3:39 AM, Ian C <ia...@amham.net> wrote:
> A corollary to this is also the notion of End of Life, or when is a
> release no longer "supported".
> In a volunteer framework that may be never, someone may always be
> fiddling with an older version?
> Are older releases archived forever?
>
> When do we say "Sorry that will not be fixed, please upgrade to a
> newer version that already addressees the issue"?
> I wrestle with this in a commercial environment all the time.
> Sometimes upgrading is a time consuming task and one in which the user
> needs to the have confidence in the product to do it.
I believe this is material in an enterprise environment. It's not rare
to see vendors supporting commercially an open source platform to
offer long-time support services for older versions. As a matter of
fact users and paying customers need that. It would be good to give
people an option, if the community doesn't support older versions
maybe there are vendors doing that.
Roberto thinking loud too
>
> Just thinking out loud.
>
> Best wishes for the New Year to one and all....
>
> On Wed, Jan 2, 2013 at 2:43 AM, Rob Weir <ro...@apache.org> wrote:
>> On Tue, Jan 1, 2013 at 1:03 PM, Dave Fisher <da...@comcast.net> wrote:
>>> HI Rob,
>>>
>>> I like your emphasis here on "Supported". Let's discuss support in terms of actual process and precisely what are official releases vs. user convenience releases. Both of which are VOTED, but only the source code release can be completely vetted by all of the project. The convenience binaries are well tested and approved. These are what you are discussing when you describe "Supported" below.
>>>
>>
>> Even when we release source code it is relevant what platforms and
>> configurations have been tested and which ones we say we support.
>> Remember, we're not releasing a literary work, source code to be
>> printed on paper and read for enjoyment. It is source code that's
>> only practical use is to be compiled into binaries that must of
>> necessity run on an operating system. So platform support is equally
>> relevant for both source and binary distributions. To support one is
>> to support another. For example, if we say we support Windows XP,
>> then we must maintain a building guide and be prepared to answer
>> questions from those who want to build binaries that work on that
>> platform. So there a parallel support and maintenance obligation for
>> the source distributions as well.
>>
>>
>>> So when the project votes to release a user convenience binary we are voting to support that configuration. This can change at any release.
>>>
>>
>> In most cases this would happen simultaneously with the release of the
>> source distribution. But there may be cases where testing of a
>> platform only completes at a latter point and we indicate it is
>> supported then. This might not require a release of any new source or
>> binary. Windows 8 might be a good example here. It was released
>> after AOO 3.4.1 came out. If we tested it now and found it worked
>> fine, then we would simply update the release notes to reflect this.
>> No formal vote required. Lazy consensus should be enough, I think.
>>
>>> Packages are built by project members using the buildbot or on personal equipment.
>>>
>>> Let's look at Apache Subversion's packages [1]. The project only produces source code and the binary packages are the responsibility of third parties.
>>
>> So does Subversion release purely based on reviewing source code? Or
>> does their community test binaries on particular platforms? Of course
>> they do. Their release notes are filled with observations on what
>> configurations work and which do not:
>> http://subversion.apache.org/docs/release-notes/1.7
>>
>> That's the nature of cross-platform C++ code. IMHO, what platforms
>> are supported is unrelated to the source versus binary question. The
>> binary is simply a machine transformation of the source (ask any
>> lawyer) and a bug in the source will guarantee a bug in the binary
>> (ask an engineer),
>>
>>>
>>> AOO has both project supported packages, the voted on user convenience binaries. There are also third party packages which project member's produce and "support". Examples are FreeBSD and Solaris.
>>>
>>> I think that AOO should provide a page with a table that lists "Free support".
>>>
>>> Columns might be.
>>> (1) Operating System and Version.
>>> (2) Apache Open Office Version as a link to a download.
>>> (3) Packager - AOO, FreeBSD, Adfinis (sic), etc.
>>> (4) Available free support - forum, ML, etc. (Would we support FreeBSD/Solaris AOO on dev ML?)
>>>
>>> The table could be followed by a description about what support means as you describe below plus some indication about how to get on the list which should include a vetting procedure and a project VOTE.
>>>
>>
>> I'd rather avoid using the word "support" in different senses, if we
>> can avoid it. Ideally we'd use a different term to describe avenues
>> that FreeBSD users might have for getting help than the term we use
>> the describe what platforms we tested and qualified before voting on a
>> release. Maybe the term "support" is irreparably generic and we need
>> to use a different term for the specific thing we state about our
>> releases and what configurations have been tested?
>>
>> -Rob
>>
>>> Regards,
>>> Dave
>>>
>>> [1] http://subversion.apache.org/packages.html
>>>
>>>
>>> On Jan 1, 2013, at 8:59 AM, Rob Weir wrote:
>>>
>>>> When a commercial software vendor says a configuration is "supported"
>>>> it means something, typically that to the extent the software license
>>>> includes an entitlement to support, that the vendor will provide that
>>>> service for that configuration. So saying something is "supported" is
>>>> essentially an obligation.
>>>>
>>>> With a volunteer-run, open source project, "supported" cannot mean
>>>> quite the same thing. We're not obligated, in any contractual sense,
>>>> to provide anyone with anything. That's the nature of a volunteer
>>>> effort.
>>>>
>>>> However, users and organizations considering OpenOffice will naturally
>>>> think in terms of "support", even if they user that term loosely. We
>>>> use that term as well, in our release notes, etc. But I think we
>>>> ought to have a more precise definition of what we mean when we say
>>>> something is "supported", in order to avoid any confusion. This
>>>> question has come up recently, with regards to the status of Windows
>>>> 8, where that OS had not been released at the time AOO 3.4.1 was
>>>> released.
>>>>
>>>> So here's a strawman proposal for what "supported" means for us.
>>>>
>>>> 1) "Supported" is a statement we make about a specific version of AOO
>>>> used with a specific platform, e.g., AOO 3.4.1 with Windows XP SP3 or
>>>> AOO 3.4 with Ubuntu 12.04 LTS.
>>>>
>>>> 2) "Supported" means we encourage use of AOO in that configuration.
>>>> We have high confidence that the combination is stable, that it works
>>>> well and is safe.
>>>>
>>>> 3) Our confidence in stating something is supported should have a
>>>> solid basis in testing. Something is not "supported" by us guessing
>>>> it should work. It is supported only after we have successfully
>>>> completed testing of that release with that platform. We probably
>>>> should define exactly what level of testing is required.
>>>>
>>>> 4) "Supported" also implies that the supported configuration is
>>>> sufficiently available and there is sufficient expertise that we have
>>>> confidence that users will have a high quality experience seeking
>>>> support on the forums and user list.
>>>>
>>>> 5) "Supported" also implies that we stand behind that release and will
>>>> take necessary steps to correct *critical* bugs, especially security
>>>> flaws, via rapidly produced point releases where necessary.
>>>>
>>>> Note that these are all expectations that a user might have, though
>>>> any given user might think that "supported" means only a subset of
>>>> these.
>>>>
>>>> What we probably really need is more of a lifecycle statement,
>>>> including when support for a configuration ends.
>>>>
>>>> -Rob
>>>
>
>
>
> --
> Cheers,
>
> Ian C
--
====
This e- mail message is intended only for the named recipient(s) above. It
may contain confidential and privileged information. If you are not the
intended recipient you are hereby notified that any dissemination,
distribution or copying of this e-mail and any attachment(s) is strictly
prohibited. If you have received this e-mail in error, please immediately
notify the sender by replying to this e-mail and delete the message and any
attachment(s) from your system. Thank you.
Re: What does "supported" mean for us?
Posted by Ian C <ia...@amham.net>.
A corollary to this is also the notion of End of Life, or when is a
release no longer "supported".
In a volunteer framework that may be never, someone may always be
fiddling with an older version?
Are older releases archived forever?
When do we say "Sorry that will not be fixed, please upgrade to a
newer version that already addressees the issue"?
I wrestle with this in a commercial environment all the time.
Sometimes upgrading is a time consuming task and one in which the user
needs to the have confidence in the product to do it.
Just thinking out loud.
Best wishes for the New Year to one and all....
On Wed, Jan 2, 2013 at 2:43 AM, Rob Weir <ro...@apache.org> wrote:
> On Tue, Jan 1, 2013 at 1:03 PM, Dave Fisher <da...@comcast.net> wrote:
>> HI Rob,
>>
>> I like your emphasis here on "Supported". Let's discuss support in terms of actual process and precisely what are official releases vs. user convenience releases. Both of which are VOTED, but only the source code release can be completely vetted by all of the project. The convenience binaries are well tested and approved. These are what you are discussing when you describe "Supported" below.
>>
>
> Even when we release source code it is relevant what platforms and
> configurations have been tested and which ones we say we support.
> Remember, we're not releasing a literary work, source code to be
> printed on paper and read for enjoyment. It is source code that's
> only practical use is to be compiled into binaries that must of
> necessity run on an operating system. So platform support is equally
> relevant for both source and binary distributions. To support one is
> to support another. For example, if we say we support Windows XP,
> then we must maintain a building guide and be prepared to answer
> questions from those who want to build binaries that work on that
> platform. So there a parallel support and maintenance obligation for
> the source distributions as well.
>
>
>> So when the project votes to release a user convenience binary we are voting to support that configuration. This can change at any release.
>>
>
> In most cases this would happen simultaneously with the release of the
> source distribution. But there may be cases where testing of a
> platform only completes at a latter point and we indicate it is
> supported then. This might not require a release of any new source or
> binary. Windows 8 might be a good example here. It was released
> after AOO 3.4.1 came out. If we tested it now and found it worked
> fine, then we would simply update the release notes to reflect this.
> No formal vote required. Lazy consensus should be enough, I think.
>
>> Packages are built by project members using the buildbot or on personal equipment.
>>
>> Let's look at Apache Subversion's packages [1]. The project only produces source code and the binary packages are the responsibility of third parties.
>
> So does Subversion release purely based on reviewing source code? Or
> does their community test binaries on particular platforms? Of course
> they do. Their release notes are filled with observations on what
> configurations work and which do not:
> http://subversion.apache.org/docs/release-notes/1.7
>
> That's the nature of cross-platform C++ code. IMHO, what platforms
> are supported is unrelated to the source versus binary question. The
> binary is simply a machine transformation of the source (ask any
> lawyer) and a bug in the source will guarantee a bug in the binary
> (ask an engineer),
>
>>
>> AOO has both project supported packages, the voted on user convenience binaries. There are also third party packages which project member's produce and "support". Examples are FreeBSD and Solaris.
>>
>> I think that AOO should provide a page with a table that lists "Free support".
>>
>> Columns might be.
>> (1) Operating System and Version.
>> (2) Apache Open Office Version as a link to a download.
>> (3) Packager - AOO, FreeBSD, Adfinis (sic), etc.
>> (4) Available free support - forum, ML, etc. (Would we support FreeBSD/Solaris AOO on dev ML?)
>>
>> The table could be followed by a description about what support means as you describe below plus some indication about how to get on the list which should include a vetting procedure and a project VOTE.
>>
>
> I'd rather avoid using the word "support" in different senses, if we
> can avoid it. Ideally we'd use a different term to describe avenues
> that FreeBSD users might have for getting help than the term we use
> the describe what platforms we tested and qualified before voting on a
> release. Maybe the term "support" is irreparably generic and we need
> to use a different term for the specific thing we state about our
> releases and what configurations have been tested?
>
> -Rob
>
>> Regards,
>> Dave
>>
>> [1] http://subversion.apache.org/packages.html
>>
>>
>> On Jan 1, 2013, at 8:59 AM, Rob Weir wrote:
>>
>>> When a commercial software vendor says a configuration is "supported"
>>> it means something, typically that to the extent the software license
>>> includes an entitlement to support, that the vendor will provide that
>>> service for that configuration. So saying something is "supported" is
>>> essentially an obligation.
>>>
>>> With a volunteer-run, open source project, "supported" cannot mean
>>> quite the same thing. We're not obligated, in any contractual sense,
>>> to provide anyone with anything. That's the nature of a volunteer
>>> effort.
>>>
>>> However, users and organizations considering OpenOffice will naturally
>>> think in terms of "support", even if they user that term loosely. We
>>> use that term as well, in our release notes, etc. But I think we
>>> ought to have a more precise definition of what we mean when we say
>>> something is "supported", in order to avoid any confusion. This
>>> question has come up recently, with regards to the status of Windows
>>> 8, where that OS had not been released at the time AOO 3.4.1 was
>>> released.
>>>
>>> So here's a strawman proposal for what "supported" means for us.
>>>
>>> 1) "Supported" is a statement we make about a specific version of AOO
>>> used with a specific platform, e.g., AOO 3.4.1 with Windows XP SP3 or
>>> AOO 3.4 with Ubuntu 12.04 LTS.
>>>
>>> 2) "Supported" means we encourage use of AOO in that configuration.
>>> We have high confidence that the combination is stable, that it works
>>> well and is safe.
>>>
>>> 3) Our confidence in stating something is supported should have a
>>> solid basis in testing. Something is not "supported" by us guessing
>>> it should work. It is supported only after we have successfully
>>> completed testing of that release with that platform. We probably
>>> should define exactly what level of testing is required.
>>>
>>> 4) "Supported" also implies that the supported configuration is
>>> sufficiently available and there is sufficient expertise that we have
>>> confidence that users will have a high quality experience seeking
>>> support on the forums and user list.
>>>
>>> 5) "Supported" also implies that we stand behind that release and will
>>> take necessary steps to correct *critical* bugs, especially security
>>> flaws, via rapidly produced point releases where necessary.
>>>
>>> Note that these are all expectations that a user might have, though
>>> any given user might think that "supported" means only a subset of
>>> these.
>>>
>>> What we probably really need is more of a lifecycle statement,
>>> including when support for a configuration ends.
>>>
>>> -Rob
>>
--
Cheers,
Ian C
Re: What does "supported" mean for us?
Posted by Rob Weir <ro...@apache.org>.
On Tue, Jan 1, 2013 at 1:03 PM, Dave Fisher <da...@comcast.net> wrote:
> HI Rob,
>
> I like your emphasis here on "Supported". Let's discuss support in terms of actual process and precisely what are official releases vs. user convenience releases. Both of which are VOTED, but only the source code release can be completely vetted by all of the project. The convenience binaries are well tested and approved. These are what you are discussing when you describe "Supported" below.
>
Even when we release source code it is relevant what platforms and
configurations have been tested and which ones we say we support.
Remember, we're not releasing a literary work, source code to be
printed on paper and read for enjoyment. It is source code that's
only practical use is to be compiled into binaries that must of
necessity run on an operating system. So platform support is equally
relevant for both source and binary distributions. To support one is
to support another. For example, if we say we support Windows XP,
then we must maintain a building guide and be prepared to answer
questions from those who want to build binaries that work on that
platform. So there a parallel support and maintenance obligation for
the source distributions as well.
> So when the project votes to release a user convenience binary we are voting to support that configuration. This can change at any release.
>
In most cases this would happen simultaneously with the release of the
source distribution. But there may be cases where testing of a
platform only completes at a latter point and we indicate it is
supported then. This might not require a release of any new source or
binary. Windows 8 might be a good example here. It was released
after AOO 3.4.1 came out. If we tested it now and found it worked
fine, then we would simply update the release notes to reflect this.
No formal vote required. Lazy consensus should be enough, I think.
> Packages are built by project members using the buildbot or on personal equipment.
>
> Let's look at Apache Subversion's packages [1]. The project only produces source code and the binary packages are the responsibility of third parties.
So does Subversion release purely based on reviewing source code? Or
does their community test binaries on particular platforms? Of course
they do. Their release notes are filled with observations on what
configurations work and which do not:
http://subversion.apache.org/docs/release-notes/1.7
That's the nature of cross-platform C++ code. IMHO, what platforms
are supported is unrelated to the source versus binary question. The
binary is simply a machine transformation of the source (ask any
lawyer) and a bug in the source will guarantee a bug in the binary
(ask an engineer),
>
> AOO has both project supported packages, the voted on user convenience binaries. There are also third party packages which project member's produce and "support". Examples are FreeBSD and Solaris.
>
> I think that AOO should provide a page with a table that lists "Free support".
>
> Columns might be.
> (1) Operating System and Version.
> (2) Apache Open Office Version as a link to a download.
> (3) Packager - AOO, FreeBSD, Adfinis (sic), etc.
> (4) Available free support - forum, ML, etc. (Would we support FreeBSD/Solaris AOO on dev ML?)
>
> The table could be followed by a description about what support means as you describe below plus some indication about how to get on the list which should include a vetting procedure and a project VOTE.
>
I'd rather avoid using the word "support" in different senses, if we
can avoid it. Ideally we'd use a different term to describe avenues
that FreeBSD users might have for getting help than the term we use
the describe what platforms we tested and qualified before voting on a
release. Maybe the term "support" is irreparably generic and we need
to use a different term for the specific thing we state about our
releases and what configurations have been tested?
-Rob
> Regards,
> Dave
>
> [1] http://subversion.apache.org/packages.html
>
>
> On Jan 1, 2013, at 8:59 AM, Rob Weir wrote:
>
>> When a commercial software vendor says a configuration is "supported"
>> it means something, typically that to the extent the software license
>> includes an entitlement to support, that the vendor will provide that
>> service for that configuration. So saying something is "supported" is
>> essentially an obligation.
>>
>> With a volunteer-run, open source project, "supported" cannot mean
>> quite the same thing. We're not obligated, in any contractual sense,
>> to provide anyone with anything. That's the nature of a volunteer
>> effort.
>>
>> However, users and organizations considering OpenOffice will naturally
>> think in terms of "support", even if they user that term loosely. We
>> use that term as well, in our release notes, etc. But I think we
>> ought to have a more precise definition of what we mean when we say
>> something is "supported", in order to avoid any confusion. This
>> question has come up recently, with regards to the status of Windows
>> 8, where that OS had not been released at the time AOO 3.4.1 was
>> released.
>>
>> So here's a strawman proposal for what "supported" means for us.
>>
>> 1) "Supported" is a statement we make about a specific version of AOO
>> used with a specific platform, e.g., AOO 3.4.1 with Windows XP SP3 or
>> AOO 3.4 with Ubuntu 12.04 LTS.
>>
>> 2) "Supported" means we encourage use of AOO in that configuration.
>> We have high confidence that the combination is stable, that it works
>> well and is safe.
>>
>> 3) Our confidence in stating something is supported should have a
>> solid basis in testing. Something is not "supported" by us guessing
>> it should work. It is supported only after we have successfully
>> completed testing of that release with that platform. We probably
>> should define exactly what level of testing is required.
>>
>> 4) "Supported" also implies that the supported configuration is
>> sufficiently available and there is sufficient expertise that we have
>> confidence that users will have a high quality experience seeking
>> support on the forums and user list.
>>
>> 5) "Supported" also implies that we stand behind that release and will
>> take necessary steps to correct *critical* bugs, especially security
>> flaws, via rapidly produced point releases where necessary.
>>
>> Note that these are all expectations that a user might have, though
>> any given user might think that "supported" means only a subset of
>> these.
>>
>> What we probably really need is more of a lifecycle statement,
>> including when support for a configuration ends.
>>
>> -Rob
>
Re: What does "supported" mean for us?
Posted by Dave Fisher <da...@comcast.net>.
HI Rob,
I like your emphasis here on "Supported". Let's discuss support in terms of actual process and precisely what are official releases vs. user convenience releases. Both of which are VOTED, but only the source code release can be completely vetted by all of the project. The convenience binaries are well tested and approved. These are what you are discussing when you describe "Supported" below.
So when the project votes to release a user convenience binary we are voting to support that configuration. This can change at any release.
Packages are built by project members using the buildbot or on personal equipment.
Let's look at Apache Subversion's packages [1]. The project only produces source code and the binary packages are the responsibility of third parties.
AOO has both project supported packages, the voted on user convenience binaries. There are also third party packages which project member's produce and "support". Examples are FreeBSD and Solaris.
I think that AOO should provide a page with a table that lists "Free support".
Columns might be.
(1) Operating System and Version.
(2) Apache Open Office Version as a link to a download.
(3) Packager - AOO, FreeBSD, Adfinis (sic), etc.
(4) Available free support - forum, ML, etc. (Would we support FreeBSD/Solaris AOO on dev ML?)
The table could be followed by a description about what support means as you describe below plus some indication about how to get on the list which should include a vetting procedure and a project VOTE.
Regards,
Dave
[1] http://subversion.apache.org/packages.html
On Jan 1, 2013, at 8:59 AM, Rob Weir wrote:
> When a commercial software vendor says a configuration is "supported"
> it means something, typically that to the extent the software license
> includes an entitlement to support, that the vendor will provide that
> service for that configuration. So saying something is "supported" is
> essentially an obligation.
>
> With a volunteer-run, open source project, "supported" cannot mean
> quite the same thing. We're not obligated, in any contractual sense,
> to provide anyone with anything. That's the nature of a volunteer
> effort.
>
> However, users and organizations considering OpenOffice will naturally
> think in terms of "support", even if they user that term loosely. We
> use that term as well, in our release notes, etc. But I think we
> ought to have a more precise definition of what we mean when we say
> something is "supported", in order to avoid any confusion. This
> question has come up recently, with regards to the status of Windows
> 8, where that OS had not been released at the time AOO 3.4.1 was
> released.
>
> So here's a strawman proposal for what "supported" means for us.
>
> 1) "Supported" is a statement we make about a specific version of AOO
> used with a specific platform, e.g., AOO 3.4.1 with Windows XP SP3 or
> AOO 3.4 with Ubuntu 12.04 LTS.
>
> 2) "Supported" means we encourage use of AOO in that configuration.
> We have high confidence that the combination is stable, that it works
> well and is safe.
>
> 3) Our confidence in stating something is supported should have a
> solid basis in testing. Something is not "supported" by us guessing
> it should work. It is supported only after we have successfully
> completed testing of that release with that platform. We probably
> should define exactly what level of testing is required.
>
> 4) "Supported" also implies that the supported configuration is
> sufficiently available and there is sufficient expertise that we have
> confidence that users will have a high quality experience seeking
> support on the forums and user list.
>
> 5) "Supported" also implies that we stand behind that release and will
> take necessary steps to correct *critical* bugs, especially security
> flaws, via rapidly produced point releases where necessary.
>
> Note that these are all expectations that a user might have, though
> any given user might think that "supported" means only a subset of
> these.
>
> What we probably really need is more of a lifecycle statement,
> including when support for a configuration ends.
>
> -Rob
Re: What does "supported" mean for us?
Posted by janI <ja...@apache.org>.
On 7 January 2013 21:15, Rob Weir <ro...@apache.org> wrote:
> On Tue, Jan 1, 2013 at 11:59 AM, Rob Weir <ro...@apache.org> wrote:
> > When a commercial software vendor says a configuration is "supported"
> > it means something, typically that to the extent the software license
> > includes an entitlement to support, that the vendor will provide that
> > service for that configuration. So saying something is "supported" is
> > essentially an obligation.
> >
> > With a volunteer-run, open source project, "supported" cannot mean
> > quite the same thing. We're not obligated, in any contractual sense,
> > to provide anyone with anything. That's the nature of a volunteer
> > effort.
> >
>
> For comparison, I came across this page for GNU Octave, where it
> defines "Support Expectations":
> http://www.gnu.org/software/octave/support-expectations.html
>
> Maybe that is a good way to think of it, defining expectations?
>
That is much better than "support", it goes well with what the users think
and does not make the link support = obligation.
The page you refer to it well written, but in my opinion, talks to much
about donations and does not concentrate on the issue..
-Rob
>
> > However, users and organizations considering OpenOffice will naturally
> > think in terms of "support", even if they user that term loosely. We
> > use that term as well, in our release notes, etc. But I think we
> > ought to have a more precise definition of what we mean when we say
> > something is "supported", in order to avoid any confusion. This
> > question has come up recently, with regards to the status of Windows
> > 8, where that OS had not been released at the time AOO 3.4.1 was
> > released.
> >
> > So here's a strawman proposal for what "supported" means for us.
> >
> > 1) "Supported" is a statement we make about a specific version of AOO
> > used with a specific platform, e.g., AOO 3.4.1 with Windows XP SP3 or
> > AOO 3.4 with Ubuntu 12.04 LTS.
> >
> > 2) "Supported" means we encourage use of AOO in that configuration.
> > We have high confidence that the combination is stable, that it works
> > well and is safe.
> >
> > 3) Our confidence in stating something is supported should have a
> > solid basis in testing. Something is not "supported" by us guessing
> > it should work. It is supported only after we have successfully
> > completed testing of that release with that platform. We probably
> > should define exactly what level of testing is required.
> >
> > 4) "Supported" also implies that the supported configuration is
> > sufficiently available and there is sufficient expertise that we have
> > confidence that users will have a high quality experience seeking
> > support on the forums and user list.
> >
> > 5) "Supported" also implies that we stand behind that release and will
> > take necessary steps to correct *critical* bugs, especially security
> > flaws, via rapidly produced point releases where necessary.
> >
> > Note that these are all expectations that a user might have, though
> > any given user might think that "supported" means only a subset of
> > these.
> >
> > What we probably really need is more of a lifecycle statement,
> > including when support for a configuration ends.
> >
> > -Rob
>
Re: What does "supported" mean for us?
Posted by Rob Weir <ro...@apache.org>.
On Mon, Jan 7, 2013 at 3:25 PM, Donald Whytock <dw...@gmail.com> wrote:
> Coming into this way late, but...
>
> Perhaps you shouldn't even use the word "supported". How about
> "validated"? As in, "We can say that we tested this software under
> this environment, and it worked for us. We will be receptive of
> reports to the contrary." "We have developed for and validated on the
> following platforms..."
>
We could use another word, certainly, but users will still ask if X is
"supported", so we cannot escape the term entirely.
-Rob
> Don
>
> On Mon, Jan 7, 2013 at 3:15 PM, Rob Weir <ro...@apache.org> wrote:
>> On Tue, Jan 1, 2013 at 11:59 AM, Rob Weir <ro...@apache.org> wrote:
>>> When a commercial software vendor says a configuration is "supported"
>>> it means something, typically that to the extent the software license
>>> includes an entitlement to support, that the vendor will provide that
>>> service for that configuration. So saying something is "supported" is
>>> essentially an obligation.
>>>
>>> With a volunteer-run, open source project, "supported" cannot mean
>>> quite the same thing. We're not obligated, in any contractual sense,
>>> to provide anyone with anything. That's the nature of a volunteer
>>> effort.
>>>
>>
>> For comparison, I came across this page for GNU Octave, where it
>> defines "Support Expectations":
>> http://www.gnu.org/software/octave/support-expectations.html
>>
>> Maybe that is a good way to think of it, defining expectations?
>>
>> -Rob
>>
>>> However, users and organizations considering OpenOffice will naturally
>>> think in terms of "support", even if they user that term loosely. We
>>> use that term as well, in our release notes, etc. But I think we
>>> ought to have a more precise definition of what we mean when we say
>>> something is "supported", in order to avoid any confusion. This
>>> question has come up recently, with regards to the status of Windows
>>> 8, where that OS had not been released at the time AOO 3.4.1 was
>>> released.
>>>
>>> So here's a strawman proposal for what "supported" means for us.
>>>
>>> 1) "Supported" is a statement we make about a specific version of AOO
>>> used with a specific platform, e.g., AOO 3.4.1 with Windows XP SP3 or
>>> AOO 3.4 with Ubuntu 12.04 LTS.
>>>
>>> 2) "Supported" means we encourage use of AOO in that configuration.
>>> We have high confidence that the combination is stable, that it works
>>> well and is safe.
>>>
>>> 3) Our confidence in stating something is supported should have a
>>> solid basis in testing. Something is not "supported" by us guessing
>>> it should work. It is supported only after we have successfully
>>> completed testing of that release with that platform. We probably
>>> should define exactly what level of testing is required.
>>>
>>> 4) "Supported" also implies that the supported configuration is
>>> sufficiently available and there is sufficient expertise that we have
>>> confidence that users will have a high quality experience seeking
>>> support on the forums and user list.
>>>
>>> 5) "Supported" also implies that we stand behind that release and will
>>> take necessary steps to correct *critical* bugs, especially security
>>> flaws, via rapidly produced point releases where necessary.
>>>
>>> Note that these are all expectations that a user might have, though
>>> any given user might think that "supported" means only a subset of
>>> these.
>>>
>>> What we probably really need is more of a lifecycle statement,
>>> including when support for a configuration ends.
>>>
>>> -Rob
Re: What does "supported" mean for us?
Posted by Donald Whytock <dw...@gmail.com>.
Coming into this way late, but...
Perhaps you shouldn't even use the word "supported". How about
"validated"? As in, "We can say that we tested this software under
this environment, and it worked for us. We will be receptive of
reports to the contrary." "We have developed for and validated on the
following platforms..."
Don
On Mon, Jan 7, 2013 at 3:15 PM, Rob Weir <ro...@apache.org> wrote:
> On Tue, Jan 1, 2013 at 11:59 AM, Rob Weir <ro...@apache.org> wrote:
>> When a commercial software vendor says a configuration is "supported"
>> it means something, typically that to the extent the software license
>> includes an entitlement to support, that the vendor will provide that
>> service for that configuration. So saying something is "supported" is
>> essentially an obligation.
>>
>> With a volunteer-run, open source project, "supported" cannot mean
>> quite the same thing. We're not obligated, in any contractual sense,
>> to provide anyone with anything. That's the nature of a volunteer
>> effort.
>>
>
> For comparison, I came across this page for GNU Octave, where it
> defines "Support Expectations":
> http://www.gnu.org/software/octave/support-expectations.html
>
> Maybe that is a good way to think of it, defining expectations?
>
> -Rob
>
>> However, users and organizations considering OpenOffice will naturally
>> think in terms of "support", even if they user that term loosely. We
>> use that term as well, in our release notes, etc. But I think we
>> ought to have a more precise definition of what we mean when we say
>> something is "supported", in order to avoid any confusion. This
>> question has come up recently, with regards to the status of Windows
>> 8, where that OS had not been released at the time AOO 3.4.1 was
>> released.
>>
>> So here's a strawman proposal for what "supported" means for us.
>>
>> 1) "Supported" is a statement we make about a specific version of AOO
>> used with a specific platform, e.g., AOO 3.4.1 with Windows XP SP3 or
>> AOO 3.4 with Ubuntu 12.04 LTS.
>>
>> 2) "Supported" means we encourage use of AOO in that configuration.
>> We have high confidence that the combination is stable, that it works
>> well and is safe.
>>
>> 3) Our confidence in stating something is supported should have a
>> solid basis in testing. Something is not "supported" by us guessing
>> it should work. It is supported only after we have successfully
>> completed testing of that release with that platform. We probably
>> should define exactly what level of testing is required.
>>
>> 4) "Supported" also implies that the supported configuration is
>> sufficiently available and there is sufficient expertise that we have
>> confidence that users will have a high quality experience seeking
>> support on the forums and user list.
>>
>> 5) "Supported" also implies that we stand behind that release and will
>> take necessary steps to correct *critical* bugs, especially security
>> flaws, via rapidly produced point releases where necessary.
>>
>> Note that these are all expectations that a user might have, though
>> any given user might think that "supported" means only a subset of
>> these.
>>
>> What we probably really need is more of a lifecycle statement,
>> including when support for a configuration ends.
>>
>> -Rob
Re: What does "supported" mean for us?
Posted by Rob Weir <ro...@apache.org>.
On Tue, Jan 1, 2013 at 11:59 AM, Rob Weir <ro...@apache.org> wrote:
> When a commercial software vendor says a configuration is "supported"
> it means something, typically that to the extent the software license
> includes an entitlement to support, that the vendor will provide that
> service for that configuration. So saying something is "supported" is
> essentially an obligation.
>
> With a volunteer-run, open source project, "supported" cannot mean
> quite the same thing. We're not obligated, in any contractual sense,
> to provide anyone with anything. That's the nature of a volunteer
> effort.
>
For comparison, I came across this page for GNU Octave, where it
defines "Support Expectations":
http://www.gnu.org/software/octave/support-expectations.html
Maybe that is a good way to think of it, defining expectations?
-Rob
> However, users and organizations considering OpenOffice will naturally
> think in terms of "support", even if they user that term loosely. We
> use that term as well, in our release notes, etc. But I think we
> ought to have a more precise definition of what we mean when we say
> something is "supported", in order to avoid any confusion. This
> question has come up recently, with regards to the status of Windows
> 8, where that OS had not been released at the time AOO 3.4.1 was
> released.
>
> So here's a strawman proposal for what "supported" means for us.
>
> 1) "Supported" is a statement we make about a specific version of AOO
> used with a specific platform, e.g., AOO 3.4.1 with Windows XP SP3 or
> AOO 3.4 with Ubuntu 12.04 LTS.
>
> 2) "Supported" means we encourage use of AOO in that configuration.
> We have high confidence that the combination is stable, that it works
> well and is safe.
>
> 3) Our confidence in stating something is supported should have a
> solid basis in testing. Something is not "supported" by us guessing
> it should work. It is supported only after we have successfully
> completed testing of that release with that platform. We probably
> should define exactly what level of testing is required.
>
> 4) "Supported" also implies that the supported configuration is
> sufficiently available and there is sufficient expertise that we have
> confidence that users will have a high quality experience seeking
> support on the forums and user list.
>
> 5) "Supported" also implies that we stand behind that release and will
> take necessary steps to correct *critical* bugs, especially security
> flaws, via rapidly produced point releases where necessary.
>
> Note that these are all expectations that a user might have, though
> any given user might think that "supported" means only a subset of
> these.
>
> What we probably really need is more of a lifecycle statement,
> including when support for a configuration ends.
>
> -Rob
Re: What does "supported" mean for us?
Posted by Rory O'Farrell <of...@iol.ie>.
On Tue, 1 Jan 2013 18:06:38 +0100
janI <ja...@apache.org> wrote:
> +1 to your definition of "supported", it is funny I just had somewhat the
> same discussion today.
>
> Regarding lifecycle, I would like to suggest that we only support the
> latest release, otherwise we stretch our resources pretty thin. We can of
> course have a statement that we in general will have a look at critical
> bugs, but they will only be solved in the latest release.
>
> rgds
> Jan I.
>
>
> On 1 January 2013 17:59, Rob Weir <ro...@apache.org> wrote:
>
> > When a commercial software vendor says a configuration is "supported"
> > it means something, typically that to the extent the software license
> > includes an entitlement to support, that the vendor will provide that
> > service for that configuration. So saying something is "supported" is
> > essentially an obligation.
> >
> > With a volunteer-run, open source project, "supported" cannot mean
> > quite the same thing. We're not obligated, in any contractual sense,
> > to provide anyone with anything. That's the nature of a volunteer
> > effort.
> >
> > However, users and organizations considering OpenOffice will naturally
> > think in terms of "support", even if they user that term loosely. We
> > use that term as well, in our release notes, etc. But I think we
> > ought to have a more precise definition of what we mean when we say
> > something is "supported", in order to avoid any confusion. This
> > question has come up recently, with regards to the status of Windows
> > 8, where that OS had not been released at the time AOO 3.4.1 was
> > released.
> >
> > So here's a strawman proposal for what "supported" means for us.
> >
> > 1) "Supported" is a statement we make about a specific version of AOO
> > used with a specific platform, e.g., AOO 3.4.1 with Windows XP SP3 or
> > AOO 3.4 with Ubuntu 12.04 LTS.
> >
> > 2) "Supported" means we encourage use of AOO in that configuration.
> > We have high confidence that the combination is stable, that it works
> > well and is safe.
> >
> > 3) Our confidence in stating something is supported should have a
> > solid basis in testing. Something is not "supported" by us guessing
> > it should work. It is supported only after we have successfully
> > completed testing of that release with that platform. We probably
> > should define exactly what level of testing is required.
> >
> > 4) "Supported" also implies that the supported configuration is
> > sufficiently available and there is sufficient expertise that we have
> > confidence that users will have a high quality experience seeking
> > support on the forums and user list.
> >
> > 5) "Supported" also implies that we stand behind that release and will
> > take necessary steps to correct *critical* bugs, especially security
> > flaws, via rapidly produced point releases where necessary.
> >
> > Note that these are all expectations that a user might have, though
> > any given user might think that "supported" means only a subset of
> > these.
> >
> > What we probably really need is more of a lifecycle statement,
> > including when support for a configuration ends.
> >
> > -Rob
> >
Supported should mean also that it works with an "out of the box" install of the "supported" operating system.
We must remember that the average user is relatively unskilled in computer knowledge and terminology; they want to press the button of the install package and have it install a working OpenOffice without intervention on their part.
Such behaviour also as a good spin-off in terms of less User support being needed; lurking on the Forum one will quickly see that many awkward support cases are caused by insufficient computer knowledge of the users, as also by attempts on their part to out-guess the install process.
--
Rory O'Farrell <of...@iol.ie>
Re: What does "supported" mean for us?
Posted by Joost Andrae <Jo...@gmx.de>.
Hi,
> So is Vista supported? It certainly isn't deprecated. But neither
> is it getting the full QA treatment. Similar questions for Linux
> releases. We don't test every release of every distro. We pick the
> major ones, such as the Ubuntu LTS releases.
>
on Vista I would be surprised if AOO won't run on it.
On Linux if AOO picks a defined version of a Linux distro as a
'supported' one then this would be the wrong decision. 'Supporting' has
to be seen in a more technical manner not from the 'commercial support'
POV. In the past OOo was built by using a build infrastructure that
allowed OOo to run the binary on most of the Linux distributions. There
were just a few distros that failed because they were incompatible to
everything else.
Platform compatibility depends on some prerequisites (just some examples):
glibc versions supported
system dependent system integration (eg. on KDE, Gnome, etc.)
drag&drop support
clipboard support
sane support on that platform
java dependencies on that platform (eg. Sun Java version, OpenSource
derivates)
The more important question is: Is AOO a LSB compatible application ?
Kind regards, Joost
Re: What does "supported" mean for us?
Posted by janI <ja...@apache.org>.
On 1 January 2013 19:03, Rob Weir <ro...@apache.org> wrote:
> On Tue, Jan 1, 2013 at 12:58 PM, janI <ja...@apache.org> wrote:
> > On 1 January 2013 18:50, Rob Weir <ro...@apache.org> wrote:
> >
> >> On Tue, Jan 1, 2013 at 12:06 PM, janI <ja...@apache.org> wrote:
> >> > +1 to your definition of "supported", it is funny I just had somewhat
> the
> >> > same discussion today.
> >> >
> >> > Regarding lifecycle, I would like to suggest that we only support the
> >> > latest release, otherwise we stretch our resources pretty thin. We
> can
> >> of
> >> > course have a statement that we in general will have a look at
> critical
> >> > bugs, but they will only be solved in the latest release.
> >> >
> >>
> >> And thinking a little further, there might be something between
> >> "supported" and "deprecated", or at least there might be different
> >> levels of confidence we might have.
> >>
> >> For example, I don't think we're doing any testing with Widows Vista.
> >> We tested Windows XP, 7 and preview version of 8. We have limited
> >> resources.
> >>
> >> So is Vista supported? It certainly isn't deprecated. But neither
> >> is it getting the full QA treatment. Similar questions for Linux
> >> releases. We don't test every release of every distro. We pick the
> >> major ones, such as the Ubuntu LTS releases.
> >>
> >> One way of handling this could be:
> >>
> >> 1) Define our "Class A" platforms, the ones that we give the full test
> >> attention to. Similar to how we treat translations, this list can
> >> grow given sufficient volunteers to cover the testing, and (if bugs
> >> are found) the fixes.
> >>
> >> 2) Class A platforms (or "primary platforms" or "tested platforms" or
> >> "supported platforms" -- whatever we call them) are the ones we
> >> encourage users to use.
> >>
> >> 3) For other platforms we make a wiki-page per platform, were we can
> >> track notes from users on an unique issues they find on that platform.
> >> These combinations are not supported, but may often work. But we
> >> make it easy to collect observations about AOO on that platform, and
> >> make it easy for users to find that info.
> >>
> >> If we do this, then our support statement could read something like:
> >> "We have tested and qualified Apache OpenOffice X.Y on the following
> >> operating system versions. Other operating system versions may work
> >> as well, but may require additional configuration. For the latest
> >> information please consult the following wiki page..."
> >>
> >> -Rob
> >>
> >> I do not know this, but would it be possible to make a QA package
> (script
> > or something) that would make it easy for skilled users to do QA of a
> > platform (e.g. vista). I have f.x. vista running and could do it, but I
> do
> > not have a clue what should be done, and there could be other users like
> me
> > out there.
> >
>
> We have some automation, but not enough to fully test a release. It is
> more at the level of checking a build to make sure it did not have
> gross defects, so more of a "smoke test". Most of the testing is
> manual. So if we had a model where a set of volunteers wanted to bump
> a new platform up to a "fully supported" platform, then we would have
> a set of automated and manual tests that the volunteers would need to
> run.
>
Do we need a full release test to make sure a platform works, isnt it more
a "feature" test ? I might be wrong but to me there is a difference whether
we test if our code works, or if already tested code works on a new
platform, this should be a lot simpler.
Would this not be a great task for some of our new QA people, to make a
minimum test suite automated, that would secure that AOO works on a
platform.
I know it is easy for me to say, without sufficient knowledge, but I think
it would be more than just a neat feature ("run this, to test if your
system works with AOO").
Jan I.
>
> -Rob
>
> > Microsoft have something I think they call certification scripts, that
> > checks if your platform is ok for a given product, could we do something
> > the same, that would be a one-time effort.
> >
> > Jan I.
> >
> >
> >> > rgds
> >> > Jan I.
> >> >
> >> >
> >> > On 1 January 2013 17:59, Rob Weir <ro...@apache.org> wrote:
> >> >
> >> >> When a commercial software vendor says a configuration is "supported"
> >> >> it means something, typically that to the extent the software license
> >> >> includes an entitlement to support, that the vendor will provide that
> >> >> service for that configuration. So saying something is "supported"
> is
> >> >> essentially an obligation.
> >> >>
> >> >> With a volunteer-run, open source project, "supported" cannot mean
> >> >> quite the same thing. We're not obligated, in any contractual
> sense,
> >> >> to provide anyone with anything. That's the nature of a volunteer
> >> >> effort.
> >> >>
> >> >> However, users and organizations considering OpenOffice will
> naturally
> >> >> think in terms of "support", even if they user that term loosely. We
> >> >> use that term as well, in our release notes, etc. But I think we
> >> >> ought to have a more precise definition of what we mean when we say
> >> >> something is "supported", in order to avoid any confusion. This
> >> >> question has come up recently, with regards to the status of Windows
> >> >> 8, where that OS had not been released at the time AOO 3.4.1 was
> >> >> released.
> >> >>
> >> >> So here's a strawman proposal for what "supported" means for us.
> >> >>
> >> >> 1) "Supported" is a statement we make about a specific version of AOO
> >> >> used with a specific platform, e.g., AOO 3.4.1 with Windows XP SP3 or
> >> >> AOO 3.4 with Ubuntu 12.04 LTS.
> >> >>
> >> >> 2) "Supported" means we encourage use of AOO in that configuration.
> >> >> We have high confidence that the combination is stable, that it works
> >> >> well and is safe.
> >> >>
> >> >> 3) Our confidence in stating something is supported should have a
> >> >> solid basis in testing. Something is not "supported" by us guessing
> >> >> it should work. It is supported only after we have successfully
> >> >> completed testing of that release with that platform. We probably
> >> >> should define exactly what level of testing is required.
> >> >>
> >> >> 4) "Supported" also implies that the supported configuration is
> >> >> sufficiently available and there is sufficient expertise that we have
> >> >> confidence that users will have a high quality experience seeking
> >> >> support on the forums and user list.
> >> >>
> >> >> 5) "Supported" also implies that we stand behind that release and
> will
> >> >> take necessary steps to correct *critical* bugs, especially security
> >> >> flaws, via rapidly produced point releases where necessary.
> >> >>
> >> >> Note that these are all expectations that a user might have, though
> >> >> any given user might think that "supported" means only a subset of
> >> >> these.
> >> >>
> >> >> What we probably really need is more of a lifecycle statement,
> >> >> including when support for a configuration ends.
> >> >>
> >> >> -Rob
> >> >>
> >>
>
Re: What does "supported" mean for us?
Posted by Rob Weir <ro...@apache.org>.
On Tue, Jan 1, 2013 at 12:58 PM, janI <ja...@apache.org> wrote:
> On 1 January 2013 18:50, Rob Weir <ro...@apache.org> wrote:
>
>> On Tue, Jan 1, 2013 at 12:06 PM, janI <ja...@apache.org> wrote:
>> > +1 to your definition of "supported", it is funny I just had somewhat the
>> > same discussion today.
>> >
>> > Regarding lifecycle, I would like to suggest that we only support the
>> > latest release, otherwise we stretch our resources pretty thin. We can
>> of
>> > course have a statement that we in general will have a look at critical
>> > bugs, but they will only be solved in the latest release.
>> >
>>
>> And thinking a little further, there might be something between
>> "supported" and "deprecated", or at least there might be different
>> levels of confidence we might have.
>>
>> For example, I don't think we're doing any testing with Widows Vista.
>> We tested Windows XP, 7 and preview version of 8. We have limited
>> resources.
>>
>> So is Vista supported? It certainly isn't deprecated. But neither
>> is it getting the full QA treatment. Similar questions for Linux
>> releases. We don't test every release of every distro. We pick the
>> major ones, such as the Ubuntu LTS releases.
>>
>> One way of handling this could be:
>>
>> 1) Define our "Class A" platforms, the ones that we give the full test
>> attention to. Similar to how we treat translations, this list can
>> grow given sufficient volunteers to cover the testing, and (if bugs
>> are found) the fixes.
>>
>> 2) Class A platforms (or "primary platforms" or "tested platforms" or
>> "supported platforms" -- whatever we call them) are the ones we
>> encourage users to use.
>>
>> 3) For other platforms we make a wiki-page per platform, were we can
>> track notes from users on an unique issues they find on that platform.
>> These combinations are not supported, but may often work. But we
>> make it easy to collect observations about AOO on that platform, and
>> make it easy for users to find that info.
>>
>> If we do this, then our support statement could read something like:
>> "We have tested and qualified Apache OpenOffice X.Y on the following
>> operating system versions. Other operating system versions may work
>> as well, but may require additional configuration. For the latest
>> information please consult the following wiki page..."
>>
>> -Rob
>>
>> I do not know this, but would it be possible to make a QA package (script
> or something) that would make it easy for skilled users to do QA of a
> platform (e.g. vista). I have f.x. vista running and could do it, but I do
> not have a clue what should be done, and there could be other users like me
> out there.
>
We have some automation, but not enough to fully test a release. It is
more at the level of checking a build to make sure it did not have
gross defects, so more of a "smoke test". Most of the testing is
manual. So if we had a model where a set of volunteers wanted to bump
a new platform up to a "fully supported" platform, then we would have
a set of automated and manual tests that the volunteers would need to
run.
-Rob
> Microsoft have something I think they call certification scripts, that
> checks if your platform is ok for a given product, could we do something
> the same, that would be a one-time effort.
>
> Jan I.
>
>
>> > rgds
>> > Jan I.
>> >
>> >
>> > On 1 January 2013 17:59, Rob Weir <ro...@apache.org> wrote:
>> >
>> >> When a commercial software vendor says a configuration is "supported"
>> >> it means something, typically that to the extent the software license
>> >> includes an entitlement to support, that the vendor will provide that
>> >> service for that configuration. So saying something is "supported" is
>> >> essentially an obligation.
>> >>
>> >> With a volunteer-run, open source project, "supported" cannot mean
>> >> quite the same thing. We're not obligated, in any contractual sense,
>> >> to provide anyone with anything. That's the nature of a volunteer
>> >> effort.
>> >>
>> >> However, users and organizations considering OpenOffice will naturally
>> >> think in terms of "support", even if they user that term loosely. We
>> >> use that term as well, in our release notes, etc. But I think we
>> >> ought to have a more precise definition of what we mean when we say
>> >> something is "supported", in order to avoid any confusion. This
>> >> question has come up recently, with regards to the status of Windows
>> >> 8, where that OS had not been released at the time AOO 3.4.1 was
>> >> released.
>> >>
>> >> So here's a strawman proposal for what "supported" means for us.
>> >>
>> >> 1) "Supported" is a statement we make about a specific version of AOO
>> >> used with a specific platform, e.g., AOO 3.4.1 with Windows XP SP3 or
>> >> AOO 3.4 with Ubuntu 12.04 LTS.
>> >>
>> >> 2) "Supported" means we encourage use of AOO in that configuration.
>> >> We have high confidence that the combination is stable, that it works
>> >> well and is safe.
>> >>
>> >> 3) Our confidence in stating something is supported should have a
>> >> solid basis in testing. Something is not "supported" by us guessing
>> >> it should work. It is supported only after we have successfully
>> >> completed testing of that release with that platform. We probably
>> >> should define exactly what level of testing is required.
>> >>
>> >> 4) "Supported" also implies that the supported configuration is
>> >> sufficiently available and there is sufficient expertise that we have
>> >> confidence that users will have a high quality experience seeking
>> >> support on the forums and user list.
>> >>
>> >> 5) "Supported" also implies that we stand behind that release and will
>> >> take necessary steps to correct *critical* bugs, especially security
>> >> flaws, via rapidly produced point releases where necessary.
>> >>
>> >> Note that these are all expectations that a user might have, though
>> >> any given user might think that "supported" means only a subset of
>> >> these.
>> >>
>> >> What we probably really need is more of a lifecycle statement,
>> >> including when support for a configuration ends.
>> >>
>> >> -Rob
>> >>
>>
Re: What does "supported" mean for us?
Posted by janI <ja...@apache.org>.
On 1 January 2013 18:50, Rob Weir <ro...@apache.org> wrote:
> On Tue, Jan 1, 2013 at 12:06 PM, janI <ja...@apache.org> wrote:
> > +1 to your definition of "supported", it is funny I just had somewhat the
> > same discussion today.
> >
> > Regarding lifecycle, I would like to suggest that we only support the
> > latest release, otherwise we stretch our resources pretty thin. We can
> of
> > course have a statement that we in general will have a look at critical
> > bugs, but they will only be solved in the latest release.
> >
>
> And thinking a little further, there might be something between
> "supported" and "deprecated", or at least there might be different
> levels of confidence we might have.
>
> For example, I don't think we're doing any testing with Widows Vista.
> We tested Windows XP, 7 and preview version of 8. We have limited
> resources.
>
> So is Vista supported? It certainly isn't deprecated. But neither
> is it getting the full QA treatment. Similar questions for Linux
> releases. We don't test every release of every distro. We pick the
> major ones, such as the Ubuntu LTS releases.
>
> One way of handling this could be:
>
> 1) Define our "Class A" platforms, the ones that we give the full test
> attention to. Similar to how we treat translations, this list can
> grow given sufficient volunteers to cover the testing, and (if bugs
> are found) the fixes.
>
> 2) Class A platforms (or "primary platforms" or "tested platforms" or
> "supported platforms" -- whatever we call them) are the ones we
> encourage users to use.
>
> 3) For other platforms we make a wiki-page per platform, were we can
> track notes from users on an unique issues they find on that platform.
> These combinations are not supported, but may often work. But we
> make it easy to collect observations about AOO on that platform, and
> make it easy for users to find that info.
>
> If we do this, then our support statement could read something like:
> "We have tested and qualified Apache OpenOffice X.Y on the following
> operating system versions. Other operating system versions may work
> as well, but may require additional configuration. For the latest
> information please consult the following wiki page..."
>
> -Rob
>
> I do not know this, but would it be possible to make a QA package (script
or something) that would make it easy for skilled users to do QA of a
platform (e.g. vista). I have f.x. vista running and could do it, but I do
not have a clue what should be done, and there could be other users like me
out there.
Microsoft have something I think they call certification scripts, that
checks if your platform is ok for a given product, could we do something
the same, that would be a one-time effort.
Jan I.
> > rgds
> > Jan I.
> >
> >
> > On 1 January 2013 17:59, Rob Weir <ro...@apache.org> wrote:
> >
> >> When a commercial software vendor says a configuration is "supported"
> >> it means something, typically that to the extent the software license
> >> includes an entitlement to support, that the vendor will provide that
> >> service for that configuration. So saying something is "supported" is
> >> essentially an obligation.
> >>
> >> With a volunteer-run, open source project, "supported" cannot mean
> >> quite the same thing. We're not obligated, in any contractual sense,
> >> to provide anyone with anything. That's the nature of a volunteer
> >> effort.
> >>
> >> However, users and organizations considering OpenOffice will naturally
> >> think in terms of "support", even if they user that term loosely. We
> >> use that term as well, in our release notes, etc. But I think we
> >> ought to have a more precise definition of what we mean when we say
> >> something is "supported", in order to avoid any confusion. This
> >> question has come up recently, with regards to the status of Windows
> >> 8, where that OS had not been released at the time AOO 3.4.1 was
> >> released.
> >>
> >> So here's a strawman proposal for what "supported" means for us.
> >>
> >> 1) "Supported" is a statement we make about a specific version of AOO
> >> used with a specific platform, e.g., AOO 3.4.1 with Windows XP SP3 or
> >> AOO 3.4 with Ubuntu 12.04 LTS.
> >>
> >> 2) "Supported" means we encourage use of AOO in that configuration.
> >> We have high confidence that the combination is stable, that it works
> >> well and is safe.
> >>
> >> 3) Our confidence in stating something is supported should have a
> >> solid basis in testing. Something is not "supported" by us guessing
> >> it should work. It is supported only after we have successfully
> >> completed testing of that release with that platform. We probably
> >> should define exactly what level of testing is required.
> >>
> >> 4) "Supported" also implies that the supported configuration is
> >> sufficiently available and there is sufficient expertise that we have
> >> confidence that users will have a high quality experience seeking
> >> support on the forums and user list.
> >>
> >> 5) "Supported" also implies that we stand behind that release and will
> >> take necessary steps to correct *critical* bugs, especially security
> >> flaws, via rapidly produced point releases where necessary.
> >>
> >> Note that these are all expectations that a user might have, though
> >> any given user might think that "supported" means only a subset of
> >> these.
> >>
> >> What we probably really need is more of a lifecycle statement,
> >> including when support for a configuration ends.
> >>
> >> -Rob
> >>
>
Re: What does "supported" mean for us?
Posted by Rob Weir <ro...@apache.org>.
On Tue, Jan 1, 2013 at 12:06 PM, janI <ja...@apache.org> wrote:
> +1 to your definition of "supported", it is funny I just had somewhat the
> same discussion today.
>
> Regarding lifecycle, I would like to suggest that we only support the
> latest release, otherwise we stretch our resources pretty thin. We can of
> course have a statement that we in general will have a look at critical
> bugs, but they will only be solved in the latest release.
>
And thinking a little further, there might be something between
"supported" and "deprecated", or at least there might be different
levels of confidence we might have.
For example, I don't think we're doing any testing with Widows Vista.
We tested Windows XP, 7 and preview version of 8. We have limited
resources.
So is Vista supported? It certainly isn't deprecated. But neither
is it getting the full QA treatment. Similar questions for Linux
releases. We don't test every release of every distro. We pick the
major ones, such as the Ubuntu LTS releases.
One way of handling this could be:
1) Define our "Class A" platforms, the ones that we give the full test
attention to. Similar to how we treat translations, this list can
grow given sufficient volunteers to cover the testing, and (if bugs
are found) the fixes.
2) Class A platforms (or "primary platforms" or "tested platforms" or
"supported platforms" -- whatever we call them) are the ones we
encourage users to use.
3) For other platforms we make a wiki-page per platform, were we can
track notes from users on an unique issues they find on that platform.
These combinations are not supported, but may often work. But we
make it easy to collect observations about AOO on that platform, and
make it easy for users to find that info.
If we do this, then our support statement could read something like:
"We have tested and qualified Apache OpenOffice X.Y on the following
operating system versions. Other operating system versions may work
as well, but may require additional configuration. For the latest
information please consult the following wiki page..."
-Rob
> rgds
> Jan I.
>
>
> On 1 January 2013 17:59, Rob Weir <ro...@apache.org> wrote:
>
>> When a commercial software vendor says a configuration is "supported"
>> it means something, typically that to the extent the software license
>> includes an entitlement to support, that the vendor will provide that
>> service for that configuration. So saying something is "supported" is
>> essentially an obligation.
>>
>> With a volunteer-run, open source project, "supported" cannot mean
>> quite the same thing. We're not obligated, in any contractual sense,
>> to provide anyone with anything. That's the nature of a volunteer
>> effort.
>>
>> However, users and organizations considering OpenOffice will naturally
>> think in terms of "support", even if they user that term loosely. We
>> use that term as well, in our release notes, etc. But I think we
>> ought to have a more precise definition of what we mean when we say
>> something is "supported", in order to avoid any confusion. This
>> question has come up recently, with regards to the status of Windows
>> 8, where that OS had not been released at the time AOO 3.4.1 was
>> released.
>>
>> So here's a strawman proposal for what "supported" means for us.
>>
>> 1) "Supported" is a statement we make about a specific version of AOO
>> used with a specific platform, e.g., AOO 3.4.1 with Windows XP SP3 or
>> AOO 3.4 with Ubuntu 12.04 LTS.
>>
>> 2) "Supported" means we encourage use of AOO in that configuration.
>> We have high confidence that the combination is stable, that it works
>> well and is safe.
>>
>> 3) Our confidence in stating something is supported should have a
>> solid basis in testing. Something is not "supported" by us guessing
>> it should work. It is supported only after we have successfully
>> completed testing of that release with that platform. We probably
>> should define exactly what level of testing is required.
>>
>> 4) "Supported" also implies that the supported configuration is
>> sufficiently available and there is sufficient expertise that we have
>> confidence that users will have a high quality experience seeking
>> support on the forums and user list.
>>
>> 5) "Supported" also implies that we stand behind that release and will
>> take necessary steps to correct *critical* bugs, especially security
>> flaws, via rapidly produced point releases where necessary.
>>
>> Note that these are all expectations that a user might have, though
>> any given user might think that "supported" means only a subset of
>> these.
>>
>> What we probably really need is more of a lifecycle statement,
>> including when support for a configuration ends.
>>
>> -Rob
>>
Re: What does "supported" mean for us?
Posted by janI <ja...@apache.org>.
+1 to your definition of "supported", it is funny I just had somewhat the
same discussion today.
Regarding lifecycle, I would like to suggest that we only support the
latest release, otherwise we stretch our resources pretty thin. We can of
course have a statement that we in general will have a look at critical
bugs, but they will only be solved in the latest release.
rgds
Jan I.
On 1 January 2013 17:59, Rob Weir <ro...@apache.org> wrote:
> When a commercial software vendor says a configuration is "supported"
> it means something, typically that to the extent the software license
> includes an entitlement to support, that the vendor will provide that
> service for that configuration. So saying something is "supported" is
> essentially an obligation.
>
> With a volunteer-run, open source project, "supported" cannot mean
> quite the same thing. We're not obligated, in any contractual sense,
> to provide anyone with anything. That's the nature of a volunteer
> effort.
>
> However, users and organizations considering OpenOffice will naturally
> think in terms of "support", even if they user that term loosely. We
> use that term as well, in our release notes, etc. But I think we
> ought to have a more precise definition of what we mean when we say
> something is "supported", in order to avoid any confusion. This
> question has come up recently, with regards to the status of Windows
> 8, where that OS had not been released at the time AOO 3.4.1 was
> released.
>
> So here's a strawman proposal for what "supported" means for us.
>
> 1) "Supported" is a statement we make about a specific version of AOO
> used with a specific platform, e.g., AOO 3.4.1 with Windows XP SP3 or
> AOO 3.4 with Ubuntu 12.04 LTS.
>
> 2) "Supported" means we encourage use of AOO in that configuration.
> We have high confidence that the combination is stable, that it works
> well and is safe.
>
> 3) Our confidence in stating something is supported should have a
> solid basis in testing. Something is not "supported" by us guessing
> it should work. It is supported only after we have successfully
> completed testing of that release with that platform. We probably
> should define exactly what level of testing is required.
>
> 4) "Supported" also implies that the supported configuration is
> sufficiently available and there is sufficient expertise that we have
> confidence that users will have a high quality experience seeking
> support on the forums and user list.
>
> 5) "Supported" also implies that we stand behind that release and will
> take necessary steps to correct *critical* bugs, especially security
> flaws, via rapidly produced point releases where necessary.
>
> Note that these are all expectations that a user might have, though
> any given user might think that "supported" means only a subset of
> these.
>
> What we probably really need is more of a lifecycle statement,
> including when support for a configuration ends.
>
> -Rob
>
Re: What does "supported" mean for us?
Posted by Kay Schenk <ka...@gmail.com>.
On Tue, Jan 1, 2013 at 8:59 AM, Rob Weir <ro...@apache.org> wrote:
> When a commercial software vendor says a configuration is "supported"
> it means something, typically that to the extent the software license
> includes an entitlement to support, that the vendor will provide that
> service for that configuration. So saying something is "supported" is
> essentially an obligation.
>
> With a volunteer-run, open source project, "supported" cannot mean
> quite the same thing. We're not obligated, in any contractual sense,
> to provide anyone with anything. That's the nature of a volunteer
> effort.
>
> However, users and organizations considering OpenOffice will naturally
> think in terms of "support", even if they user that term loosely. We
> use that term as well, in our release notes, etc. But I think we
> ought to have a more precise definition of what we mean when we say
> something is "supported", in order to avoid any confusion. This
> question has come up recently, with regards to the status of Windows
> 8, where that OS had not been released at the time AOO 3.4.1 was
> released.
>
> So here's a strawman proposal for what "supported" means for us.
>
> 1) "Supported" is a statement we make about a specific version of AOO
> used with a specific platform, e.g., AOO 3.4.1 with Windows XP SP3 or
> AOO 3.4 with Ubuntu 12.04 LTS.
>
> 2) "Supported" means we encourage use of AOO in that configuration.
> We have high confidence that the combination is stable, that it works
> well and is safe.
>
> 3) Our confidence in stating something is supported should have a
> solid basis in testing. Something is not "supported" by us guessing
> it should work. It is supported only after we have successfully
> completed testing of that release with that platform. We probably
> should define exactly what level of testing is required.
>
> 4) "Supported" also implies that the supported configuration is
> sufficiently available and there is sufficient expertise that we have
> confidence that users will have a high quality experience seeking
> support on the forums and user list.
>
> 5) "Supported" also implies that we stand behind that release and will
> take necessary steps to correct *critical* bugs, especially security
> flaws, via rapidly produced point releases where necessary.
>
> Note that these are all expectations that a user might have, though
> any given user might think that "supported" means only a subset of
> these.
>
> What we probably really need is more of a lifecycle statement,
> including when support for a configuration ends.
>
> -Rob
>
I agree these 5 points are very good and needed. If we don't have an
explicit entry for something like this, we definitely need to create
something (off the Download page? elsewhere?)
Since this is "free" software, I see 4. and 5. as critical to end users. #3
should go without saying -- this seems standard practice to release
anything. There are certain areas of AOO that need more of this -- the DB
connectivity aspects for example. Some of this is difficult for many
volunteer testers without access to some environments.
OK, many more interesting points made already. I am also assuming that
commercial users have a slightly different set of priorities in this
regard. But something like this list is needed.
--
----------------------------------------------------------------------------------------
MzK
"No act of kindness, no matter how small, is ever wasted."
--
Aesop