www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - We need a community effort to maintain unmaintained dub packages,

reply mw <mingwu gmail.com> writes:
Hi,

I'm new here, try to start using D on my hobby projects, and I 
quickly run into issues when looking for supporting libraries.

I'm searching for a fixed point (decimal) type. On 
code.dlang.org, I found two packages having the functionalities 
that I need:

https://code.dlang.org/packages/decimal
https://code.dlang.org/packages/money

But I then run into issues with these packages (one has bug, and 
the other has compilation issues:
https://github.com/qznc/d-money/issues/11
https://github.com/rumbu13/decimal/issues/9)

And worse, it looks like both packages are no longer maintained 
by their original owners.

Then I found other people experienced the same difficulties, and 
started to re-invent those wheels, and the new packages are in 
0.0.x stage with limited functionalities.

I think we are wasting our community effort here. I'm wondering:


1) can we form a dub packages maintenance group, to take care of 
these no longer maintained packages


2) can we change the code.dlang.org to allow other users take 
over those packages, e.g. after 2 weeks no reply from the 
original owner:

https://github.com/rumbu13/decimal/issues/9#issuecomment-632843049

'''
I would be willing to take over and fix the package.
I have forked it already months ago.
The most important think would be to give me access on 
code.dlang.org, so users would find it.
'''

https://github.com/rumbu13/decimal/issues/8 (this issue has been 
more than half year now).


3) make the new "may-take-over-when-needed" policy explicit on 
https://code.dlang.org/, when people register new packages.


4) create a "dub packages maintenance" group in this forum, so 
people can discuss these issues.


Anything else? thoughts?
May 22
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 22 May 2020 at 21:01:58 UTC, mw wrote:
 I think we are wasting our community effort here. I'm wondering:


 1) can we form a dub packages maintenance group, to take care 
 of these no longer maintained packages
I believe this is the purpose of the dlang-community github organization: https://github.com/dlang-community
May 22
parent reply mw <mingwu gmail.com> writes:
On Friday, 22 May 2020 at 21:15:42 UTC, Paul Backus wrote:
 I believe this is the purpose of the dlang-community github 
 organization:

 https://github.com/dlang-community
Thanks for the link, can we add this link to https://code.dlang.org/ on each individual package's page, with the message: If you found issues with this package, and it is no longer maintained and worth maintaining, please file an issue at: https://github.com/dlang-community/discussions/issues I'm adding the two packages I just found there.
May 22
parent reply Seb <seb wilzba.ch> writes:
On Friday, 22 May 2020 at 21:35:45 UTC, mw wrote:
 On Friday, 22 May 2020 at 21:15:42 UTC, Paul Backus wrote:
 I believe this is the purpose of the dlang-community github 
 organization:

 https://github.com/dlang-community
Thanks for the link, can we add this link to https://code.dlang.org/ on each individual package's page, with the message: If you found issues with this package, and it is no longer maintained and worth maintaining, please file an issue at: https://github.com/dlang-community/discussions/issues I'm adding the two packages I just found there.
Well the capacities that dlang-community can maintain are limited as well, so I'm not sure whether it's a good idea to advertise it so openly as a "free service", but I agree that it currently has too little presence (and maintainers). We generally only move a package if there's a volunteer in dlang community that actually is interested in maintaining the library (though it's not hard to become such a volunteer).
May 22
next sibling parent reply mw <mingwu gmail.com> writes:
On Friday, 22 May 2020 at 22:54:30 UTC, Seb wrote:
 , but I agree that it currently has too little presence (and 
 maintainers). We generally only move a package if there's a 
 volunteer in dlang community that actually is interested in 
 maintaining the library (though it's not hard to become such a 
 volunteer).
