couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: [DISCUSSION] Remove Logs module from Fauxton
Date Sat, 24 May 2014 19:54:43 GMT

On 23 May 2014, at 20:44 , Joan Touzet <joant@lrtw.org> wrote:

> Hi all,
> 
> I am also +1 on this. It would be a "nice to have" to restore logging
> functionality after the merge, but as the present work is in an
> unfinished and unusable state, it would be unfair to users to push this
> out.

+1 to have this added back in a point release, if we decide we want this.

Best
Jan
--


> 
> -Joan
> 
> ----- Original Message -----
> From: "Robert Kowalski" <rok@kowalski.gd>
> To: dev@couchdb.apache.org
> Sent: Friday, May 23, 2014 1:13:25 PM
> Subject: Re: [DISCUSSION] Remove Logs module from Fauxton
> 
> As the BigCouch merge is right around the corner, I am +1 on closing the
> tickets for the log component (so people that want to contribute do not
> spent time on a component which gets removed in a few weeks). This also
> includes not to add features for the log component that do not have a
> ticket.
> 
> Also +1 on removing the logs component now, but just if we have to support
> it with/after 2.0, which would be the case if we do a LTS release. We would
> have to maintain a special snowflake then.
> 
> 
> 
> 2014-05-23 18:10 GMT+02:00 Alexander Shorin <kxepal@gmail.com>:
> 
>> Hi devs,
>> 
>> The situation around Logs module looks like the following:
>> 
>> 1. Current UX is bad - it requires a lot of work and time to get fixed;
>> 2. After BigCouch merge the /_log resource will be gone (and all the
>> work that had done for it too);
>> 3. With BigCouch merge lager module comes which is able to streams
>> logs to custom aggregation systems like LogStash. These systems are
>> more powerful in question of logs analysis and monitoring than Fauxton
>> could ever provide;
>> 4. The last release of 1.x series will have LTS status which means
>> that it'll receive only bug fixes and security updates. Probably, with
>> one exception in face of Fauxton to make users migration more smooth.
>> Since Fauxton evolves very fast, it would be awesome to pick his
>> changes back to LTS Fauxton teams will be happy to reduce amount of
>> things which only works for some single branch (2.x or 1.x) and the
>> /_log resource is the only of such.
>> 
>> In overall, there left no strong reasons to continue improve Fauxton
>> Logs module. May be remove it and close all the related tickets as
>> Won't Fix? It's a pity to say that, but the reality is hard. What do
>> you think about?
>> 
>> --
>> ,,,^..^,,,
>> 


Mime
View raw message