search

wummel / linkchecker

check links in web documents or full websites
http://wummel.github.io/linkchecker/
GNU General Public License v2.0
1.42k stars 234 forks source link

new organisation to welcome maintainers #686

Closed anarcat closed 7 years ago

anarcat commented 7 years ago

i would like to see this project make new releases (#678) and address the large number of issues (currently 137) and pull requests in the queue (13).

i would be happy to coordinate a new release. ideally, this would be a new github organisation with @wummel being at the helm, but i am considering just forking this project considering there hasn't been activity from the maintainer since last june.

i would like to have at least 2 co-maintainers to review issues and make sure we don't move the problem from @wummel to me instead of fixing the problem in the long run. :)

please volunteer explicitly here if you are interested.

ghost commented 7 years ago

Bastian split off the linkchecker-gui as a separate and explicitly unmaintained project. It would be good if the linkchecker maintainers could also manage that project.

anarcat commented 7 years ago

@seamang are you volunteering? :) Wishlists are nice, but they will work only if people step up to actually do it...

ghost commented 7 years ago

I have no Windows development experience, no experience of QT, and not much python either, so I might generate minor pull requests, but I couldn't be the maintainer. I just thought I'd point out that linkchecker-gui was there too in case it gets missed...

Have you managed to talk to @wummel (maybe on his debian.org address?). Maybe he might come back?

anarcat commented 7 years ago

i have not found an email address for @wummel, but then i didn't look very hard either. :) i am anarcat@debian.org if you want to forward me his email address...

anarcat commented 7 years ago

i wrote an email to @wummel (i believe - i looked at the git history for an email address and @seamang did some more research to figure out a @debian.org email).

anarcat commented 7 years ago

i'm a bit disappointed to see no one is showing up to share the work. i am not sure i want to create a full organization and everything if no one else is going to show up to help with the work.

@seamang and others considering this: you don't need to know how to code to contribute to a project. there's already a lot of work to be done here just to triage issues and support users. documentation and translations are other areas where non-programmers can help as well.

i'm going to give this another month: let's see if something happens before 2017, and then we can see where we go from here. i haven't heard anything from @wummel at all...

PetrDlouhy commented 7 years ago

Hi, I started using this project for automatic testing of several webpages in our organization. So I have long term interest in this project being usable for that purpose.

Right now I have few improvements in mind, that would have to be made to reach full scale usability in my case. I am contributing to several rather smaller Python/Django projects and I maintain few of them. I would like to help with this project, although I can not guarantee, that I am able to give this enough time.

I think, that reaching @wummel would be really useful, because otherwise we would need to fork GitHub and PyPI repository and also gain our own place in Linux distributions. If we could just continue in this project, that would be much less work.

For now, I would like to fix Travis tests and improve my PR #687, so it could be pulled.

anarcat commented 7 years ago

@PetrDlouhy that's great news.

i agree that reaching @wummel would be the best. but #661 is about six months old, #678 is now over two months old, and this here is 20 days old. @wummel has been completely inactive on github since june. i haven't heard from him by email. so i don't know what's going on, but i'm worried we'd have to wait forever for this...

i don't think the technical hurdles of creating a new organisation are so big. we'd need:

i think all this can be facilitated if we simply rename the fork: i would propose naming the new software "linkcheck", "urlchecker" or something simple. that way we don't have to worry about ownership of existing resources.

regarding packaging, the package is orphaned in debian right now, and i can take over maintainership there. there might be timing issues with the stretch release unfortunately, but i may be able to convince the release team to slip the fork into the new release, especially if we have a branch that focuses on critical issues (i'd be happy to shepherd that branch). i am confident that other distros will follow suit if the fork proceeds smoothly. this is what happened with the attic/borg fork, and it wasn't a situation where the author disappeared as much as he wanted to keep the project private...

no, the real challenge is the actual work that needs to happen on linkchecker: patches and PRs like yours, but also triage of existing issues. this is why i would like more people to join in, because moving ownership around only does so much. :)

ghost commented 7 years ago

I could help temporarily with some of the smaller stuff (eg triaging) but can't guarantee anything long term. Please don't forget linkchecker-gui too.

PetrDlouhy commented 7 years ago

@anarcat There is other email address to @wummel (Bastian Kleineidam) in the setup.py in sources ending with @web.de. Did you try that? If not, can you please try to post that email there?

anarcat commented 7 years ago

On 2016-12-01 11:22:10, PetrDlouhy wrote:

@anarcat There is other email address to @wummel (Bastian Kleineidam) in the setup.py in sources ending with @web.de. Did you try that? If not, can you please try to post that email there?

Yes, i did try that. Heck, this is all public stuff anyways, so here's the email I sent:

From: Antoine Beaupré anarcat@debian.org Subject: linkchecker maintenance To: Bastian Kleineidam bastian.kleineidam@web.de Cc: calvin@debian.org Date: Fri, 11 Nov 2016 09:46:17 -0500

Hi!

(I am not sure I have the right email, I am trying to reach @wummel on github.)

I have been trying to get a new release of linkchecker going on Github to resolve critical issues that are making it basically unusable in certain scenarios. Someone asked for a release back in September and didn't get a reply yet:

https://github.com/wummel/linkchecker/issues/678

There are a lot of issues to triage and pull requests to merge. I have had to make a "non-maintainer upload" to fix issues in Debian:

https://tracker.debian.org/news/769401

I have since then opened an issue to see if we could collaborate better on the project, maybe by creating an organization:

https://github.com/wummel/linkchecker/issues/686