I can take one of the issue I found. And m3m0ry has express interest in take over the other one. Just let me know the setup steps (any link somewhere?) on how to adopt the project to dlang-community, and someone who can do code review for me. (I've noted on the issue ticket I filed.)
May 22
parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Friday, 22 May 2020 at 23:33:44 UTC, mw wrote:
 On Friday, 22 May 2020 at 22:54:30 UTC, Seb wrote:
 , but I agree that it currently has too little presence (and 
 maintainers). We generally only move a package if there's a 
 volunteer in dlang community that actually is interested in 
 maintaining the library (though it's not hard to become such a 
 volunteer).
I can take one of the issue I found. And m3m0ry has express interest in take over the other one. Just let me know the setup steps (any link somewhere?) on how to adopt the project to dlang-community, and someone who can do code review for me. (I've noted on the issue ticket I filed.)
The best is if the original project author(s) transfer the project to the dlang-community repo. Then they remain maintainers of the repo, but also other members of the dlang-community organization can contribute or invite other potential maintainers. In case they are unavailable, the next option would be to create a fork, transfer it yourself and register it as new package on dlang.org. Later down the road, if original author responds, you can move the original repo and delete the fork.
May 22
prev sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
I am happy for us to bring over a fixed-point data type, but not a money 
type.

Money requires external API access for get conversion rates ext.

A fixed point type at worst requires optimization for a given cpu.
Which is ok, very limited external dependencies needed to do that well.
May 22
parent reply mw <mingwu gmail.com> writes:
On Saturday, 23 May 2020 at 00:31:48 UTC, rikki cattermole wrote:
 I am happy for us to bring over a fixed-point data type, but 
 not a money type.

 Money requires external API access for get conversion rates ext.
That particular money package actually is very simple, it just implemented a fixed-point data type, and that's also what I need. (Ahh, even such a small thing is hard to find in dub, and this one is the most downloaded package in its kind with dub score 4.0). The other decimal package actually looks pretty decent: https://github.com/rumbu13/decimal/issues/7 but, right now it has compilation and test errors: https://github.com/rumbu13/decimal/issues (sigh ..., suppose I want to use D in my work, how I can convince my company to use it if I cannot even get my personal hobby project done in D?)
May 22
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 23 May 2020 at 00:48:26 UTC, mw wrote:
 (sigh ..., suppose I want to use D in my work, how I can 
 convince my company to use it if I cannot even get my personal 
 hobby project done in D?)
Every language has unmaintained libraries. You could always fork and fix the errors.
May 22
parent reply mw <mingwu gmail.com> writes:
On Saturday, 23 May 2020 at 01:31:38 UTC, Mike Parker wrote:
 Every language has unmaintained libraries. You could always 
 fork and fix the errors.
Well, fork and fix is ok for personal project; but for the company, they will certainly say: why not choose a mature language with mature libraries? why not just use Java / Python / C++? why should we spend time fixing the libraries instead of getting our (functionality) work done? I've some threads on this topic of industry use in the past: April 24, 2012 How can D become adopted at my company? https://forum.dlang.org/thread/exazrwacogokubvhjauh forum.dlang.org June 05, 2016 Andrei's list of barriers to D adoption https://forum.dlang.org/post/nj2mm1$1hun$1 digitalmars.com it's almost 8 years now, is D's industry adoption picking up?
May 22
next sibling parent reply mw <mingwu gmail.com> writes:
On Saturday, 23 May 2020 at 02:04:01 UTC, mw wrote:
 it's almost 8 years now, is D's industry adoption picking up?
Wow, it's more than 20 years now: quote https://forum.dlang.org/post/nrhhnhocbsamkifkhzrd forum.dlang.org """ Hi Walter, You had asked me a question that I have been thinking about for a couple years. Your question from 2009 was, “How can D become adopted at my company?” *** What makes a language successful? *** I think Stroustrup’s answer is the best metric I’ve heard: a language is successful if it is used. """
May 22
parent mw <mingwu gmail.com> writes:
On Saturday, 23 May 2020 at 02:07:45 UTC, mw wrote:
 On Saturday, 23 May 2020 at 02:04:01 UTC, mw wrote:
 Wow, it's more than 20 years now: quote
20 -- I mean since D started.
May 22
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Saturday, 23 May 2020 at 02:04:01 UTC, mw wrote:
 Well, fork and fix is ok for personal project; but for the 
 company, they will certainly say: why not choose a mature 
 language with mature libraries? why not just use Java / Python 
 / C++? why should we spend time fixing the libraries instead of 
 getting our (functionality) work done?
If the library was in a complete and stable state when original the maintainer left, picking up it's maintenance is not that much of a trouble, assuming you only want to keep it compiling and to fix the most critical bugs. Even for a lone programmer it's worth considering, and more so for a company with many programmers. This is because regressions due to library development is the main way the library can break code using it. If the development stops, so do the regressions, and code using it tends to keep working. The only problems left are: 1. breakage due to language updates 2. old bugs that the user has not happened to trigger. Point one is much less work than dealing with regressions, and point two can usually be worked around, if fixing the library is too hard: You didn't trigger the feature before, so you can usually continue to avoid the usage that triggers the bug.
May 23
parent reply mw <mingwu gmail.com> writes:
On Saturday, 23 May 2020 at 10:23:09 UTC, Dukc wrote:
 On Saturday, 23 May 2020 at 02:04:01 UTC, mw wrote:
 Well, fork and fix is ok for personal project; but for the 
 company, they will certainly say: why not choose a mature 
 language with mature libraries? why not just use Java / Python 
 / C++? why should we spend time fixing the libraries instead 
 of getting our (functionality) work done?
If the library was in a complete and stable state when original the maintainer left, picking up it's maintenance is not that much of a trouble, assuming you only want to keep it compiling and to fix the most critical bugs. Even for a lone programmer it's worth considering, and more so for a company with many programmers.
This is majority of the case we care about, i.e. fix the bug found in well-used unmaintained packages. But for industry usage, there is another side of the story, i.e accountability & company politics. The managers who can make decisions (together with the consequent responsibility) have to think about the worst scenario: what if the project missed the deadline? or even fail? Will s/he *bet* his/her job security or even career on a new language / library? Most managers sure won't. That's why companies always want to use *mature* language & libraries: 1) the project schedule can be more reliably estimated (without wasting extra time, detour to fix libraries bugs) 2) if the project delayed, or failed, at least nobody in the company can blame him/her choosed a new language & new libraries that caused the failure.
May 23
parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Saturday, 23 May 2020 at 17:27:15 UTC, mw wrote:
 But for industry usage, there is another side of the story, i.e 
 accountability & company politics. The managers who can make 
 decisions (together with the consequent responsibility) have to 
 think about the worst scenario: what if the project missed the 
 deadline? or even fail? Will s/he *bet* his/her job security or 
 even career on a new language / library? Most managers sure 
 won't.
