couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Kowalski <...@kowalski.gd>
Subject Re: [DISCUSSION] Remove Logs module from Fauxton
Date Sat, 24 May 2014 19:46:02 GMT
Hi,

I would also just remove the code.


2014-05-24 19:18 GMT+02:00 Simon Metson <simon@cloudant.com>:

> Hey,
> I'd remove the code and let the VCS be the historical record.
> Cheers
> Simon
>
>
> On Saturday, 24 May 2014 at 07:44, Garren Smith wrote:
>
> > Hi All,
> >
> > I’m happy for it to be removed. Should we remove the code or just
> disable from being added to Fauxton on a build? If we keep the code we will
> have something to build off if logs gets added back in after the merge?
> >
> > Cheers
> > Garren
> >
> > On 23 May 2014, at 8:44 PM, 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.
> > >
> > > -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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message