Return-Path: X-Original-To: apmail-openoffice-dev-archive@www.apache.org Delivered-To: apmail-openoffice-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 33283ED24 for ; Tue, 1 Jan 2013 17:50:48 +0000 (UTC) Received: (qmail 89026 invoked by uid 500); 1 Jan 2013 17:50:47 -0000 Delivered-To: apmail-openoffice-dev-archive@openoffice.apache.org Received: (qmail 88960 invoked by uid 500); 1 Jan 2013 17:50:47 -0000 Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openoffice.apache.org Delivered-To: mailing list dev@openoffice.apache.org Received: (qmail 88950 invoked by uid 99); 1 Jan 2013 17:50:47 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Jan 2013 17:50:47 +0000 Received: from localhost (HELO mail-oa0-f44.google.com) (127.0.0.1) (smtp-auth username robweir, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Jan 2013 17:50:47 +0000 Received: by mail-oa0-f44.google.com with SMTP id n5so12565219oag.3 for ; Tue, 01 Jan 2013 09:50:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.245.20 with SMTP id xk20mr36565875obc.89.1357062646697; Tue, 01 Jan 2013 09:50:46 -0800 (PST) Received: by 10.182.245.48 with HTTP; Tue, 1 Jan 2013 09:50:46 -0800 (PST) In-Reply-To: References: Date: Tue, 1 Jan 2013 12:50:46 -0500 Message-ID: Subject: Re: What does "supported" mean for us? From: Rob Weir To: dev@openoffice.apache.org Content-Type: text/plain; charset=UTF-8 On Tue, Jan 1, 2013 at 12:06 PM, janI 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 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 >>