new organisation to welcome maintainers

[anarcat]

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]

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]

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

[ghost]

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]

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

[anarcat]

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]

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]

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]

@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:

• orga on github
• pipy repository
• packaging
• travis
• readthedocs
• (anything else?)

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]

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]

@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]

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é <[email protected]> Subject: linkchecker maintenance To: Bastian Kleineidam <[email protected]> Cc: [email protected] 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: #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: #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. - Leonardo da Vinci

[PetrDlouhy]

@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]

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

[anarcat]

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]

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]

@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]

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]

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:

• @anarcat
• @davejagoda
• @mgedmin
• @PetrDlouhy
• @seamang

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]

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

[NicolasWebDev]

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]

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]

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]

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

[anarcat]

i have created issue linkchecker/linkchecker#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]

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 linkchecker/linkchecker#2.

[anarcat]

so in my todo list here i had:

• orga on github (done)
• pipy repository (well, not done, but see new PyPI release (9.4.0) linkchecker/linkchecker#4)
• packaging (not quite done either, but I'll make sure to sponsor future packages)
• travis (see also Set up Travis linkchecker/linkchecker#3)
• readthedocs (not yet - but see automatically build binaries and tarballs linkchecker/linkchecker#5) for the website update
• (anything else?) (nothing was mentionned)

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 linkchecker/linkchecker#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]

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.