My understanding from our JS devs is that Futon is both completely
unmaintained and unmaintainable.

-Joan

----- Original Message -----
From: "Jonathan Hall" <fli...@flimzy.com>
To: dev@couchdb.apache.org
Sent: Saturday, 19 August, 2017 11:47:11 AM
Subject: Re: [DISCUSSION] Moving CouchDB off of Facebook React

One other random thought.  It's admittedly ugly, but I think worth 
bringing up just the same:

What effort would be involved in making the old Futon interface usable 
in CouchDB 2, possibly even without exposing all the features?  Would 
that be less effort/faster than porting Fauxton? I know the interface is 
old and clunky, and doesn't support all CDB 2.x features, but (assuming 
no similar licensing restrictions), even an old (and possibly limited) 
interface might be a better option for some, than the pain of installing 
Fauxton as a separate step.

If feasible (in licensing and technical terms), I only offer this as a 
stop-gap measure, probably to be coupled with the "install Fauxton" link 
option described below in #3.

-- Jonathan

On 08/19/2017 12:50 PM, Jan Lehnardt wrote:
> Thanks for getting the ball rolling Joan,
>
> If you are interested in the licensing/policy details, I’ve summed things up 
> on my blog: 
> http://writing.jan.io/2017/08/19/understanding-the-facebook-vs-asf-license-kerfuffle.html
>  — if you want to comment on this, please start a new thread, or email me 
> privately. This thread is only for what we do next with Fauxton.
>
> * * *
>
> To take a bit of pressure out of this decision making process, I want to 
> bring up an option that unblocks us indefinitely for making new releases at 
> the expense of end-user experience.
>
> It’s a little bit of work, but not as much as anything approaching a rewrite.
>
> 1. move apache-fauxton to its own GitHub organisation outside of the ASF
> (we can always re-integrate it later)
> 2. publish release builds as tarballs somewhere on the web.
> 3. replace /_utils in CouchDB with a custom route that displays a simple web 
> ui with a button “install Fauxton” that goes away once Fauxton is installed, 
> that then fetches a Fauxton release tarball from outside the ASF and installs 
> it on the user system.
>
> There is some infrastructure work to be done, and the added inconvenience for 
> our end-users is not something I’d like to keep up for long.
>
> But should we decide to take this option (or one like it), it would allow us 
> to not have to rush with a Fauxton adaptation, or be blocked on releases, or 
> have no admin UI in a release.
>
> * * *
>
> Garren has already done some experiments with preact[1] (a react-API 
> compatible rendering library with a compatible license) and has a basic 
> prototype running. Since we are also using additional React libraries that 
> have no corresponding equivalent in preact-land, Garren expects to migration 
> work to take 1-2 months of development time, something I’m not sure we are 
> able to afford at this point.
>
> [1]: https://preactjs.com
>
> * * *
>
> Moving to a library that isn’t React-API compatible would be close to a 
> complete Fauxton rewrite which would likely take years at our pace, and would 
> break compatibility with downstream addons (that we know Cloudant are using).
>
> As such, my preference would be to stick with the React-API and find a 
> minimal replacement for what we need. But I’d like to leave the final 
> decision to the Fauxton team.
>
> * * *
>
> I’d be happy to help with a recruiting drive to get more folks helping to do 
> the port.
>
> Best
> Jan
> —
>
>
>
>
>
>> On 19. Aug 2017, at 02:40, Joan Touzet <woh...@apache.org> wrote:
>>
>> Hello everyone,
>>
>> <Joan puts her Apache CouchDB PMC hat on>
>>
>> I have some difficult news to communicate.
>>
>> Those of you who are more tuned in to the JavaScript world will be aware
>> that the Apache Software Foundation (ASF) has placed the so-called "BSD
>> + Patents" license that Facebook uses in licensing some of its open
>> source technologies, such as the popular React library, into "Category
>> X." This means that we are no longer able to ship React in Apache
>> CouchDB, nor have it as a build dependency, after August 31, 2017.
>>
>> Subsequently, we asked Facebook if they would consider changing the
>> React license to avoid this conflict, as they chose to do for their
>> RocksDB database. About an hour ago, they publicly announced that this
>> would not be forthcoming:
>>
>> https://code.facebook.com/posts/112130496157735/explaining-react-s-license/
>>
>> This means that we must replace the use of React in Fauxton completely
>> (with something like Vue or preact), and ship CouchDB without Fauxton
>> until the former can be completed (or simply not ship until the rewrite
>> is complete.)
>>
>> No one in the PMC is suggesting we remove Fauxton completely from
>> CouchDB either now or in the future - we consider our web UI a defining
>> feature of the product and would consider a Fauxton-less release of
>> CouchDB incomplete.
>>
>> I would like to open the discussion towards the Fauxton rewrite, and
>> specifically:
>>
>> * Which replacement library do we like the best? Why?
>> * Who is willing to step up to lead this change?
>> * Do you know any good JS devs willing to help us?
>>
>> Those who are interested in the reasons why this policy decision was
>> reached by the ASF are encouraged to read the following links:
>>
>> https://issues.apache.org/jira/browse/LEGAL-303
>> https://issues.apache.org/jira/browse/LEGAL-319
>> https://github.com/facebook/react/issues/10191
>>
>> PLEASE do not devolve this thread into discussion about Facebook's
>> decision, or why the ASF has made the policy decision that they have;
>> such discussions lead nowhere, and CouchDB is not in a position to
>> influence either organisation to change their decisions.
>>
>> On behalf of the CouchDB PMC,
>> Joan Touzet


Reply via email to