Sublime Forum

What's happening to package control repo

#1

Package Control Channel Repo has over 80 pull requests and some of them are over two months old.
What’s going on? Is it that the team is busy with other stuff, or there’s another plan. I’ve seen small packages (pull requests) are getting merged every now and then but not the others!

2 Likes

#2

TL;DR: It’s not fun and after 3 years I became sick of it.

I do intend to work a bit on the backlog today however.

5 Likes

#3

I understand that the current methodology is to hold a high standard, but if it is burning people out, and it is difficult for people to get to the back log, should we lower the standard so that getting packages on Package Control doesn’t take months?

Also, automation would really help this (I realized this has been stated before), but what exactly do the maintainers do? It would be nice to see a list as maybe people can come up with a way to automate this if the official team is too busy to look at automation.

I think Package Control probably shouldn’t be reviewing the authors packages directly except in the context of Package Control integration. At times I have seen in depths reviews of the author’s packages to be added, but I wonder if that is too much and contributing to people getting burned out. Really, I think if an author adds their package and it’s functionally broken on release, that should be a job for their issues. We can review to make sure everything is working and working well, but they could easily break it right after release making the effort moot.

I’m just trying to open up dialog.

1 Like

#4

there’s a link to the review guidelines in the original post

yep, I said the exact same thing :slight_smile:

0 Likes

#5

Thanks @kingkeith! I overlooked that link. Yeah, that is quite a bit to do on every request. I can see how people get burned out on it. I can also see the challenges of automating it.

There are clearly some things that are subjective and are best suited for a human. And there are things that could be automated, but you would need some way to extract the targeted repo(s) in the pull. If that can be done, you could just checkout the repo(s) and analyze the package to cut out a bit of the manual stuff.

It is definitively not an ideal maintenance environment. I feel like some of the things could get cut out for the sake of maintaining sanity for the maintainer, but I also see the benefit it can bring if the maintainer is willing to go through the effort.

0 Likes

#6

Skipping through the list [1] there is a lot to be automated. Looking at the tests [2], many of the reviewing guidelines are already (partially) covered. If they decide which parts can be automated and which are required to be reviewed personally, we can help them by writing the automated parts/improve the tests.


[1] https://github.com/wbond/package_control_channel/wiki/Pull-Request-Review-Guidelines
[2] https://github.com/wbond/package_control_channel/blob/master/tests/test.py

0 Likes

#7

There are certainly a lot of things that can be automated in the review process, but at this point it’s just a matter of actually implementing it. Will has little time at the moment for open source and I have priorities elsewhere. As such, the channel is currently in maintenance mode, kind of.

I do intend to work on a helper tool that I can just feed a repo URL (as provided in the pr) which will then handle a lot of checks. Human interaction is still necessary for this, but will be saverely reduced.
There are a couple to do items I already collected for this. If you want to start working on this, I’ll gladly share them.

(by the way, if you think that I’m wasting my time on the forum instead of reviewing pull requests, that’s because I cannot review while on mobile.)

3 Likes

#8

I’d be more than happy to accept pull requests that automate the process of reviewing PRs. Unfortunately I’m generally burnt out on open source work, and haven’t had the free time to tackle this yet.

The biggest hurdle is needing to take a git diff and from that identify the channel entries that changed and write code to use the downloaders to fetch the package, extract and inspect. So some sort of JSON diff functionality, combined with downloaders and some custom Python to check various things.

Ideally users can run this on their own machine, but that then involves shelling out to git (from within Sublime) and automating that process which is error-prone. I suppose just relying on Travis is probably good enough.

0 Likes

#9

FWIW, I started working on this today. Since there are quite a few PRs unreviewed, they should serve as a good testing field for dogfeeding the test suite.

I’ll start with having the package on the disk already and slowly automating the process to reach that state.

Currently, this requires at least Python 3.4 since I am using the pathlib module (i.e. it’s not compatible with ST’s python).

4 Likes

#10

I pushed my current progress to a repo at https://github.com/packagecontrol/package_reviewer. It’s still very WIP, but the general structure is done and it is in a “usable” state and has a few checks already.
Tests are also available, but I still need to add quite a few.

cc @kingkeith (since you asked on IRC)

5 Likes

#11

As I am not a native python developer and just started python about 2 month ago, I require a bit of a setup README or something along the line to get it going.

0 Likes

#12

It’s still not finished, unfortunately, but you can use the following:

$ python3 -m package_reviewer --help

Requires at least 3.4 at the moment. No external dependencies (for running, that is).

0 Likes

#13

Status update: Package checking itself is pretty much done right now. Could still be improved in some way, but that’s some luxury that can be added at any later date. (Checking for key binding conflicts wasn’t as easy as I hoped, but implicit test-driven development is awesome.)

I’m currently doing some refactoring and will then start with checking the repository (and downloading it). I hope to have this finished before the new year.

12 Likes

#14

As always, thanks for your efforts Fichte (and Will too).

1 Like

#15

I’m one day late, but it’s done! I added a small readme which should get you started on usage and stuff.

Tomorrow, I will add some content to the wiki on how to resolve the various checks that are in place (e.g. how to add tags to your repository, how they have to look like, why you usually don’t need .no-sublime-package in your package, etc.), so that I can refer people to that page in case their package has issues. After that I will begin with dog feeding and reviewing my backlog.

You are very welcome to test it on some (of your) packages, check out the code and leave issues and/or pull requests (for more checks). Remeber that the checks are still rather basic and any properly-crafted package should not trigger a failure or warning.

Happy new year, by the way.

4 Likes