Freezing master to release 3.13

[ultrabug]

I would like to state that I and we shall not merge anything else from now on on master and focus on releasing a new version of our beloved project.

I will therefore only accept to merge

• functionally blocking user facing bugs
• CHANGELOG updates to reflect 3.13

For the next release, we will start using milestones which describe the focus of the current development efforts. Ideally we will alternate between module focused releases and core focused releases.

This should help us be clearer for everyone as well as making sure we do not waste too much energy in too much topics at the same time.

[lasers]

@ultrabug should review #1504 and #1499 too.

[lasers]

https://github.com/ultrabug/py3status/tree/changelog-3.13

[tobes]

cool by me I would like to resolve #1504 because that save us pain, maybe we chat over the weekend.

I'm also for a more focused development cycle

[ultrabug]

Ok tomorrow is one week frozen master day, we will be able to proceed

@tobes what's your decision on #1504 please?

[tobes]

I've merged #1504.

I've tried to see any problems with the change - lm_sensors which as I understand is the effected module seems to behave the same before and after the merge. To be honest The module is broken in the default settings for me but if I fix that issue then nothing seems to change and I am still waiting for @lasers to actually provide a workable example of his problem (I still think the fix is trivial but need a test case). I think the module needs a rewrite anyway.

I think maybe we should also look at taking #1525

[ultrabug]

Indeed, #1525 is in thanks

[ultrabug]

so @tobes @lasers I have trouble seeing through what is preventing 3.13, are we in line here? shall I proceed?

[tobes]

from my point of view there are the following issues

• timewarrior module has some issues but the merge was done badly so I reverted (realistically we could take the PR or drop the module as it's new) I'm skeptical of modules that no-one uses.

• lm_sensors has some issues but there has been no real explanation of the issue.

Me I'd drop both of them completely and do a release

[maximbaz]

Having functionality in modules that no-one is using (or having entire modules without real users) is strange indeed, I wonder if it makes sense to make some kind of revision and determine which modules are not being used at all by core contributors.

I also wonder if it makes sense to split the modules in two folders "core" and "contrib", where "core" contains modules used by at least one of the maintainers (and thus are guaranteed to be working and with perfect code quality), while "contrib" contains the rest (modules made for fun, modules made as an example, etc.), which are not being used by core contributors and thus are not guaranteed to be in the best shape or even working.

Maybe worth discussing this in a separate ticket, not to clutter this one.

[tobes]

I also wonder if it makes sense to split the modules in two folders "core" and "contrib"

In my experience this makes things very difficult to manage - however knowing who uses/cares about which modules is very useful information and we could add this somewhere.

I'd also happily see a module cull at some point too

[lasers]

Imho...

1) Revert the (functionally blocking user facing bugs) revert https://github.com/ultrabug/py3status/pull/1527 to get rid of large button functionality that is going to be generally confusing and useless. I believe some users who already use timewarrior and/or taskwarrior will find this module useful.

Reason... `timewarrior` is a serious tool. More serious than tools like `hamster`. It's the only the serious real `time`-related tool I know of... and is not a small command line, related to and can work with `taskwarrior` via [on-modify](https://taskwarrior.org/docs/timewarrior/taskwarrior.html) hook script.

`timewarrior` module is going to be used to display times in same way `taskwarrior` module is going to be used to display tasks. I wanted to remove the shoehorned button functionality to keep it clean.

2) Merge #1499 to revert commits and merge missing commit. Basically, we get period back and see what we're going to use it for... as well as keep displaying fake nonexistent keys on invalid formatting placeholders. Let them die at someone's discretion.

3) lm_sensors is finished and tested. This solved 2 issues too #1315, #1354. I gave explanations and examples relating to None in that it print {input} instead of None for users with alarm/intrusion (only in default) or with different placeholders because of{None:.2f}.

This module will be useful for rest of AMD users as well as other users. It's also long overdue in a sense that many users already have more than one core sensor for a long time and flawed `sysdata` only can print the first `CPU` core sensor, not all cores. This exposes everything and users who tried this already probably can confirm this.

I have a workaround in mind that we can use... Use `{input}|\show None` instead and would only work with default `format` which is probably good enough as most users will only want to use `{input}`. This issue revealed that if users made mistakes, we could be silent about it.

 Also because we hadn't addressed `{None:.2f}`. Do we want to be silent about it or not? #1477

4) Reiterate this issue again after we addresses the issues above.

5) @ultrabug gets blackstar-ed one more time on nvidia_temp (?)... citing a module cull in the near future. And if you hadn't hate me yet, you should now... I think it would be easier for users to relate with percents (ie {memory.used_percent}) instead of {memory.used} in nvidia_smi as well as in other modules too. Users with beefy hardware might not find that useful (ie very low percents), but is still more relatable over precise statistics (ie 312 MiB).

[tobes]

from @lasers comments

1) I still think we should just remove this module till we decide what to do

2) #1499 is a mess and must not be merged - I'm happy to revert the bad commits but I think the risk is too high - and they are possible to back out of - even if they should never imho have been merged because changing core because your module is broken is always the wrong fix (don't get me started on this)

3) lm_sensors is not ready imho it is ill thought out and overly complex for what is either trivial or needs a massive think of how we do formats. Anyhow I do not consider it production ready

5) no - we are in a freeze - if you keep needing to change modules you created because they were ill thought out then this just shows that maybe this will keep happening and maybe we should not merge stuff just because we can. and changing a broken placeholder for another broken one helps nobody.

Anyhow it is the morning .... @ultrabug your call have fun

[ultrabug]

Having functionality in modules that no-one is using (or having entire modules without real users) is strange indeed,

I agree with you and I think we all overreact and over rely on the formatter, that you know both dear collaborators :)

I wonder if it makes sense to make some kind of revision and determine which modules are not being used at all by core contributors.

This is an old project of mine, a sort of telemetry module that users could load to report their usage anonymously if they wish to participate

I still think we should just remove this module till we decide what to do

Looking at Maxim's comment and since this looks to be blocking a release, I think we should put them aside and move on as well

@lasers that means that I'd like us all to accept to disagree but commit on the release and thus:

1. leave timewarrior as it is
2. stay put on any other formatter / module change

So for now, I will wait for tomorrow for any last resort comment: if something is unbearable to any of you, get to me on IRC not on github.

We're in the process of setting up a new collaboration, those discussions are important and a good sign even if they're frustrating and tense sometimes.

With <3

[tobes]

over rely on the formatter,

I have been trying to push back on this since the beast was born.

freenode no longer allows anon access :( so I'll miss the chat

[lasers]

I'm online there now. Just got on. Make an account or something.

[tobes]

Make an account or something.

actually freenode is ok I just can't join #py3status which is sad :(

[lasers]

Screw that place. We'll make our own... Join ##py3status instead.