On Tue, Jul 01, 2014 at 12:37:31PM +0100, Matt Caswell wrote:
> >> I just started to wonder, will soon come the time when my patches
> >> will be also refused with the "unsupported platform" comment?
> >
> > Our soon-to-be-released roadmap has this to say on "supported platform":
> >
> > * Currency, i.e. a platform is widely deployed and in current use
> > * Vendor support
> > * Available to the dev team, i.e. the dev team have access to a
> > suitable environment in which to test builds and deal with tickets and
> > issues
> > * Dev team ownership, i.e. at least one person on the team is willing
> > to take some responsibility for a platform
> 
> The roadmap has now been announced on the -users list:

Of note from the roadmap:

* Non-supported platforms requiring regular maintenance activities
  will eventually be removed from the code after first seeking
  community owners to support the platforms in platform specific
  repositories.

For the record, I'm absolutely in favor of the platform support
strategy documented in the roadmap.


I would assume that something that follows from the above that patches
for these non-supported platforms will be applied only if they don't
impose maintenance costs, and that it will be up to community owners
interested in supporting these patches to make the support as painless
as possible.

For example, I'll accept patches for e2fsprogs for non-supported
platforms (I don't have a FreeBSD platform at hand), but if the patch
doesn't apply, or if it causes regression test failures, I will in
general not try to fix up the patch; I'll bounce it back to the patch
submitter who is much more well suited to create a proper patch that
applies against the tip of the development patch and doesn't cause any
problems.  Well, sometimes I'll be nice and do some minimal cleanups,
but I don't feel *obliged* to do anything more than this.

If this is how the OpenSSL team plans to run things, it might be
useful to put a statement similar to the above into their
to-be-published Document Strategy docuement.

                                                        - Ted
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [email protected]
Automated List Manager                           [email protected]

Reply via email to