Project status?

[cyqsimon]

The latest release cannot be built now due to a dependency issue: #258. Are there plans to continue maintaining this project @imsnif ?

If for whatever reason you cannot spare time to maintain this project (which is of course understandable - everyone's availability and priorities change), I would like to volunteer to at least passively maintain this project, which is to say not to add new features, but at least make sure the latest release will build using the latest version of rust. And maybe fix some bugs if I have the time.

If you have someone else you would like to entrust that's okay too. I just don't want to see a good project become abandonware and all the effort go to waste. Much thanks.

[cyqsimon]

For context, I maintain a build of bandwitch at https://copr.fedorainfracloud.org/coprs/cyqsimon/el-rust-pkgs/. I noticed the build failure a few days ago during a mass rebuild.

[imsnif]

I indeed do not have a lot of time to maintain this project these days, unfortunately.

However, giving maintainership to someone else (especially someone I do not personally know) can have grave consequences. Even if there is no malicious intent, what often happened to me in the past is that a very well-intentioned person would take on a project only to abandon it themselves a few weeks or months later.

They would often do that by leaving the project in an even more broken state than it began - and then it would fall to me clean up afterwards... on a project I did not have time to maintain to begin with.

So, while I very much appreciate your intentions and willingness to help out... why not fork?

[cyqsimon]

However, giving maintainership to someone else (especially someone I do not personally know) can have grave consequences.

Understandable. Nobody should feel compelled to put their trust on an internet stranger to do a good job, whether that be me or anyone else.

why not fork?

In one word, fragmentation. If you (or someone you trust) decides to again pick up development and/or maintenance on this repo again a few months later, it will put any maintained fork in an awkward position. Therefore I only consider forking as a last resort (e.g. if the owner is actually MIA).

[cyqsimon]

Just to be clear, if you can confirm that you're unlikely to continue maintaining this project and are unwilling to delegate a maintainer in the foreseeable future, I'm happy to go ahead and make a fork. I guess I'm just looking for some semblance of certainty in order to avoid wasted work.

[imsnif]

I get where you're coming from and can empathize with your situation, doubtless with the situation of others who wish to use this software. However, while it is very unlikely that I will pick up maintenance of this project in the future - it can certainly happen that someone will hire me to do so (just to give you an example).

It saddens me that rust introduced this breaking change in a non-major version (at least this seems to me like what happened from a cursory reading of the links) - but I guess mistakes happen.

[jcgruenhage]

@cyqsimon If you end up do forking, can you ping me about that? I'm not interested enough myself to actually go through with a fork (I'd switch to nethogs or jnettop probably, but bandwhich is nicer than either of those), but as the maintainer of the bandwhich package for Void Linux, I have to at some point remove the package because the upstream project is dead (at the moment) and doesn't build on our current Rust toolchain, unless there's an actively maintained fork that builds. I've done what's required for it to currently build and work properly over in #265, but without that merged and released, the downstream update for this probably won't land.

rust introduced this breaking change in a non-major version

While this is a change that broke something, the breakage happened because crates relied on the internal layout of stdlib types, which are not part of the public API. I think the change is good, and breakage here was unfortunate, but easily resolved with a few dependency bumps, so it's not as big a deal - breaking this in a minor version would therefore be fine in my opinion.

Aside of that though: Fully understand that you currently don't have the capacity to work on this, and I hope my comment doesn't come over as disapproving of that. Open source maintenance can be a very thankless, yet time consuming job. Therefore, I want to make it a point of thanking you for the large amount of work you've poured into both bandwhich and also zellij so far!

[imsnif]

While this is a change that broke something, the breakage happened because crates relied on the internal layout of stdlib types, which are not part of the public API. I think the change is good, and breakage here was unfortunate, but easily resolved with a few dependency bumps, so it's not as big a deal - breaking this in a minor version would therefore be fine in my opinion.

I disagree with this strongly, which is why I'm going to take a moment to reply because I find this important.

Breaking changes should be defined by the people using the software first and foremost. If the software author made a change and it broke something - it is a breaking change. It doesn't matter if it's big or small, it doesn't matter how hard or easy it is to fix it. It's the author's responsibility to avoid it if possible or to fix it if not.

I very much respect and agree with what you've said about maintaining open source software. Which is why I am not upset with whoever made this change or think they owe me anything. I just feel it's important to lay the responsibility for it where it belongs.

I feel the basic contract between me and my ecosystem is that if I build a piece of software in a stable ecosystem and leave it be, it should continue working within that ecosystem (barring major versions, etc.) if the ecosystem is stable. Rust is post 1.0, so I as a software author had this expectation.

On a side note: how long a change takes to implement is very much relative and subjective. This project for example has accrued a sizable amount of technical debt in its CI. any change here would mean overhauling the CI, which is in itself quite a big change. Not overly complicated, but something I personally have to do (because I would later be responsible for it regardless of who did the work). So... no, this is not a small change.