Your run-of-the-mill manager would think like that, I guess. That is why, as far as I know, D is used commercially in companies that are managed by tech people; People who can properly put a value on the advantages and disadvantages of using D, and consider its significance for their chances of success versus risk of failure. — Bastiaan.
May 23
parent reply mw <mingwu gmail.com> writes:
On Saturday, 23 May 2020 at 18:45:25 UTC, Bastiaan Veelo wrote:
 On Saturday, 23 May 2020 at 17:27:15 UTC, mw wrote:
 But for industry usage, there is another side of the story, 
 i.e accountability & company politics. The managers who can 
 make decisions (together with the consequent responsibility) 
 have to think about the worst scenario: what if the project 
 missed the deadline? or even fail? Will s/he *bet* his/her job 
 security or even career on a new language / library? Most 
 managers sure won't.
Your run-of-the-mill manager would think like that, I guess.
your use of word are exactly right ... in supporting *my* statement :-). (I even don’t bother the personal attack in your words) “run-of-the-mill”: What does the idiom run of the mill mean? run-of-the-mill. COMMON You use run-of-the-mill to describe something or someone that is ordinary and not at all exciting. Common means, say 80 ~ 90% of the managers In contrast, extraordinary (tech-savvy) means 10% of the managers And my original statement:
 Will s/he *bet* his/her job security or even career on a new 
 language / library? Most managers sure won't.
