Goaccess: Next release of GoAccess

[szepeviktor]

There are a number of commits since last release

https://github.com/allinurl/goaccess/compare/85cdf89f8f26b584168cf3a9a9941f80d769e2ee...master

Do you plan to release 1.3?

[allinurl]

I certainly plan to release 1.3, however, there are still a few milestones I want to reach, such as #334, #832, and hopefully I can nail down #708/#813 (which are haunting me - can't reproduce them). Closing those will make it a nice release :)

[szepeviktor]

Seem like the community is not that active, all 4 PRs are open.

[allinurl]

A different project is taking a lot of my time, I certainly need to start pushing out some major commits though. #708/#813 needs to be addressed in my opinion before the next release is pushed out. Otherwise, it may be worth replacing tokyocabinet with something more stable or roll-out our own. I just closed 2 PRs, only your is left, which I need to look in the next deb packaging.

[szepeviktor]

@allinurl Do you plan to release a new version this year?

[allinurl]

There are a couple of PRs opened at this time. However, by no means this is an indication of the project not being active. There is a chance that the current on-disk storage will go away, so before merging them, I need to check if the new on-disk storage will be pushed out. Probably there won't be a release this year, I believe at this point it's better to push a a major release.

[szepeviktor]

@allinurl I think it may take some time to resolve bugs
https://github.com/allinurl/goaccess/issues?q=is%3Aopen+is%3Aissue+label%3Abug

[allinurl]

@szepeviktor Indeed it will take some time, however, several of them are dups and should be taken care of once the on-disk btree is replaced. If possible, feel free to check any of them.

[szepeviktor]

@allinurl What kind of help would advance the next release?

[allinurl]

I'm halfway implementing the new on-disk storage in an attempt to fix these issues. Once I get this done and have it fully tested I plan to push this release for sure. In between, I may be able to address a few other opened issues. I'm certainly aware of how behind this release is :(

Please feel free to take any issues you feel comfortable with, it's always very helpful and appreciated.

[szepeviktor]

It seems like on-disk storage needs a lot of changes in the code.

[szepeviktor]

Hello @allinurl !

Do you have plans to fix the on-disk bug/s and make a release?

[allinurl]

Hello @szepeviktor, yes I certainly have plans to finish fixing that issue and to push the next release. Last few months have been crazy busy here, should be better in the upcoming weeks though.

[szepeviktor]

Thank you.

[szepeviktor]

Hello @allinurl !

Do you plan to fix the on-disk storage issue and make a release?

[allinurl]

@szepeviktor Yes I do. Working on it as of this post :)

[justinmayer]

Looking forward to the next release. If I may humbly make a few suggestions...

• When the next version (1.3) is released, immediately create a new issue to track the next version (say, 1.4). That allows folks to subscribe to the "Release next version" issue and thus know once it's been released. (I use this technique for Pelican, and folks seem to find it very useful.)

• Create milestones for the 1.3 release and also the next 1.4 release, adding the most important issues as appropriate, including the aforementioned ones. That makes it easier to understand what's holding up the release, and can help determine which issues are truly critical and which can/should be deferred to a subsequent release in order to maintain a more frequent release cadence.

• Release new versions more frequently, even if they aren't "complete" or "ready". This project has about new 550 commits since 1.2 was released, none of which are being used by the vast majority of users because they aren't in a shipping release. This is a very difficult discipline to develop and put into practice, and I am _terrible_ at it. Look no further than Pelican, which hasn't seen a release in a similar timeframe! But I am making a commitment to releasing more frequently, and I think GoAccess would benefit from a similar practice.

For what it's worth, I am more than willing to assist with any of the above issue/milestone management tasks if that is helpful. Just say the word, and I'll get to work on it! 😁

[allinurl]

@justinmayer Thank you very much for those tips. I completely agree on all of them.

1. I wasn't aware of this functionality. I do like this idea of creating a new issue so folks can subscribe to it. :+1: I'll make sure to do that for v1.4

2. I agree on this, I'll defenitly start using milestones, especially in the upcoming releases. Just created the first one for v1.3 containing the showstopper (w/ dups) for the upcoming release.

3. I couldn't agree more on this. Like you said, there are ~550 new commits since 1.2 was out, and I haven't released 1.3 :( I attribute this to several things happening to me since then, but ultimately I think I mismanaged it. I've been working slowly on that one thing that's holding v1.3 and now I have set a hard release deadline of November 23, 2018.

I do appreciate a lot your offer to assist on the project. As I'm in the middle of the new on-disk storage, I think is best I just finish it up and release v1.3 asap.

[allinurl]

v1.3 was pushed out last Friday Nov 23th. Closing this. Thanks!

[szepeviktor]

Thank you!

:) I wait for 1.3.1 with all the bugs fixed.

[justinmayer]

Awesome! Are there any upgrade notes for those upgrading from v1.2 via Debian packaging? Any configuration file changes required? Or is it as simple as apt upgrade goaccess?

[allinurl]

@justinmayer Great question. apt upgrade goaccess should do the job.

Only minor installation change is where the conf file is placed, before it was under /etc/goaccess.conf now is under /etc/goaccess/goaccess.conf. Also, you may want to expand your browsers.list as needed and use -b /path/browsers.list.