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 <kxe...@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? > > -- > ,,,^..^,,, >
