dev-mailinglist

[elbenfreund]

Hello

As a long time user of hamster I have finally some time at my hands which
I possibly would like to invest into doing some work on hamster.
So far this has been limited to some minor import scrips.
As the project seems to have received some activity rececntly now may be a good
time to join the party. :)

Is there any dedicated development mailinglist or the like, used to
discuss design and implementation details/questions?
If not i could offer setting one up if you think that would useful.

Thank you and your projects contributors for the little hamster and hope
to hear you soon. Eric.

[toupeira]

Hello @elbenfreund, thanks for the offer and yes I agree this would be useful! Do you already know where to set it up?

[elbenfreund]

I took the liberty to set one up here.
Once we are up and running you may take over of cause.
Let me know if it works for you or if you run into any trouble. Could be that DNS for lists.denkeninechtzeit.net may need awhile to propagate.

[elbenfreund]

Hello again there. What is the general status up this project anyway? :)

I have taken a closer look at the codebase in master, and there seems to be quite some potential for clearing some technological debts. The fact that we do not seem to have any testcoverage to speak of is also not realy encouraging.
I would be willing (upcoming projects pending of cause) to put in some major work into this (as have others at times before) but if this is a lost case, it may be better to just fork and move on?

On a different note is there any documentation about why/how to use waf for this particular project. Maybe refacturing package layout would help clarify/compartmentalize upcoming tasks a bit. Right now it seems a bit confusing what aspect (cli-client, gtk-client, dbus-service, storage-backend) is where and most likely not all is needed in one package.

[toupeira]

@elbenfreund thanks for your email and I apologize for the late response! When @tbaugis was looking for maintainers about a year ago I had just recently started using Hamster, and like you I wanted to help the project stay alive and decided to take over maintenance. But as these things go I never really found the time to dig into the code and clean up all the open issues and PRs, so I really appreciate you taking the initiative and welcome any work you're willing to put into this!

Big thanks also for setting up the mailing list, I subscribed and added a link to the README so people can find it.

I think everybody would rather avoid a fork, and since you seem trustworthy enough I went ahead and added you to the GitHub team. Submit any changes in a PR, I'm usually more responsive on those compared to issues ;-) And of course if you want to take over more responsibilities I definitely won't stand in your way.

As for the general status of the project, here are the main issues from my view:

• several distributions still carry ancient Gtk2 versions of Hamster, which causes a lot of confusion with users and "invalid" bug reports. So getting proper packaging going again would be a big win, I'm planning to look into Debian packaging soon, and also doing a proper 2.0 release.
• missing tests and CI, definitely important
• Python 3 migration (see the old PR Python 3 migration, #153 fix #174)
• moving away from outdated tech like GConf

And then of course there are lots of minor bugs and feature requests, mostly for syncing and reporting. Regarding waf, I have to admit I'm not very familiar with the Python world these days. Suggestions for alternatives are certainly welcome, especially if it helps with packaging.

I hope I was able to address your concerns and look forward to seeing your improvements! I'm also planning to set aside some time every week for Hamster so I can be more involved.

[elbenfreund]

Hey Markus,

did you revieve my mail on the dev list? In case something went wrong folloing is a copy.

It would be great if we could get this thing going :)

Hello Markus, welcome to our humble dev list...

As i mentioned before, my main focus with regards to hamster right now
is a major rework of its backend [1].
So far this work is coming along quite nicely and I am confident that
will be able to upload something workable within the early parts of next
week. Just before Fallout 4 gets out
So far I tried really hard not to break anything clientside. For that I
basicly made sure that the API provided by client.py stays untouched.
Everything from there on on down to storage.db has been more or less
rewritten.

Unfortunatly we do not have tests, so once i actually upload my stuff,
somebody who has a grasp of the frontend end of the code (what input
does it expect, what hidden constrains are there, what undocumented
assumptions are made...) need to have a look over my code and let me
know were we run into problems.

With regards to the big picture and things that I did not want to change
as part of the rewrite but feel may be worthwile (re-)considering I will
put down in the questions bit of this page [2].

After you had a chance to look at [1] I would be glad to hear about your
thoughts with regards to wether to create new repositories to house our
backend and dbus-service related code.
Once we decide on that i can start pushing and prepare python packaing.

Concerning versioning; I personaly suspect (given current activity of
the project) that we keep the version 2 major as indicator for our
switch to gtk 3 BUT (if you turn our to be ok with my work on the backend)
go straight to 3 once we put backend and dbus-service into its own
package. This should make it easier to communicate the state of affairs
to anyone just passing by...

Python3: All new backend code e.g up to and including client.py will be
python2.7 and python3 compatible, So its just up to the frontend to
deal with this

On a more personal note: As you said in your issue response "you never
really found the time to dig into the code", are there any pieces-areas
you feel more familiar with than others? From where I stand, it would be
realy great if someone could focus/take on the frontend facing end of
hamster. For a) I usually try to avoid frontend work b) i dont like
frontend work c) am busy bringing the backend up to standarts

So, not to overwhelm anyone with too much of a novel instead of an
email, I shall end here and repeat my opening line: welcome to our
humble dev list... lets get this furry hamster rolling!

Eric.

[1] https://github.com/projecthamster/hamster/wiki/Proposed-Code-Layout
[2] https://github.com/projecthamster/hamster/wiki/Development-Discussions/

