Thread overview
What to do about stale or abandoned dub packages?
Feb 18, 2020
ShadoLight
Feb 18, 2020
rikki cattermole
Feb 18, 2020
ShadoLight
Feb 18, 2020
rikki cattermole
Feb 18, 2020
ShadoLight
Feb 18, 2020
ShadoLight
Feb 18, 2020
rikki cattermole
February 18, 2020
A problem that I have now run into on a few occasions, and which I suspect is very common in D-world, is that some dub packages are abandoned, or the author has moved on to other things leaving the package in limbo and simply not maintained anymore.

As a result, over time - specifically as a result of changes to the compiler and/or language, deprecations, etc - these packages cannot successfully build anymore!

This is a real problem, even with some packages that were popular once upon a time!

Case in point, Vadim Lopatin (@buggins) contributed both the dlangui and dlangide packages - which by all accounts were an enormous amount of work! Both these packages, even though some issues remained, were fully working and quite useful on release. And then he just disappeared - since August 2019 no pull-requests have been merged (some requests are still open).

The current state of affairs is that both these packages don't build anymore as a result of changes to the language and/or compiler. I tried to use the dlangui package some time ago, when it was still building, and found it reasonably pleasant to work with.  Yet I ran into a minor problem as a result of an incomplete feature - which was easily resolved once someone confirmed it was incomplete and not actually my stupidity [1].

However, when I looked at the github dlangui project [2], a thought struck me... the project has been forked 96 times and I wonder; are there any fork that is actually more up to date and complete than the original, which is what dub always references?

With so many forks it stands to reason that the package must have been useful to at least some people. Did they fix some bugs or added some features? Are they maintaining and updating their forks to remain in sync with the evolution of the compiler?

The problem is it is really hard to figure out which fork is the best one to use without investigating each and every one of them. Maybe it is better to flip the situation around - I wonder, is there some way for someone like this to propose their fork as the 'latest' version of a dub package (and possible for the community to vote or somehow confirm), rather than the 'original', but now stale/abandoned package, that dub now references? At least this will indicate the person is interested to become the active maintainer for said package. And if he/she leaves eventually, ditto for the next person!

I know dub cannot currently do this (and maybe there are licensing issues to take into consideration), but is this something other people think is worth to consider? Maybe dub can still reference the original to credit/preserve the original project/author, but have the notion of an 'active' github package link that can change...?

Every now and again there are questions as a result of this issue in the forums, but typically phrased as how to use an alternative git branch [3], which is typically just a symptom of this situation we currently have.

This would also make dub more useful for everybody - packages will have a longer lifespan and, as a side-effect will also improve the ratio of building vs failing packages.

What say you?

[1] https://forum.dlang.org/post/wcpraclpsdmqvclzqzfa@forum.dlang.org
[2] https://github.com/buggins/dlangui/network/members
[3] https://forum.dlang.org/post/r2bhv9$2qrc$1@digitalmars.com

February 19, 2020
1) We can allow others to take ownership of packages in cases like dlangui (manual process and requires getting the right people to agree)
2) dlangui has no active forks. As per http://code.dlang.org/search?q=dlangui
3) There has been desire and attempts to get all packages tested automatically, this would solve most problems.
February 18, 2020
On Tuesday, 18 February 2020 at 12:48:58 UTC, rikki cattermole wrote:
> 1) We can allow others to take ownership of packages in cases like dlangui (manual process and requires getting the right people to agree)

Can you elaborate? Does this requires getting agreement from the original author? How will this work when the person has disappeared?


> 2) dlangui has no active forks. As per http://code.dlang.org/search?q=dlangui

Not forked on http://code.dlang.org/. Forked on github i.e. https://github.com/buggins/dlangui/network/members

> 3) There has been desire and attempts to get all packages tested automatically, this would solve most problems.

This is already done. This is how I know these packages fail to build. This just demonstrates the problem - it doesn't solve it.
February 19, 2020
On 19/02/2020 1:54 AM, ShadoLight wrote:
> On Tuesday, 18 February 2020 at 12:48:58 UTC, rikki cattermole wrote:
>> 1) We can allow others to take ownership of packages in cases like dlangui (manual process and requires getting the right people to agree)
> 
> Can you elaborate? Does this requires getting agreement from the original author? How will this work when the person has disappeared?

I think in the earlier days of dub one or two packages may have been deregistered or something along those lines.
But since you can just register your fork under a slightly different name, its not a big deal.

That is as much as I should say, best for somebody who does have access to say if they are willing to do it.

>> 2) dlangui has no active forks. As per http://code.dlang.org/search?q=dlangui
> 
> Not forked on http://code.dlang.org/. Forked on github i.e. https://github.com/buggins/dlangui/network/members

Unless it is registered on code.dlang.org, the repository owner probably doesn't intend on you using it.

