[meta] Project maintainer wanted

[formatc1702]

As you may have noticed, I have not been able to work on the project or even engage in discussions here for a while now. Due to shifting interests, limited time, and other factors, I currently cannot maintain WireViz at the level I feel it deserves.

Therefore I am open to talking with anyone interested about handing over the duties as main project maintainer. Obviously my first priority would be somebody out of the existing contributor pool. Anyone interested please reach out here (preferred for transparency), or privately via the e-mail in my user profile.

We would need to figure out how exactly the delegation should happen.
The two alternatives that come to mind are full control over the mainline repo, which would require a very high level of trust, or defining a straightforward process of submitting finished, tested* and documented PRs that I can simply green-light and merge.
(* Ideally tested by another contributor)

My hope is that losing the burden of being the primary maintainer could help me re-engage with the project in a different way. I have ideas for future features and certain wishes for the "look&feel", which I would like to share but do not have the energy and resources to commit to implementing and testing myself.

I look forward to any comments.

As a separate point, I would like to thank @kvid for their active involvement in responding to other users' issues, and past efforts in reviewing PRs. 🙏

[kvid]

Thank you, @formatc1702 for describing your situation and suggesting different paths to bring this project further. I've not been as active as I want myself either lately, but I'm willing to help as long as the tasks don't get too big. The number of changes in #251 is a bit overwhelming, and I therefore have not been able to get the oversight that I feel is needed to make a proper review. What is the minimum effort needed to merge this large PR into dev to avoid it blocking other PRs, and how can we all join our efforts to fulfill the needed steps?

[formatc1702]

I had been testing the refactored code using the existing examples and demos, as well as some other test files, and it appeared to be working fine except for some particular points marked as TODO in the code. I would need to play with the code again after all this time to give a particular example.

The changelog needs to be updated. I want to get rid of the changelog branch and go back to updating CHANGELOG.md within each PR again.

Currently the code history is dev -> latest -> big-refactor, roughly speaking.

I would be comfortable with merging latest into dev asap, without further review, and updating the changelog accordingly, since this is simply a stack of multiple cleanly separated PRs independent of the refactoring.

Afterwards, personally I would also be fine with merging big-refactor into dev; it is a development branch, after all. This would expose it to all collaborators to have a look at any bugs. I have updated __init__.py to reflect the large change via an interim version number 0.4-dev-refactored (was 0.4-dev) in order to understand whether any subsequent bug reports are based on the refactored code.

It might feel a bit ugly to offload the burden from me onto others to clean up in the refactored branch, but it would lift a weight off my back knowing that this could get the ball rolling again. I realize the changes are a bit overwhelming when thinking about it as a diff from the previous code. So the best way to get familiar with the "new order" will probably be to step through the code using one of the known example YAMLs (pudb is great for stepping through code!) and hopefully seeing how everything fits together.

[amotl]

Dear Daniel and @kvid,

thanks for creating this community request. I will be happy to step up as a co-maintainer, in order to support the project on corresponding tasks, to hopefully give you some amount of breath on them, and to bring back the fun in working on this project together.

We've conducted similar operations in the past ¹²³, and I hope to be able to apply the same kind of maintenance to WireViz. In order to proceed hands-on with that, I suggest to transfer the repository into an organization you, @kvid, and humble me has administrative permissions on. We did that recently at ⁴ without further ado, it worked well, and even attracted others to add their projects to the same organization ⁵.

It might feel a bit ugly to offload the burden from me onto others to clean up in the refactored branch, but it would lift a weight off my back knowing that this could get the ball rolling again.

If you see any chance to integrate GH-251, please do ⁶, and let us sort out the aftermath. Don't worry about offloading the burden ⁷, I think it will not be too big at all ⁸.

With kind regards,
Andreas.

Footnotes

1. https://github.com/mqtt-tools/mqttwarn ↩

2. https://github.com/panodata/grafana-client ↩

3. https://github.com/xmpppy/xmpppy ↩

4. https://github.com/mqtt-tools/mqttwarn/issues/389#issuecomment-1537451614 ↩

5. https://github.com/mqtt-tools/mqttwarn/issues/665 ↩

6. Unless there are any strong objections, of course. ↩