[tstriker]

i would advise against a mailinglist and maintain all the discussions here in github, naturally grouped by issues. This provides a single source of truth for the project and alleviates the need to hunt for mailinglists and operate with yet another interface (incredibly dated while at it). most modern projects seem to be able to live with just github so i'd suggest to leave it at that.

@elbenfreund - as for "reworking the backend"
what you seem to be proposing with the rework is to split up the main code in four packages, to which i don't really see much merit to - none of the individual packages would be able to survive by themselves, nor they can really be reused, as the structure has clear dependencies: storage -> dbus -> cli | gui
splitting them out will add overhead to packaging, development and also to issue tracking, or in other words - what you are proposing is directly going against what you are hoping to address.

i'd suggest to, instead of going for a house cleaning, aim for smaller things first - familiarize yourself with the project so that you wouldn't need someone else to tell you if your code is broken or not. and maybe gain understanding on how the already in-place pluggable backends work (and learn that there is no real demand for pluggable backends, either. And why would there be - sqlite comes built into python, there are no performance considerations, and the in-place schema migration system is good enough).

[elbenfreund]

Thank you for your feedback :)

Mailinglist

Using an issuetracker as a mailinglist/threaded communication platform is not something i regularly encounter in a software project. To the contrary, most trackers will try to encourage a clear separation of discussing an implementation and documenting process.
Besides this, the target audience is fundamentally different. In a way, the issuetracker is a public facing interface to communicate the state of affairs. To provide a search-able lookup so users and interested non-core-devs can easily see what is an already known problem and what is new phenomenon. Overloading this with several additional tickets discussing implementation details, specifications and the like is confusing at best, intimidating at worst.

Compartmentalization

Interdependence

Compartmentalization is not only about creating packages that "can live on their own" but also to have clearly defined dependencies and functional units. There is just no excuse what so ever that we have parsing code in 2 (3?) different places, same goes for business logic within our sql queries and so on...
a proper hamsterlib could very well provide functionality that is common to any possible frontend while being able to stand on its own. whether one opts to use it in order to build a monolithic timetracker GUI or opts for the dbus or CLI interface should would not matter. You just build upon the library. this would also help reduce code/feature-duplication as we have it right now.

Packaging

Spliting them would not create overhead but actually start to allow proper packaging. Right now the state of affairs is that no one knows what to package where, how relevant WAF is and what hidden dependencies may lurk around the corner.

Issue tracking

I fail to see how a clear separation of concerns would create overhead to issue tracking. To the contrary: it would allow to properly assign the relevant issue to a clearly defined component and improve the odds that a person actually familiar with the relevant codebase is made aware of this instead of spaming everyone.

General

I tried to familiarize myself with the project but documentation is non present/contradictory and direct communication difficult. Besides that, I checked back with Markus before I started my work and this seemed to be a valid course of action.
As a sidenote: I am not asking for someone to tell me if "my code is broken or not", but to tell me if my code breaks any client using the interface. Seeing that no documentation about the API is to be found and the present code is inconsistent I don't think this is unreasonable or grounds for snappy remarks.
I gained quite the understanding of "how the current backend works" and it scares me ;) I think any attempts to work towards syncing or the like will be difficult with the present self made sqlite solution. Seeing that this is a major issue for a lot of people there is a clear business case to be had. Even if one would be really to concede that writing SQL by hand instead of using a well tested and flexible library instead is the way to go.

To sum things up, I am truly grateful for hamster as it is right now and would like to give something back. I may be wrong or not, but from where I am standing the code is past refactoring, especialy given its lack of documentation. As a consequence I have rewriten the backend and would be happy to offer it to the project (right now I just want to get my coverage from 50 to 80%).

If you truly feel that the project would be better served with its current solution I would disagree but will manage. I would persue thisi as a proper fork instead. I am confident that we will manage to work this our in a constructive way and shall take this as a sign of renewed interest of hamsters developers in the project :)

If you decide not to make use of my offer I will go on and continue development within my own repository. This wouldnt be a big deal but for the lack of git-history if you decide to incorporate the code in some later stage.

One way or the other, thanks for you comments and rejuvenated interest in project hamster, Eric.

Quite frankly, the current state of the project is a case in point of my argument. When I first layed eyes on the code I was almost willing to walk away again because it is just utterly unclear which bit is done where.
Repeaded questions about the use of waf illustrate that.

[FelixSchwarz]

Just some input from my experience as someone developing in Python + some moderate experience in packaging stuff in Fedora: I don't think waf (the build system?) or something like that matters a lot. If you want your latest code in distributions you should release a stable version first. Packagers can also push "-rc" (or even just git) versions in the distribution (as currently seen with hamster in Fedora) but that is usually some effort/packagers might receive some pushback about this.

It seems to me as the 2.0 version regresses a bit on functionality (overview window) which makes it harder to justify the update but usually packagers are not so opinionated so most of them just "follow along".

Testing+CI is for sure important but just for the project as a whole, not necessarily for distribution adoption.

From my point of view the "hamster project" (= developers with push access) needs to become more responsive. I see 9 pull requests and more than half of them without any response. Even if you tell the submitters "won't be implemented, not the right way" it's better than no response.