search

redddcyclone / glpi-agentmonitor

GLPI-Agent monitoring utility for Windows (systray icon)
GNU General Public License v2.0
9 stars 5 forks source link

Minor updates request #3

Closed g-bougard closed 1 year ago

g-bougard commented 1 year ago

Hi @redddcyclone

I see 2 things you may need to update:

  1. as you added new features, you should update the README.md so your github project page lists all the features,
  2. this is not critical, but testing glpi-agent packaging integration, I found it's possible to start GLPI-AgentMonitor more than one time by user session. This creates as many icon as it is started. I don't know if this is easy to support but it would be nice to not start it if still started.
redddcyclone commented 1 year ago

Hi @g-bougard

as you added new features, you should update the README.md so your github project page lists all the features,

As I didn't prepare a new release yet, I thought of adding the new features to the README.md file only when I release it. Do you think I should have already referenced the new features even though there's no release ready?

this is not critical, but testing glpi-agent packaging integration, I found it's possible to start GLPI-AgentMonitor more than one time by user session. This creates as many icon as it is started. I don't know if this is easy to support but it would be nice to not start it if still started.

Yes, I'll work on it right away, I think this is easy to accomplish.

g-bougard commented 1 year ago

Indeed the README is here to describe what is doing the current code. If you don't want to list them here, you can also link the CHANGES source telling future release features are listed there.

And also, for clarification, maybe you should tell official releases will be available from glpi-progect/glpi-agentmonitor fork.

redddcyclone commented 1 year ago

OK, I'll clarify it in the README.

Also, about the releases, how should we do it? Should I set a tag for releasing in this repo and then you do the same in the fork? I'm still confused about this

g-bougard commented 1 year ago

IMHO, you should not do any release until this is handled in our fork. So you should not put any tag. You should probably just update the README to tell where official release can really be download at that time.

You should think to release yourself in the future only if we decided to no more follow your updates. Just remember this is up to you as this is your project. You know you can quickly release by simply tag a commit and push it to your project. Personally, if you decide to release, I won't blame you as this is your freedom. glpi-project/glpi-agentmonitor is just a fork so we can sign by ourselves the produced binaries. For security reasons (and even if I trust you today ;-)), we can only promote in documentation or embed in our packages what we build and publish by ourselves for such kind of features.

redddcyclone commented 1 year ago

Right, I like it the way it is today, releases being handled by the fork, signed. But how would you know it's time to tag a new version in the fork? Should I tag it here and delete the automatically produced release after?

g-bougard commented 1 year ago

I'm notified you pushed some commits as I subscribed to your repository. So I know a new release should come soon. I have to review your code and merge it in the fork. So I can decide to release myself if I think you finished the new features. But you can simply open an issue on our fork to request a new release as you think you finished the dev. After the release is published, you can fix the CHANGES file to remove the "not yet released" tag. IMHO, you even can remove that tag as you don't have to handle release process by now.

redddcyclone commented 1 year ago

So shall I leave versioning up to you and just keep adding features and logging them in the changelog? I agree with this, if so

g-bougard commented 1 year ago

Yes, I confirm.