Open Dreomite opened 5 years ago
i just found this tool as part of a vscode extension and that's really sad. i hope someone can continue the project and that everyone who was close to peter is ok.
I'm sorry to hear about that, this is a excellent tool for linting and static analysis of Lua code
RIP Peter.
Does this repository already have who keeps it alive?
EDIT: I had in mind using this repo to create the Lua version of GoReportCard. What do you think?
Does this repository already have who keeps it alive?
@PandaFoss I don't think that anyone else has commit or admin access to this repo so someone would need to create a fork and maintain that instead as @Azumgi mentioned in the original message:
This repo will no longer be maintained and needs to be forked by someone who's willing to carry on Peter's legacy.
FYI, I've taken over ownership of the readthedocs page/org.
To move the repository to a community location, the luarocks organisation would be happy to host it. We have a fork here: https://github.com/luarocks/luacheck The missing thing right now is someone with the will+expertise+bandwidth to work on luacheck.
I'm sorry to hear that.
I'm sorry to hear about Peter! It's certainly a testament to a well written project that I'm only noticing this since Lua 5.4 things have started cropping up.
I may be willing to pick up maintaining this. I've certainly gotten a lot of mileage out of it. I'll have to give the code a once over and make sure it's in my wheel house.
Also it would be really nice if the official repository could find a home such as the Luarocks org. I know Github has recently started implementing procedures for how to handle repositories when their owners pass away. Now there is a way to designate ahead of time who will be responsible for that, but I know a few cases in the past have been manually re-paranted by Github staff. I wonder if we can contact somebody and ask about this. It seems like if the home was somewhere such as Luarocks and not just some rando they might be willing to executive transfer the repo.
There is some hope for this is the deceased user policy, but the voice of an collaborator would hold more weight than mine. Unfortunately I see quite a few contributors but none marked as a collaborator. @daurnimator or @hishamhm have either of you by chance tried contacting Github about this yet?
@alerque We did, but they request official papers which would be difficult to obtain.
For practical purposes, we can make luarocks.org point to the fork under github.com/luarocks/luacheck and accept PRs there, but there haven't been significant contributions yet to warrant tagging a new release and making the switch (I've done that already for another of Peter's projects, hererocks and managed to get the entry changed in the Python PIP repository).
If the community contributes Lua 5.4 support (or other PRs with fixes, etc.), I'll be happy to push a release. But his projects are still in need of maintainers. I'm short on bandwidth and acting as temporary caretaker of his projects on a best-effort basis (in particular, I'm unfamiliar with the code internals).
Now that Lua 5.4 support has been contributed to the fork and a release looks like it is in the works I suggest we go ahead with this and make the fork as official as possible, either there under the luarocks org or under the lunarmodules org.
Either way I'm interested in pitching in especially with issue triage and getting as much stuff from this project ported over (I'll resubmit the PRs and copy over as many issues as seem te be relevant and crosslink the originals so people know where to track them).
Although as a last ditch effort to use the deceased user policy to migrate this, is it possible that the necessary docs are something that @notWhaleB (who was a classmate of Peter's) could dig up?
Although as a last ditch effort to use the deceased user policy to migrate this, is it possible that the necessary docs are something that @notWhaleB (who was a classmate of Peter's) could dig up?
Yes, I have a copy of required docs. I will send it to @hishamhm via email.
Thanks, but if possible, I'd rather not be involved in activating the deceased user policy at this time — I've gone through a lot of this for multiple things related to Peter's passing last year and I'm just not in a mental place to go through it again right now.
@alerque Would you be willing to go through the process? I can move the current fork from luarocks/ to the lunarmodules/ org where you are already added, and with @notWhaleB 's document you should have everything needed.
Thanks for understanding.
@hishamhm Yes I'm willing to take care of that end of things. Let's not transfer the the Luarocks fork into Lunarmodules though. I'm not sure how Github handles this kind of migration and if it's different that regular transfers, but if Lunarmodules is the ultimate home we want this under then I think the namespace needs to be clear of forks in order to transfer this repository there. At least stand by until I confirm that. Once this original is transferred I'll help with merging the things that make been done in the fork back into the canonical source repo.
@notWhaleB Per the above wish from Hisham can you email me those docs instead? I believe my email address is public on my GitHub profile.
Is there any progress on this front? I'm wanting to implement a feature to treat warnings as errors and would rather not maintain my own fork. But it doesn't look like much has changed about the repo in the last half year (it's still the top search result for "luacheck").
The project is still unmaintained.
I did receive the requested documentation and tried several times with GitHub to get ownership transferred to no avail. They want an actual next of kin to handle this, not just a likely programmer community inheritor. In spite of having some cooperation and confirmation from friends they are saying it just isn't enough.
I thing it's probably time we initialize a NON FORK repo on @lunarmodules and work on transferring the community there.
I guess the best way to get a non-fork repo going is to migrate the luarocks/luacheck
fork to @lunarmodules and then file a request to disconnect its "fork" status.
I guess the best way to get a non-fork repo going
Why would we want a non-fork repo? I'm content to remain as a fork in github's metadata.
Either works as far as I'm concerned — whatever needs the least help from Github support is probably easiest.
@alerque, if you move ahead with the move to @lunarmodules, just let me know when things are set up and I'll transfer the luacheck
from the luarocks
account on luarocks.org to some other account responsible for pushing updated rockspecs (create a luacheck
account, perhaps? That's the appoarch taken for argparse
)
Fork status has several drawbacks. One is a discoverability penalty. Another is that GitHub doesn't credit people for contributions to forks. That being said that status is something your can change later when/if those and other disadvantages become more apparent.
Given that I was just outvoted on that idea, lets go ahead and transfer luarocks/luacheck
to at least bring those issues/stars/links/watchers/etc. along for the ride. @hishamhm I think you'll have to do that since you're the owner of that repo. Then after it comes in you'll have to do some permission updating.
A luacheck
account (or lunarmadules
if we want to setup CI based deploys managed by GitHub push access instead of individually, cc @lunarmodules) to handle rockspec pushes is an easy next step after that.
All right! I clicked through the transfer process! Should be happening now
Transfer is live at https://github.com/lunarmodules/luacheck — I made a quick search-and-replace in the repo to update all URL references.
A luacheck account (or lunarmadules if we want to setup CI based deploys managed by GitHub push access instead of individually, cc @lunarmodules) to handle rockspec pushes is an easy next step after that.
IIRC Travis CI is currently broken in that repo, and Appveyor might be down as well. It took me some effort to be able to build the binaries for releases locally (this is the adhoc script I've been using locally), and I've never automated the process on Github. Moving the whole thing (CI, builds, releases) to Github Actions is probably the best thing to do, but I haven't looked into that, I have next to no experience with Actions.
Fantastic!
I've done some release automation with Actions before, I'll look into it.
Just a heads up I'm a few days away from 6 weeks of almost non-stop travel so at best I'll have a trickle of FOSS contributions for a little while, but I'll be back at it in Dec.
I just looked and I have member status on the @lunarmodules org, but that isn't giving me any super powers on the newly migrated repo at all. I suspect the migration kept the original permissions profile instead of inheriting the org defaults. Can you look into giving me access to repo settings so I can work on CI stuff?
I tweaked the permissions, should be working now!
Hello everyone who will read this message
I suggest to check if you already
I think that will helps people to find the new lunarmodules repository instead of the legacy one. Currenty, lunarmodules 101 stars, mpeterv 1522 stars.
Regards,
After seeing all the new issues popping up from unaware people I decided to spread awareness.
Almost a year ago Peter Melnichenko has passed away. I'm going to quote Hisham's open letter to Lua community because I could not phrase it better:
This repo will no longer be maintained and needs to be forked by someone who's willing to carry on Peter's legacy.
UPD: After a lengthy discussion, the community fork has been finalized at https://github.com/lunarmodules/luacheck