And to reiterate: while I feel strongly about this subject as I mentioned, I am not blaming anyone or think anyone is at fault or did a bad thing. Just mentioning who in my opinion bares responsibility here.

[jcgruenhage]

I feel the basic contract between me and my ecosystem is that if I build a piece of software in a stable ecosystem and leave it be, it should continue working within that ecosystem (barring major versions, etc.) if the ecosystem is stable. Rust is post 1.0, so I as a software author had this expectation.

I'm not saying it's not a breaking change, it certainly is, but it's a breaking change of a part that was never supposed to be used, that wasn't part of the public API, and the things that did rely on this internal detail and therefore broke here were pnet and socket2, both of which were not and still are not stable. But I don't think we'll end up agreeing here, so I'll stop arguing on that topic after this reply here.

This project for example has accrued a sizable amount of technical debt in its CI. any change here would mean overhauling the CI, which is in itself quite a big change.

That's a choice you're making though, and it doesn't have to be this way. The dependency bumps could very well be merged and released without overhauling the CI. But your project, so your choice, and as I said before, I don't want to nor would I have the right to dictate how you work on this project. The reason I'm mentioning this is because you're stating it as if it were a fact, while it is a choice IMO.

And to reiterate: while I feel strongly about this subject as I mentioned, I am not blaming anyone or think anyone is at fault or did a bad thing. Just mentioning who in my opinion bares responsibility here.

Very well put, fully agree on this bit :)

[imsnif]

I'm not saying it's not a breaking change, it certainly is, but it's a breaking change of a part that was never supposed to be used, that wasn't part of the public API, and the things that did rely on this internal detail and therefore broke here were pnet and socket2, both of which were not and still are not stable. But I don't think we'll end up agreeing here, so I'll stop arguing on that topic after this reply here.

Fair enough - but breaking changes do not only happen in public APIs. I expect any breaking change to either be accompanied with a major version bump or to be remedied when pointed out to unbreak the broken parties. Whether this choice is made or not, is the purview and responsibility of the breaking party - not the consumer.

That's a choice you're making though, and it doesn't have to be this way. The dependency bumps could very well be merged and released without overhauling the CI. But your project, so your choice, and as I said before, I don't want to nor would I have the right to dictate how you work on this project. The reason I'm mentioning this is because you're stating it as if it were a fact, while it is a choice IMO.

I don't think this really is a choice. Coming back to a project that I have not maintained in years and merging changes sight unseen without running the CI is irresponsible. Honestly, I don't even remember the explicit (not to mention implicit) tests the CI makes. Saying this is equivalent to saying you expect me to place an unknown amount of work into the project over an unknown period of time - it is probably less work to "just" rebuild the CI and thus continue maintaining the project.

Very well put, fully agree on this bit :)

Thank you for having a respectful disagreement! I think this would serve as good information to anyone who wondered what happened with this project.

[imsnif]

@cyqsimon - still interested?

[cyqsimon]

Oops this is a bit embarassing. I completely forgot about this entire matter after I patched the build locally.

I'll go ahead and push said changes to my fork. Also IIRC one of the dev dependencies needed patching too. I will investigate that.

[imsnif]

@cyqsimon - I had a change of heart. Are you still interested in taking up maintainership of this tool?

Since I had bad experiences with this in the past as I mentioned above, I'm going to ask:

1. Will you keep this tool working, as much as you can and your schedule permits?
2. If for some reason you cannot do 1 anymore, will you communicate it and make an effort to not leave things in a worse way than they are now?

While I of course cannot hold you to any of this, this pledge will at least help me do this with a calmer heart. I hope you do not take this personally, this has nothing to do with you and everything to do with my past experiences in the matter. The fact that you're still around and interested after a few months of opening this issue very much acts in your favor. :)

[cyqsimon]

Are you still interested in taking up maintainership of this tool?

Of course. If a few months is enough for me to retract my offer, I wouldn't have bothered in the first place.

1. Will you keep this tool working, as much as you can and your schedule permits?

IIRC I spent a total of about 5 hours familiarising myself with the codebase, updating all dependencies, and fixing everything to the point where cargo clippy is happy. While it would indeed require lots of spare time if I want to do things like fulfill feature requests, I don't think it would be difficult for me to perform passive maintenance. So yes, I believe I am able to keep bandwhich in working order.

2. If for some reason you cannot do 1 anymore, will you communicate it and make an effort to not leave things in a worse way than they are now?

For a project with this much attention, I think it's a good idea to have more than one maintainer regardless. So I will be looking to build a team of trusted individuals. When eventually I am no longer able to effectively maintain bandwhich anymore, my hope is that my departure will be a rather insignificant event.

I hope you do not take this personally, this has nothing to do with you and everything to do with my past experiences in the matter. The fact that you're still around and interested after a few months of opening this issue very much acts in your favor. :)

I get it. I would be hesitant too if I'm in your position. Thank you for considering the offer at all.

[imsnif]

@cyqsimon - I am very happy to hear! I just invited you to the GitHub repo, if you give me your crates.io username I'll also add you there so that you can publish versions.