7. I think your patch has been carefully engineered, and deserves to be merged into mainline. Also, it will not break anything for users, because they probably consume the Python package on PyPI. At least, they should ;]. ↩

8. If you think differently, please outline specific details you are worrying about. ↩

[amotl]

Hi again,

I've just created the wireviz organization, invited both of you as members with ownership permissions, and already transferred the WireViz-Web repository.

GitHub will employ corresponding redirects, both on HTTP and Git+SSH level, so transferring a repository to another organization will not break anything for anyone at all, and can be conducted any time.

With kind regards,
Andreas.

[kvid]

I think what @amotl suggests sounds like a solution that is worth considering, but @formatc1702 has to make the final decision. If accepting, he might want to specify some "base rules" about certain type of changes that he reserve the right to approve.

[formatc1702]

Thank you for your replies. I am very open to transferring WireViz to the organization, I think it is a great idea.
I am currently traveling but I will arrange the transfer once I am back.

[formatc1702]

The transfer to the WireViz organization is complete. Everything else will follow after my trip.

I give @amotl and @kvid green light to work on the code in the meantime if they so please; I'll be sure to sync up before resuming work.

[formatc1702]

I have taken some first steps to get things moving and sorted.

• Move dev forward to include all PRs formerly labeled as in-latest. The label is now obsolete.
  Since some PRs them had some good discussions that were not 100% resolved, I link them here for reference:
  • Embed images in SVG output #189
  • Improve output of diagram + BOM as technical drawing #239
