On 1 January 2013 19:03, Rob Weir <robw...@apache.org> wrote:
> On Tue, Jan 1, 2013 at 12:58 PM, janI <j...@apache.org> wrote:
> > On 1 January 2013 18:50, Rob Weir <robw...@apache.org> wrote:
> >
> >> On Tue, Jan 1, 2013 at 12:06 PM, janI <j...@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 <robw...@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
> >> >>
> >>
>
