On Wed, Jan 2, 2013 at 3:39 AM, Ian C <i...@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 <robw...@apache.org> wrote: >> On Tue, Jan 1, 2013 at 1:03 PM, Dave Fisher <dave2w...@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.