Most == common == run-of-the-mill :-) But, are we betting on extraordinary managers to expanding the adoption of D. Probably we are, and that explains how much we have achieved after 20 years of D. And how much has the ordinary language like Java has achieved in the past 20 years. You want *popular* adopt, then you have to think about what those “common” run-of-the-mill managers will choose :-)
May 23
next sibling parent reply welkam <wwwelkam gmail.com> writes:
On Saturday, 23 May 2020 at 19:12:14 UTC, mw wrote:
 And how much has the ordinary language like Java has achieved 
 in the past 20 years.
Sun played big role in Java's adoption. Most languages got popular because they had big corporate backer.
May 23
next sibling parent mw <mingwu gmail.com> writes:
Speaking of ordinary vs extra-ordinary, do I need to mention the 
well known story of Paul Graham?

His startup, written in the most extraordinary programming 
language Lisp (IMHO), after sold to Yahoo, was rewritten to C++ 
and Perl:

https://discuss.fogcreek.com/joelonsoftware1/31402.html

This is another classic example of extraordinary-ness lose to 
ordinary-ness, unfortunately.


Frankly speaking, for my hobby project, I would want to use Lisp 
(I hope this won’t offend anybody here), but it’s really hard to 
get started without some good modern Lisp libraries for today’s 
IT infrastructure (hardware & software).

D is the 2nd on my language selection list. Language-wise, D 
certainly is superior to C++, and Java (among compiled languages 
that can offer decent performance). From my short D journey so 
far, I think if D’s supporting libraries can catchup with what 
the D language itself  has offered, D will have a much bright 
future.
May 23
prev sibling parent reply mw <mingwu gmail.com> writes:
On Saturday, 23 May 2020 at 20:06:42 UTC, welkam wrote:
 On Saturday, 23 May 2020 at 19:12:14 UTC, mw wrote:
 And how much has the ordinary language like Java has achieved 
 in the past 20 years.
Sun played big role in Java's adoption. Most languages got popular because they had big corporate backer.
Then, who is the big corporate backer behind Python? Well, I think it’s the community — the community who maintained those so many out-of-box, directly useable extraordinary packages: numpy, requests, pandas, keras, etc. to name just a few. Which are often sought after by other languages’ developers, and being simulated to keep the same interface, e.g. “what’s the Sure, behind the scene, the work is done by C, but it’s numPY who takes the credits. D has such a native compatibility with C, do we have any library that come to the close of the popularity of numpy? I would say, many times it’s the library packages that attract the people to use a particular language, after all, not so many people are as enthusiastic about a particular programming language features as you and me or anyone on this forum. Normally, people use a language — and most importantly the *libraries* — to get their job done. That *usage* determines which language becomes trendy, becomes popular. I would say libraries can make a language, or destroy one. Numpy has made Python’s fame. I think currently D is on the other side of this spectrum (after 20 years).
May 23
next sibling parent reply Luis <luis.panadero gmail.com> writes:
On Sunday, 24 May 2020 at 01:56:13 UTC, mw wrote:
 I would say libraries can make a language, or destroy one.

 Numpy has made Python’s fame. I think currently D is on the 
 other side of this spectrum (after 20 years).
And Ruby had Rails... The question is... we have something with these potential to become popular ?
May 23
parent reply mw <mingwu gmail.com> writes:
On Sunday, 24 May 2020 at 06:57:01 UTC, Luis wrote:
 On Sunday, 24 May 2020 at 01:56:13 UTC, mw wrote:
 I would say libraries can make a language, or destroy one.

 Numpy has made Python’s fame. I think currently D is on the 
 other side of this spectrum (after 20 years).
And Ruby had Rails... The question is... we have something with these potential to become popular ?
D is late in the game, but still have potentials because of D's good performance and language features, e.g. -- If vibe.d can catch up on the easy of use, and fast-prototyping with Django, Rails (performance-wise, we have trust in D), people may want to switch over to use it, after all compiled language ensures type safety for web services. -- maybe numD? numpy is great, but because of the Python language's Global Interpreter Lock (GIL), people who want parallel data processing can only run on separate tasks via multiple processes, which sometimes is inconvenient when exchange information via shared memory is needed. This problem is *inherently unsolvable* in Python because of the GIL. If numD can offer everything numpy has offered, and plus parallel processing via multiple threads on multi-cores, it will have an edge. -- the recent change safe as default opt-in is good thing: without a nogc phobos, nobody is going to write system level software using D. I think this safe change means the shift of D's focus from system software to application software. And I'm glad to see the the template project that dub generate starts with "app.d", which is the right direction for D. -- anyone have more ideas to throw in?
May 24
parent reply Luis <luis.panadero gmail.com> writes:
On Sunday, 24 May 2020 at 17:29:54 UTC, mw wrote:

 -- anyone have more ideas to throw in?
