search

wbond / package_control

The Sublime Text package manager
https://packagecontrol.io
4.77k stars 816 forks source link

How to replace an unmaintained package #1607

Closed Enduriel closed 2 years ago

Enduriel commented 2 years ago

The Squirrel package in Package Control hasn't been updated in 5 years, and uses the older system of language syntax definition (.tmlanguage), on top of that it isn't able to properly identify all aspects of the language properly (in too many ways too list). I worked on fixing all of this in my 'fork'.

I've tried to get in touch with the current owner of the repository (IAmRoland) about updating the repo via email, but they haven't replied to my email after 2 months and I can't find any activity on any of their social media profiles for years.

Would it be possible to have the package be changed to instead use my repository? What's the process I should follow for this? I've read the docs so I know how to go about adding a new package but don't want to contribute to bloat if I don't have to.

chrisspiegl commented 2 years ago

I have a feeling, that right now the only option you have is to publish a new package (as has been done by many others).

Ideally, it would be great if the PackageControl system would support some kind of "deprecated" or "unmaintained" state.

But then again, this would probably depend on the original maintainer to add this indicator which usually does not happen.

But a new way of doing things could be introduced, like for example a "consensus package state" like "unmaintained" / "deprecated" / "active" / etc based on some sort of community consensus?

Alternatively, I have seen that projects are marked "unmaintained" if they have not been updated in a certain amount of time.

Now, I understand that just because something has not been updated in a long time does not mean that it would not work, but it is an indicator that it is unmaintained. If the person who created it just updates the package — let's say — once every year, then it would not go tot he "unmaintained" section?

To me, that feels like it would be a good solution.

rchl commented 2 years ago

There is a process that was used many times in the https://github.com/wbond/package_control_channel/ repo. For example, just some random one that I was able to find is here https://github.com/wbond/package_control_channel/pull/5346.

Basically the original author is given a week or two to respond and if he/she doens't, the package can be replaced.

Enduriel commented 2 years ago

Yeah that looks perfect, I'll take a look at doing that when I have some time, thanks a lot.

idleberg commented 1 year ago

Sorry for bumping this thread, if it's preferred I'd open a new one, but then again this is more of a response and not a software issue.

There is a process that was used many times in the wbond/package_control_channel repo. For example, just some random one that I was able to find is here wbond/package_control_channel#5346.

Basically the original author is given a week or two to respond and if he/she doens't, the package can be replaced.

Frankly, I'm shocked about this procedure and have some strong security concerns about it. Sure, I understand that Package Control is a curated collection of packages, but I don't think anyone has the means to know an author's intentions. Any user of a package will have to decide on subjective reasons that he or she wants to trust the work of a package author. When that author changes that trust needs to renewed (if you really think about it, you'd even have to renew trust with any new version, regardless of its author!)

As a package author, I'd love to see someone else carry on my work and there might be cases when I know I can trust someone to do just that. In any case, I'm obliged to communicate a change in the project. However, I think a proper deprecation is the better way. To give an example from outside the Sublime Text universe: in VSCode a package can be deprecated with a recommendation for another package. Users can continue using the deprecated package or decide to change to a fork (or some other replacement).

The bottom line is, that you can't simply replace a package without notifying its users or giving them the option to decline. Security is the main concern here, but there are other valid cases why a user doesn't want a third-party to meddle with his preferences.

FichteFoll commented 1 year ago

This is a valid concern that we should indeed discuss, but not on this repo. Would you mind opening a new one on the PCC repo? (I'd recommend a discussion, but we don't have those there.)