• Update CHANGELOG.md and kill the changelog branch (Changelog #228). New features should update the changelog directly instead.
• Rebase the refactor/big-refactor branch onto the latest dev (Large scale refactoring #251)

How shall we proceed? I will quote my initial comment:

[...] personally I would also be fine with merging big-refactor into dev; it is a development branch, after all. This would expose it to all collaborators to have a look at any bugs. [...]

[...] the best way to get familiar with the "new order" will probably be to step through the code using one of the known example YAMLs (pudb is great for stepping through code!) and hopefully seeing how everything fits together.

In other words, I am pushing a branch that is 90% finished but needs some good polishing, onto the greater collaborator community.

Thanks so much for your support.

[kvid]

@formatc1702 wrote:

I have taken some first steps to get things moving and sorted.

• Move dev forward to include all PRs formerly labeled as in-latest. The label is now obsolete.
  Since some PRs them had some good discussions that were not 100% resolved, I link them here for reference:

  • Embed images in SVG output #189
  • Improve output of diagram + BOM as technical drawing #239

Very nice!

• Update CHANGELOG.md and kill the changelog branch (Changelog #228). New features should update the changelog directly instead.
• Rebase the refactor/big-refactor branch onto the latest dev (Large scale refactoring #251)

• Large scale refactoring #251 still has the latest branch as base branch, but dev is currently 10 commits ahead of latest (and refactor/big-refactor is on top of 9 of them). Should we therefore move the latest branch 9 commits ahead to include all commits that now are both in dev and in refactor/big-refactor, and thereby correctly identify where they branch off, or is it better to change base branch to dev in Large scale refactoring #251?

• The 10 latest commits include adding entries for v0.3.1 and v0.3.2 into CHANGELOG.md, but the actual code commits for these hotfix releases are currently not yet included in dev. Should we just cherry-pick these two code hotfix commits into dev, or do you prefer merging master into dev?

How shall we proceed? I will quote my initial comment:

[...] personally I would also be fine with merging big-refactor into dev; it is a development branch, after all. This would expose it to all collaborators to have a look at any bugs. [...]
[...] the best way to get familiar with the "new order" will probably be to step through the code using one of the known example YAMLs (pudb is great for stepping through code!) and hopefully seeing how everything fits together.

Are you mainly worried about known bugs and TODOs already documented in the #251 code, or unknown stuff due to lack of testing?

In other words, I am pushing a branch that is 90% finished but needs some good polishing, onto the greater collaborator community.

In your opinion, what are the known major shortcomings of refactor/big-refactor?

I can see that in your list of addressed issues, #224 and #226 are the only ones not checked. Does that mean they represent the major remaining work, and that all the checked issues are more or less finished? Or does it rather mean that the unchecked issues can be moved to a future PR?

[formatc1702]

Should we therefore move the latest branch 9 commits ahead to include all commits that now are both in dev and in refactor/big-refactor, and thereby correctly identify where they branch off, or is it better to change base branch to dev in #251 ?

I would rather change base to dev on #251 and get rid of the latest branch, since I don't see a use for it anymore. Could you please give this a go?

• The 10 latest commits include adding entries for v0.3.1 and v0.3.2 into CHANGELOG.md, but the actual code commits for these hotfix releases are currently not yet included in dev. Should we just cherry-pick these two code hotfix commits into dev, or do you prefer merging master into dev?

Please cherry pick them to avoid tangles. And add equivalent changes to refactor/big-refactor to avoid a regression on these fixes.

Are you mainly worried about known bugs and TODOs already documented in the #251 code, or unknown stuff due to lack of testing?

Mainly the former. There will always be more bugs to find, and I don't mind post-hoc bugfixes, but it would be nice to solve the known TODOs, at least the ones that can't be easily handled as separate PRs afterwards.

In your opinion, what are the known major shortcomings of refactor/big-refactor?

I can see that in your list of addressed issues, #224 and #226 are the only ones not checked. Does that mean they represent the major remaining work, and that all the checked issues are more or less finished? Or does it rather mean that the unchecked issues can be moved to a future PR?

What I can think of off the top of my head, and going through the TODO comments in the code is the following:

Issues that should be solved within 251:

• BOM hash for bundles, where each wire has to become its own BOM entry.
  • See wv_dataclasses.py->def bom_hash(self):
  • See wv_harness.py->def _add_to_internal_bom(self, item: Component)
• quantity multipliers for wire terminations.
  • See TODO in wv_dataclasses.py->def compute_qty_multipliers(self)
• PN info rendering for additional components.
  • See TODO in wv_graphviz.py->def gv_additional_component_table(component)

Issues that can be moved to future PRs:

• Improving additional component display, BOM item numbers #224 and Better additional component BOM table #226, dealing with improved BOM modes, BOM bubbles, etc. See comment in wv_bom.py: # TODO: different BOM modes
• other TODO comments

Can you take care of the first points (change base, cherry pick 0.3.1 and 0.3.2 changes into dev, implement equivalent changes in big-refactor), and let me know? Thanks.

[kvid]

Can you take care of the first points (change base, cherry pick 0.3.1 and 0.3.2 changes into dev, implement equivalent changes in big-refactor), and let me know? Thanks.

I have now cherry-picked v0.3.2 changes into dev (v0.3.1 changes seem no longer needed) and fixed a couple of minor issues. Then, I rebased refactor/big-refactor on top of dev (with one conflict easily solved) and force-pushed it. Finally, I changed base branch of #251 to dev. Edit: As I had to retry the force-push, the order of the two latter actions got swapped.

I hope my rebasing+force-pushing doesn't create problems for any local uncommitted or un-pushed changes you might have. We can always undo it if needed.

[kvid]

My force-push of refactor/big-refactor half an hour ago had apparently failed, so I had to retry, and now it seemed to work. However, the following automatic "build" process fails with this error:

/tmp/pip-build-env-0ucy1ahg/overlay/lib/python3.8/site-packages/setuptools/dist.py:509: SetuptoolsDeprecationWarning: Invalid version: '0.4-dev-refactored'.

Is this just because of your temporary nonstandard version format?

[formatc1702]

Thanks for your effort.

I am not sure for the reason of this error. Previous version formats, including 0.4-dev worked fine, and nothing else has changed in the pipeline, so perhaps it's the double -? Feel free to change the string to e.g. 0.4-devrefactored or even 0.5-dev if you want, to see if it has an effect.

[kvid]

It seems "-dev" (normalized to ".dev") should only be directly followed
by a number for different deveopment releases of the same version.
See full description: https://peps.python.org/pep-0440/

I pushed commit 0b9af8d using 0.4-dev251, and the first 4 scripts succeeded, but the 5th hasn't completed yet...

[sb424dat]

Hi there! I really like this repo and would like to contribute! I have plenty of wiring experience but am trying to get better at my programing.

I plan to start looking at the issues and see what I can work on.

[formatc1702]

@sb424dat thanks for offering! I will try and go through the list of issues soon to see which one could be a good starting point.