Pegged have a good potential. Nobody catches how powerful it's a parser library that can parse stuff on compilation time ?
May 24
parent Mike Parker <aldacron gmail.com> writes:
On Sunday, 24 May 2020 at 17:48:37 UTC, Luis wrote:

 Pegged have a good potential. Nobody catches how powerful it's 
 a parser library that can parse stuff on compilation time ?
Bastiaan Veelo at DConf 2017: Extending Pegged to Parse Another Programming Language https://www.youtube.com/watch?v=NoAJziYZ4qs&feature=youtu.be
May 24
prev sibling parent aberba <karabutaworld gmail.com> writes:
On Sunday, 24 May 2020 at 01:56:13 UTC, mw wrote:
 On Saturday, 23 May 2020 at 20:06:42 UTC, welkam wrote:
 Then, who is the big corporate backer behind Python?

 Well, I think it’s the community — the community who maintained 
 those so many out-of-box, directly useable extraordinary 
 packages: numpy, requests, pandas, keras, etc. to name just a 
 few. Which are often sought after by other languages’ 
 developers, and being simulated to keep the same interface, 


 Sure, behind the scene, the work is done by C, but it’s numPY 
 who takes the credits.
 I would say, many times it’s the library packages that attract 
 the people to use a particular  language, after all, not so 
 many people are as enthusiastic about a particular programming 
 language features as you and me or anyone on this forum.

 Normally, people use a language — and most importantly the 
 *libraries* — to get their job done. That *usage* determines 
 which language becomes trendy, becomes popular.

 I would say libraries can make a language, or destroy one.

 Numpy has made Python’s fame. I think currently D is on the 
 other side of this spectrum (after 20 years).
I couldn't say better. You've said it all. I use Node.Js MORE not because JavaScript is technically the best language out there, its because it gets things done. Mostly the packages on NPM. Its what I care about...and I can confidently say that for a lot of devs using it...its why I came to it, its why I stayed. How perfect or technically solid a language is doesn't matter to run-the-mill devs (and they are the majority...80%-90%), its the ecosystem of RELIABLE tools and libraries/packages to get job done. Somehow we haven't figured this out. We have the most brilliant engineers doing the impossible here but that alone is not enough. More devs means more contributors...especially for those less technical stuff (arguably the majority of our problems)
May 24
prev sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Saturday, 23 May 2020 at 19:12:14 UTC, mw wrote:
 On Saturday, 23 May 2020 at 18:45:25 UTC, Bastiaan Veelo wrote:
 On Saturday, 23 May 2020 at 17:27:15 UTC, mw wrote:
 But for industry usage, there is another side of the story, 
 i.e accountability & company politics. The managers who can 
 make decisions (together with the consequent responsibility) 
 have to think about the worst scenario: what if the project 
 missed the deadline? or even fail? Will s/he *bet* his/her 
 job security or even career on a new language / library? Most 
 managers sure won't.
Your run-of-the-mill manager would think like that, I guess.
your use of word are exactly right ... in supporting *my* statement :-).
Indeed, I am supporting your statement.
 (I even don’t bother the personal attack in your words)
No attack intended!
 “run-of-the-mill”:    What does the idiom run of the mill mean?
 run-of-the-mill. COMMON You use run-of-the-mill to describe 
 something or someone that is ordinary and not at all exciting.


 Common means, say 80 ~ 90% of the managers
 In contrast, extraordinary (tech-savvy) means 10% of the 
 managers

 And my original statement:

 Will s/he *bet* his/her job security or even career on a new 
 language / library? Most managers sure won't.
