Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move idle, external, and similar features elsewhere #493

Open
ederag opened this issue Dec 15, 2019 · 11 comments
Open

Move idle, external, and similar features elsewhere #493

ederag opened this issue Dec 15, 2019 · 11 comments

Comments

@ederag
Copy link
Collaborator

ederag commented Dec 15, 2019

"External" was never brought back (#271),
and notifications are not working at all (tested on openSUSE 15.1).
There have been related feature requests (#123) and PRs (#118, #259) pending for a long time.

No wonder:
that kind of features is nice to have, but hard to test,
and increase a lot the maintenance burden and responsibility.

All these features can be implemented separately,
talking to the main hamster through dbus, for instance.

Let's remove them from the main repo,
and if there is an interest, eventually delegate that to a new separate project
(say hamster-companion), preferably with another maintainer.
[I would gladly help to set it up, of course, so please ask here]

That would even be reusable with the rewrite if it resumes.

@ederag
Copy link
Collaborator Author

ederag commented Dec 20, 2019

Removal part done in #494.
Leaving open as an advertisement for the revival part (need help).

@ederag
Copy link
Collaborator Author

ederag commented Dec 27, 2019

For JIRA and Redmine integration, hamster-bridge already exists and looks good !
@kraiz the DBus interface is intended to be stable, but we can discuss improvements.

@sh-zam
Copy link
Contributor

sh-zam commented Jan 4, 2020

As a user of this, I will try to fix it :-)

Starting with: notifications are not working

@ederag
Copy link
Collaborator Author

ederag commented Jan 4, 2020

@sh-zam that would be good !
In addition to the removed files listed in the PR #494 head comment,
here are some pointers about notifications:
https://wiki.gnome.org/HowDoI/GNotification
https://github.com/projecthamster/unity-indicator/blob/master/hamster-indicator

@sh-zam
Copy link
Contributor

sh-zam commented Jan 24, 2020

Follow up from: PR #521

If I understand you correctly, you want the notifications to be managed separately (like in a separate service) and it should talk to hamster-service and client over dbus?

@ederag
Copy link
Collaborator Author

ederag commented Jan 24, 2020

Exactly.
These features are hard to test, and will need a faster development/review pace, too much for me.
Not to mention this wise recommendation from @tstriker himself.

As stated above, this is how hamster-bridge works.
@kraiz, @mkorvas, could notifications (PR #521) be added to hamster-bridge e.g. as a listener ?

@sh-zam
Copy link
Contributor

sh-zam commented Jan 24, 2020

Makes sense.

If the repository is fit for hamster-bridge, I'll add it to that.
If not, I'll create a new one for notifications and few other features, I'd love to have :-)

@gsobczyk
Copy link

If anybody is interested I've made some changes to hamster in my own repository https://github.com/gsobczyk/hamster:

  • gathering activities from an external source: Jira (but only via DBUS because I don't have a need to suggesting them - I use cinnamon applet for every operation on activities)
  • export activities as worklogs to Jira

@DirkHoffmann
Copy link
Member

If anybody is interested I've made some changes to hamster in my own repository https://github.com/gsobczyk/hamster:

Hello @gsobczyk,
Thank you for your contributoin. Would you mind to create an independent pull request, where we can discuss it?

@ederag
Copy link
Collaborator Author

ederag commented Sep 5, 2020

Several comments and PRs show a misunderstanding of the rationale.

  • All the external stuff really could have been brought back quickly
    if there were developers interested in the setup and testing (my safe estimate was 1-3 months), with my help.
  • Keeping the core lean is by far the best way, for both users and maintainers.
    See the project creator's warning (emphasis is mine):

but i need someone taking care of pull requests and making sure hamster stays on focus and doesn’t gain weight via preferences (i’ve seen oh so many requests for that lately and majority fall far outside the 80/20 rule; it is however compelling to please everyone, and that’s what i’m afraid my replacement would try to do)

Ideally the candidate would have something to show that he and she have created, because if there is anything that i fear more than extinction is the project falling into somebody’s hands who will botch it up

So please be nice with the new maintainers.
People who want too much (a bit is fine) wear maintainers out. No theory; it already happened...

@ederag
Copy link
Collaborator Author

ederag commented Oct 28, 2020

@u451f
They are all important features, and I measured their usefulness.
But maintainers have already trouble with the main code (it's been about 6 months since #597 (comment)),
see why we planned to decrease the burden ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants