Package Control: A full-featured package manager

[Anomareh]

Just someone indicating they use it and that is seems to be the best and most actively developed version. From the conversation that has happened here is appears that the Kronuz fork is most actively developed, so I'll add it to the master channel list.

That's kind of messed up, but whatever I guess.

[wbond]

Just someone indicating they use it and that is seems to be the best and most actively developed version. From the conversation that has happened here is appears that the Kronuz fork is most actively developed, so I'll add it to the master channel list.

That's kind of messed up, but whatever I guess.

I'm certainly open to improving this process. What about the current process do think is messed up?

[Anomareh]

I'm certainly open to improving this process. What about the current process do think is messed up?

One person saying something and acting on it without the repos in question even being looked at.

For one, the Kronuz fork should probably be the aparajita fork at this point as the last month worth of commits have pretty much just been merging his pull requests. Secondly, that fork probably shouldn't be a fork anymore.

Also I'm not really sure what conversation happened that would affirm the Kronuz fork was the one to go with. aparajita said twice that it was the most actively developed, two people said they weren't using it or sure about what it actually was, and I gave my impression.

Just seemed rather hasty to me.

[wbond]

I'm certainly open to improving this process. What about the current process do think is messed up?

One person saying something and acting on it without the repos in question even being looked at.

For one, the Kronuz fork should probably be the aparajita fork at this point as the last month worth of commits have pretty much just been merging his pull requests. Secondly, that fork probably shouldn't be a fork anymore.

Also I'm not really sure what conversation happened that would affirm the Kronuz fork was the one to go with. aparajita said twice that it was the most actively developed, two people said they weren't using it or sure about what it actually was, and I gave my impression.

Just seemed rather hasty to me.

Point taken, I'll be sure to be slower before adding repositories that have more than one copy. I did spend a little bit of time looking at the various forks before I added it and also checked out https://github.com/lunixbochs/sublimelint/network. I also weighed in your and aparajita's comments. That said, I do think you have a valid point and appreciate you speaking up.

Due to the way that the versioning in Package Control is done, it is actually possible to switch the repository being used for a package at any given time as long as it was pushed after the date the previous repository was pushed.

[Anomareh]

The only reason I really took issue with it is I know what it's like to want the light version of something and ending up having to go digging around for it. This happens to be one of the occasions that I actually want the heavier version but many a time have I had to either pull apart something to rip off all the stuff I don't want or go looking for the version where someone has already done it for me.

Personally, I think the ideal solution would be making both versions available, ideally with the fork being split into a new package entirely (SublimeLint+ or something) or being made available as a dev release.

[wbond]

Personally, I think the ideal solution would be making both versions available, ideally with the fork being split into a new package entirely (SublimeLint+ or something) or being made available as a dev release.

That is potentially a good idea for the next version. Right now it is not possible to map the names of individual repositories, just all repositories of a specific name. If I add the ability to map names on a per repository basis, then it would be possible to have both without any changes to the repositories.

Perhaps a better idea that would be clearer to users would be for the fork to rename itself. This would obviously require buy-in by the developer.

It is possible right now to add your own custom repositories to allow someone to use the original, but this doesn't help solve the discoverability problem for people. It would, however, allow for easy updating.

[aparajita]

My sincere apologies to everyone. I was only looking at the commit histories to see which had been more active recently -- whether or not those commits were from me.

For one, the Kronuz fork should probably be the aparajita fork at this point as the last month worth of commits have pretty much just been merging his pull requests.

I don't want to create yet another fork of the project, nor do I want to be primarily responsible for maintaining it.

Secondly, that fork probably shouldn't be a fork anymore.

Probably not. I haven't looked closely to see what the essential differences are between the forks. Ultimately it would be nice if the forks could be unified somehow.

[aparajita]

I actually prefer the original version: it's responsive, less noisy and seems to have less quirks.

If that's true, I'll switch!

What do you mean by "less noisy" and "less quirks"?

[aparajita]

Version 1.1.0 of Package Control was just released for upgrade.

Great work, thank you for making this available.

I want to submit a new package for inclusion in the package repo, how do I go about it?

[Anomareh]

I don't want to create yet another fork of the project, nor do I want to be primarily responsible for maintaining it.

Heh, you already are :p You've been the only one pushing commits to the fork for the past month. Only difference is you're sending pull requests instead of just committing.

Probably not. I haven't looked closely to see what the essential differences are between the forks. Ultimately it would be nice if the forks could be unified somehow.

I don't think this is possible. Although they seem very similar on paper, internally they are rather different. The original is much stabler and snappier. With the fork everything config wise is quite different.