Most == common == run-of-the-mill :-)
Yes, that is what I mean. It is just my observation.
 But, are we betting on extraordinary managers to expanding the 
 adoption of D.

 Probably we are, and that explains how much we have achieved 
 after 20 years of D.
I don’t think there’s much betting being done around here. We just gather around a shared treasure and each of us (individuals and companies) invest in it as much as we can and want to. Would it be cool if using D would be a no-brainer for every manager? Probably, but getting there with volunteers only is unlikely. Personally I am happy that D is still around even after 20 years, so that I can use it professionally. And I made a considerable investment to make it that way. Some people are disappointed that D is not as widely adopted as they would like it to be, and somehow feel the need to put the blame somewhere. I don’t see the point in that, I’d say just use it if you want to, and make it better if you want to. Cheers, and welcome! — Bastiaan.
May 24
parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Sunday, 24 May 2020 at 11:13:03 UTC, Bastiaan Veelo wrote:
 On Saturday, 23 May 2020 at 19:12:14 UTC, mw wrote:
 On Saturday, 23 May 2020 at 18:45:25 UTC, Bastiaan Veelo wrote:
 Your run-of-the-mill manager would think like that, I guess.
 (I even don’t bother the personal attack in your words)
No attack intended!
Ah now I see how my words may have come out hostile. I was not insinuating anything about _your_ manager. I meant something like "the typical manager". I thought that's how the phrase is typically used ("Your run-of-the-mill ...") but I'm not a native English speaker. -- Bastiaan.
May 24
parent mw <mingwu gmail.com> writes:
On Sunday, 24 May 2020 at 16:26:33 UTC, Bastiaan Veelo wrote:
 Ah now I see how my words may have come out hostile. I was not 
 insinuating anything about _your_ manager. I meant something 
 like "the typical manager". I thought that's how the phrase is 
 typically used ("Your run-of-the-mill ...") but I'm not a 
 native English speaker.
No worries, neither am I.
May 24
prev sibling parent reply Jan =?UTF-8?B?SMO2bmln?= <hrominium gmail.com> writes:
On Saturday, 23 May 2020 at 00:48:26 UTC, mw wrote:
 The other decimal package actually looks pretty decent:
For this reason I have started my own extremely simple fixedpoint type: https://github.com/m3m0ry/fixedpoint https://code.dlang.org/packages/fixedpoint For me it would be great, if you use it for a personal project, since I am as well. As for the decimal package. I am currently trying to get the "rights" to it, so I can fix it. The problem with decimal types is, that one solution is not enough. There are many possibilities how to achieve it, each of them having its own pros and cons.
May 22
parent Jan =?UTF-8?B?SMO2bmln?= <hrominium gmail.com> writes:
On Saturday, 23 May 2020 at 06:57:32 UTC, Jan Hönig wrote:
 For this reason I have started my own extremely simple
I see you have found it :)
May 22
prev sibling parent reply Luis <luis.panadero gmail.com> writes:
On Friday, 22 May 2020 at 21:01:58 UTC, mw wrote:
 And worse, it looks like both packages are no longer maintained 
 by their original owners.

 Then I found other people experienced the same difficulties, 
 and started to re-invent those wheels, and the new packages are 
 in 0.0.x stage with limited functionalities.

 I think we are wasting our community effort here. I'm wondering
Because this, I forked two small packages and get it under my wing, with the self-compromise that at least I will keep it working on future versions of D. However, I published they with different names and changing the module name. Something that should be totally unnecessary. And there are many packages with the same problem on the wild.
May 23
parent reply mw <mingwu gmail.com> writes:
On Saturday, 23 May 2020 at 07:27:50 UTC, Luis wrote:
 Because this, I forked two small packages and get it under my 
 wing, with the self-compromise that at least I will keep it 
 working on future versions of D. However, I published they with 
 different names and changing the module name. Something that 
 should be totally unnecessary.

 And there are many packages with the same problem on the wild.
Right, people forked & fixed, but the fix cannot be contributed back to the D community. Other users are still getting the original buggy version from dub, and don't have an easy way to find new patches. So the main blocker is to get the write permission (of the unmaintained packages) of the dub system, this will solve lots of these problems. Or we should setup a new policy that any new dub packages should give write permission to dlang-community by default.
May 23
next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Saturday, 23 May 2020 at 17:10:27 UTC, mw wrote:
 On Saturday, 23 May 2020 at 07:27:50 UTC, Luis wrote:
 Because this, I forked two small packages and get it under my 
 wing, with the self-compromise that at least I will keep it 
 working on future versions of D. However, I published they 
 with different names and changing the module name. Something 
 that should be totally unnecessary.

 And there are many packages with the same problem on the wild.
Right, people forked & fixed, but the fix cannot be contributed back to the D community. Other users are still getting the original buggy version from dub, and don't have an easy way to find new patches. So the main blocker is to get the write permission (of the unmaintained packages) of the dub system, this will solve lots of these problems. Or we should setup a new policy that any new dub packages should give write permission to dlang-community by default.
How about putting every packages under dlang-community under a repo maintained by community so anyone else can accept pull request. If anyone else starts another decimal package, it'll also end up the same way most likely. It's about time we have packages regarded as core with the community in charge...so we can direct contributions to them. Every fix gets submitted there...
May 23
parent reply aberba <karabutaworld gmail.com> writes:
On Saturday, 23 May 2020 at 17:46:42 UTC, aberba wrote:
 On Saturday, 23 May 2020 at 17:10:27 UTC, mw wrote:
 On Saturday, 23 May 2020 at 07:27:50 UTC, Luis wrote:
 Because this, I forked two small packages and get it under my 
 wing, with the self-compromise that at least I will keep it 
 working on future versions of D. However, I published they 
 with different names and changing the module name. Something 
 that should be totally unnecessary.

 And there are many packages with the same problem on the wild.
Right, people forked & fixed, but the fix cannot be contributed back to the D community. Other users are still getting the original buggy version from dub, and don't have an easy way to find new patches. So the main blocker is to get the write permission (of the unmaintained packages) of the dub system, this will solve lots of these problems. Or we should setup a new policy that any new dub packages should give write permission to dlang-community by default.
How about putting every packages under dlang-community under a repo maintained by community so anyone else can accept pull request. If anyone else starts another decimal package, it'll also end up the same way most likely. It's about time we have packages regarded as core with the community in charge...so we can direct contributions to them. Every fix gets submitted there...
The community here is very week. I've also talked to lack of focus on community building. Every open source endure needs a strong community to make things happen under a collective effort. Until there's official push and dedication to making that happen, we'll also be overruns by things to do.
May 23
parent aberba <karabutaworld gmail.com> writes:
On Saturday, 23 May 2020 at 17:49:59 UTC, aberba wrote:

I meant... The community here has always been very week. I've often talked about lack of focus on community building. Every open source endeavor needs a strong community to make things happen under a collective effort. Until there's official push and dedication to making that happen, we'll always be overrun by things to do. The more the hands on deck, the less it remains for each one to have to do. I'm having a love and hate relationship with D right now.
May 23
prev sibling parent Basile B. <b2.temp gmx.com> writes:
On Saturday, 23 May 2020 at 17:10:27 UTC, mw wrote:
 On Saturday, 23 May 2020 at 07:27:50 UTC, Luis wrote:
 Because this, I forked two small packages and get it under my 
 wing, with the self-compromise that at least I will keep it 
 working on future versions of D. However, I published they 
 with different names and changing the module name. Something 
 that should be totally unnecessary.

 And there are many packages with the same problem on the wild.
Right, people forked & fixed, but the fix cannot be contributed back to the D community. Other users are still getting the original buggy version from dub, and don't have an easy way to find new patches. So the main blocker is to get the write permission (of the unmaintained packages) of the dub system, this will solve lots of these problems. Or we should setup a new policy that any new dub packages should give write permission to dlang-community by default.
https://github.com/dlang-community was created for that. https://github.com/dlang-community/discussions#adoption-guidelines.
May 23