Would you be interested in giving access to more maintainers on the project to triage issues? Alternatively, would you like (us?) to create a new organization to decentralize maintenance of the project?

Thank you for your feedback,

A.

-- For once you have tasted flight, You will walk the earth with your eyes turned skyward; For there you have been, And there you long to return.

PetrDlouhy commented 7 years ago

@anarcat OK, I will try to dig in a little bit more, because I think it is worth trying to avoid the name confusion.

I fixed the Travis tests in PR #694, so we could judge other PRs by that.

anarcat commented 7 years ago

(Email replies do not support Markdown - github, what's wrong with you... at least preformat that stuff or something :p)

anarcat commented 7 years ago

so still no reply from the maintainer here, i'll probably fork this in january or look again at w3c-checker...

i looked more at @wummel's status in debian, and he has actually retired there 2 years ago, which is why the package is orphaned...

mgedmin commented 7 years ago

I'm willing to step up and help with PyPI releases and with keeping Travis CI builds passing all the time. I would also be interested in trying to fix bugs, but I'm afraid to promise much as I'm already stretched pretty thin.

(My approach to PyPI releases is to automate as much as possible so you could make a release when woken up in the middle of the night, by running a single command that asks for confirmation before doing anything dangerous/irreversible. This requires master always being in the releasable state, which is why I care about Travis CI builds being green all the time, and code coverage being as close to 100% as possible.)

davejagoda commented 7 years ago

@anarcat thanks for looking into this. I recently encountered the PyPI package not having the fix for requests version checking. I am willing to help. One question - if ongoing development efforts move to a fork, does it actually need to renamed? If @wummel were to reappear, we could apply changes from the fork back to the original.

anarcat commented 7 years ago

it's a fair point - maybe we can keep the name. it was mostly out of respect for the existing maintainer, but maybe we should just assume the project is abandoned and carry on with it as is. :)

an update on my side: i may not have time to followup on this until february because of personal issues. i will try to make a bugfix release to launch the fork before the Debian full freeze (february 5th) however, just to get things kicked off. after that i will focus on maintaining a release-critical stability branch and will welcome others to focus on development...

of course, if others want to start the initiative themselves, feel free to kick that into gear! :) please do include, in the project, me and others that manifested an interest here of course... ;)

anarcat commented 7 years ago

another update. due to personnaly issues, i wasn't able to deploy this before the debian freeze. apologies to everyone. i am still confident we'll be able to fix critical issues in stretch there, by (ab)using a new 9.3.x critical release branch that would be long-lived in Debian (and elsewhere). in could then go wild in 9.4.x or 10.x.

so far i see the following people on the maintenance roster, in no particular order:

i will personnally focus on release engineering, collaboration and contribution guidelines and fixing critical bugs for debian.

i expect the fork to come to life next week! sorry for the delays.

PS: i tried creating a linkchecker organization, but that name is already taken - do you know if we could request to get that back from github? alternatively, we could just use linkcheck or linkchecker-org for the organisation. i am also of the opinion of keeping the linkchecker name for now...

anarcat commented 7 years ago

PPS: linkchecker is available on gitlab.com: https://gitlab.com/linkchecker - i wonder if we should just migrate there... ;)

NicolasWebDev commented 7 years ago

I would personally recommend against migrating to gitlab.com right now. The product is already quite good, but it is still really far from being as known as github, so I think that linkchecker would loose in visibility and contributions.

PetrDlouhy commented 7 years ago

I think, that it would be easier to pull existing PRs here on GitHub, than moving the development to GitLab. I don't have big preference about the organisation name, but I would go with linkcheck.

I have fixed and widen Travis testing in PRs #694 and #706. I think, that is a good base for accepting other PRs in the new repository.

anarcat commented 7 years ago

i have now created the new organization. the new repository is here:

https://github.com/linkcheck/linkchecker

@davejagoda @mgedmin @PetrDlouhy @seamang you should all have received invites.

i have mirrored this git repo over there, but unfortunately, i can't copy all the issues and pull requests, so you will need to fork the repo and push those branches again to rebuild those pull request.

i will not personally go through every issue and every PR and migrate them over. there's way too much noise there. but people are welcome to migrate pending issues that are still relevant, and of course all PRs are welcome.

let's do this.

anarcat commented 7 years ago

oh, and I have invited @wummel as well, of course. :)

anarcat commented 7 years ago

i have created issue https://github.com/linkcheck/linkchecker/issues/1 for the community process, will try and see if i can issue a PR soon, but at least I have unblocked some stuff here. :)

anarcat commented 7 years ago

the above is the list of all currently opened PRs that should be reviewed and/or migrated to the new project by their authors. issues should be similarly checked, but I will not do that myself. followup for those issues is in https://github.com/linkcheck/linkchecker/issues/2.

anarcat commented 7 years ago

so in my todo list here i had:

so i think we are all done here: we have forked this project! whee!

now whether this is successful or not depends on you, the community. i am very happy to give commit access to anyone who demonstrates commitment (just send PRs and when they're good and merged, you get in, yay). as mentioned before, i'll try to formalize this in https://github.com/linkcheck/linkchecker/issues/1 and i have of course invited people who already manifested an interest, just to bootstrap things.

in the meantime, i think this issue can be closed. hopefully #708 will bring people to the fork and this project will eventually be really abandoned!

PetrDlouhy commented 7 years ago

I would like the new repository to be fork of current one - it would be easier to repost PRs that way and it will be visible in network graph. But anyway, I am reposting the PRs.