Broken repo after update to new version


I wonder if anyone has the authority to roll back a repo to the previous version.

In this case, the mod, the admin, or whoever owns (is that the right word?) the project, introduced changes that in the latest version/release break the software.

I’m not going to mention any names here. I don’t necessarily want anyone to get into trouble. Suffice to say that the project in question is fairly popular and has existed for many years.

It is defunct as of about 10 days ago, because a maintainer, perhaps unwittingly , added code that broke it. What can I do?

Note: I reported it as an issue (#150) yesterday in the main branch of the repo, however it goes beyond an issue.


Just a footnote. Actually, it may go back a little further. Tampering, for lack of a better term, seems to have started about two months ago.

I’d probably start w/:

If you think that the project has been attacked / compromised, hopefully they can do something.

I think the current person who maintains the project and has been a contributor in the past did something very irresponsible.

While I’m trying to see if there is any way of fixing the code without rolling back and at the same time trying to get in touch with the person via the issue, failing in both, I don’t know what to do. Github support – maybe. I hope that it doesn’t come to that. It would be uncool.

The interim thing is to work in a fork, possible without that commit.

Good luck

@tnbnicer did that person force-push any branches? If not you can roll back any changes yourself easily with just Git operations. Reverting a commit - GitHub Docs

In the last two months there have two commits, or releases, on the main branch.

It wasn’t forced.

There is a changelog too, in which the modifications are explained. To be honest, I’m slowly working towards comprehending the changes, much of it by trial and error. CSS code is incomplete, but once you realize this and insert styles, the project seems less broken.

The best I can do is to comment and make suggestions for a simpler route. There was one, imo. I think the suggestion to use an older fork is probably the one for me, although I don’t like being old-fashioned.

The support categories don’t provide much scope for reporting a “maintainer”.

Reporting abuse or spam
• Reporting a user
• Reporting an issue or pull request
• Reporting a comment
• Reporting an app in GitHub Marketplace

The changes the maintainer commits are damaging. The project is being compromised and all we can do is sit back and watch? Enjoy the show!

How do you get rid of the maintainer?

Not the least of my grievances is that the person who now controls the project will not respond to issues which point out where he/she (‘he’ probably) has gone wrong.

I submitted a pull request that would fix distorted icons, for example – the tip of the iceberg – underlying the distorted icons is a mysterious polyfill added recently. No reply.

I could draw up a list of defects based on the maintainers activities these past two months, but who can I send such a list to? A technical list.

Would Github do anything? Is there anything Github can in fact do?

You don’t. Making bad technical decisions isn’t against GitHub’s TOS. If the new maintainer was abusing trust in the project to spread malware or something it’d be different.

Assuming the project is under a proper Open Source license, what you can do is to create your own version (commonly called “fork”, not the same thing as GitHub forks). Start from a point in Git history you consider good, port fixes, make your own improvements. You should probably choose a new name, being clear which is which is important. Of course it’s best if you don’t do it on your own, let people know what you’re doing, and if they agree your version is better, users and contributors might switch over.

I know from experience that maintaining a software project is a lot of work, and I get it’s frustrating to see a project you like run into a bad direction, but unless you’re paying the maintainer it’s essentially “take it or leave it”.

How do you get to be a maintainer? Who elects you? Isn’t it possible for the same wheels to be set in motion to elect a new maintainer?

I would not be standing, because like you said, maintaining a project is a lot of work. I believe you. The direction this project appears to be taking is perdition. Supposedly, it’s in the name of WCAG 2.1.

To be […] compliant we had to introduce breaking changes. [endquote:]

The main problem for me is optical. Distorted and misaligned icons, and ‘smaller’ buttons, chopped-off SVGs, prevent upgrading. So are we going to turn a blind eye to it? Yes, I take it.

That depends on the project. In the simplest case: I start a project (whether from scratch or as a fork), so it’s me. :slightly_smiling_face:

Sometimes the responsibility is transferred, for example because the previous maintainer didn’t have time any more and someone else they trusted was willing to take over. In that kind of situation the maintainer change is a matter between the people involved: Others may have and voice their opinions, but can’t decide other than whether to keep using the software.

It gets a lot more complicated if an organization is responsible for a project, whether a non-profit or a company. In that case the maintainer (or maintainers, for a large project or redundancy) probably has responsibilities towards that organization, and you could try to talk to appropriate people at that organization, and let them know what you think is going wrong.

Unless the project you’re talking about is owned by GitHub, GitHub is simply not in charge of that. They’re only hosting the repository (and possibly providing other services), and not responsible for decision making within the project.

It is a fairly well-known project. The turn of events surprised me. There is still time to rescue the next release. In a week or a month, … tomorrow.

My hope is that will turn out to be the case. I believe the project doesn’t have a direct sponsor. Maintaining it is, for all I know, on a first-come-first-serve basis. A maintainer wanting to quit might also contact you, if you made contributions.

Thank you for encouraging me.

1 Like