code.dlang community transfer repository
Steven Schveighoffer via Digitalmars-d
digitalmars-d at puremagic.com
Thu Apr 23 09:00:31 PDT 2015
On 4/23/15 11:43 AM, Jesse Phillips wrote:
> Dub provides an easy way to utilizes 3rd party libraries, github
> provides an easy way to revive a project no longer being maintained by
> the author. Can we come up with a solution within code.dlang to take
> advantage of this?
>
> While I'd prefer if the project owner would proved commit rights to
> their contributors (or subset of such). This doesn't usually happen, and
> you can't always get into contact with them.
>
> My example is dini[1]. There is a pull request to get it working with
> 2.067, it hasn't been merged in the last 29 days with latest
> modifications being from January.
>
> In order to keep the projects in code.dlang.org relevant, I think it is
> important that we provide a way to have the primary project change
> hands, rather than require the fork be placed on to code.dlang.org too[2].
>
>
> 1. https://github.com/robik/DIni/pulls
> 2. http://code.dlang.org/packages/tharsis-dimgui
I think it would be good to be able to organize code.dlang.org by
compiler that it works with.
For example, if I want to know all the projects that work with 2.067,
then I can filter based on that.
Then you can put the fork into a newer compiler category, and force the
old one out of it.
Not perfect, but I don't think there really is anything we can do about
no-longer-maintained projects. It's not fair to the author that they can
have their project taken over and published with their name. At least we
can have a way to avoid displaying projects that are broken.
-Steve
More information about the Digitalmars-d
mailing list