Keep in mind that people fork on Github for a number of reasons including just keeping track of interesting repositories. That fork number is not a good metric of potential developers who could maintain it.
February 18, 2020
On Tuesday, 18 February 2020 at 13:02:37 UTC, rikki cattermole wrote:
> On 19/02/2020 1:54 AM, ShadoLight wrote:
>> On Tuesday, 18 February 2020 at 12:48:58 UTC, rikki cattermole wrote:
>>> 1) We can allow others to take ownership of packages in cases like dlangui (manual process and requires getting the right people to agree)
>> 
>> Can you elaborate? Does this requires getting agreement from the original author? How will this work when the person has disappeared?
>
> I think in the earlier days of dub one or two packages may have been deregistered or something along those lines.
> But since you can just register your fork under a slightly different name, its not a big deal.
>
> That is as much as I should say, best for somebody who does have access to say if they are willing to do it.
>

OK, understood. Yes, that definitely helps. I also looked on dub and, as you noticed, there were none.

But even if there is, it is not always clear which one to use.


>>> 2) dlangui has no active forks. As per http://code.dlang.org/search?q=dlangui
>> 
>> Not forked on http://code.dlang.org/. Forked on github i.e. https://github.com/buggins/dlangui/network/members
>
> Unless it is registered on code.dlang.org, the repository owner probably doesn't intend on you using it.
>

This is the problem with the current status-quo. There is no procedure in dub in support of this idea so, I suspect, people don't do it because 'it is not done'.

In my case [1] I asked why a specific feature didn't work, someone answered explaining it was incomplete with code showing how he added the code to the package, which I then used and further generalized. All these improvements could be useful to other people, but to who do we do the pull-requests since the original is abandoned?

Maybe someone is maintaining his own version and would in fact be willing, but are afraid of license issues, etc. If dub has an official way to do this, would this not be useful?

For example, dlangui statistics today are:

        4 downloads today
        44 downloads this week
        184 downloads this month
        31438 downloads total

30k+ total downloads. If is still being downloaded over 40x this week, even though it is clearly shown as failing to build. This is surely an indication of at least perceived/expected usefulness - and surely it would be better to have an official way to use the most up-to-date package, if at all possible.


> Keep in mind that people fork on Github for a number of reasons including just keeping track of interesting repositories. That fork number is not a good metric of potential developers who could maintain it.

Yes, but you don't need many, you just need *one* that is willing.


[1] https://forum.dlang.org/post/wcpraclpsdmqvclzqzfa@forum.dlang.org

February 18, 2020
On Tuesday, 18 February 2020 at 12:44:28 UTC, ShadoLight wrote:
> [..]

Hi, I don't have time for a detailed answer right now, but I think the best course of action would be to adopt projects like this in the dlang-community organization. See this blog post for more details:

https://dlang.org/blog/2018/02/17/project-highlight-the-d-community-hub/

TL;DR
The project author doesn't need to transfer the ownership, but it's best if he does so, so users of the project have a clear indication of the official/upstream line of work.

The project author keeps maintainership access to the project, but also shares this access with other members of the community, so they can merge bug fix pull requests and release new versions of the software.
February 18, 2020
On Tuesday, 18 February 2020 at 14:24:29 UTC, Petar Kirov [ZombineDev] wrote:
> On Tuesday, 18 February 2020 at 12:44:28 UTC, ShadoLight wrote:
>> [..]
>
> Hi, I don't have time for a detailed answer right now, but I think the best course of action would be to adopt projects like this in the dlang-community organization. See this blog post for more details:
>
> https://dlang.org/blog/2018/02/17/project-highlight-the-d-community-hub/

This definitely has the makings of a solution. Not yet perfect, but I can see that something along these lines can work.

I remember seeing this at the time, but have completely forgotten about it. I suspect it is also driven more from Seb's/your side, than from the community's side at this stage, no? I suspect it needs to be easy and a "standardized" dub process so that it is rather initiated from the community's side.

>
> TL;DR
> The project author doesn't need to transfer the ownership, but it's best if he does so, so users of the project have a clear indication of the official/upstream line of work.
>
> The project author keeps maintainership access to the project, but also shares this access with other members of the community, so they can merge bug fix pull requests and release new versions of the software.

I completely agree with the listed benefits but, even though the process is superficially clear (nominate a project or just "ask for help"), it is not clear to me how it will work in practice. For example, I suspect a common case is going to be when the author disappears. How will pull-request merging be handled in this case?

Somehow there needs to be a way to identify the projects that needs TLC, and for a way for a champion to volunteer. Preferably from the dub pages itself.

Maybe it will help if the dub 'list view'[1] contain an extra column for build status (if being done). Some statistics about the last compiler version/date that was build successfully could also be useful to help people see the status at a glance.

And then some way for someone to easily volunteer to take over a project as maintainer. It will be useful if this can be easily done from the dub page itself, preferably allowed/disallowed based on some criteria based on the above.

Maybe it could also be useful for the 'volunteer action' to automatically generate a forum post where the "offer" is proposed, and for people (and/or the author) to comment. Then Seb, you or someone can, based on the feedback, add the volunteer to dlang-community and he/she can fork the original repo to dlang-community.

I notice there is a 'harbored-mod' repo there... maybe we can use that as a standard naming convention eg. <package_name>-mod is the standard name if the original project is left in dub.

Displaying the build status for search results will also at a glance show that <package_name>-mod is building, while <package_name> is not (or indicate it is not being auto-build).

Just throwing some ideas around here...

[1] https://code.dlang.org/?category=library

February 19, 2020
See: https://github.com/dlang-community/discussions