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

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

On Thursday, 23 April 2015 at 16:00:31 UTC, Steven Schveighoffer wrote:
> 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

Github already allows this, it also makes sure modifications are correctly authored (at least with the author specified in the commit, which can easily be faked). It think it is completely fair, the author published their source for others to use and modify, if someone else can pick up that maintenance fairly easily then they have achieved their goal, otherwise it will die with their loss of interest.

On 4/23/15 1:57 PM, Jesse Phillips wrote:
> On Thursday, 23 April 2015 at 16:00:31 UTC, Steven Schveighoffer wrote:
>> 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
>
> Github already allows this, it also makes sure modifications are
> correctly authored (at least with the author specified in the commit,
> which can easily be faked). It think it is completely fair, the author
> published their source for others to use and modify, if someone else can
> pick up that maintenance fairly easily then they have achieved their
> goal, otherwise it will die with their loss of interest.

Well, I admit to have selfish goals in my statement :)

For example, I have a very old bit-rotting project in dcollections. However, I do plan on resurrecting it. But what happens when I make my updates, and find that someone else has taken over and taken the project in a different direction than I wanted to?

If you are going to fork, you need to give it a new name. This is standard practice for open source projects.

-Steve

On 4/23/2015 10:57 AM, Jesse Phillips wrote:
> Github already allows this, it also makes sure modifications are correctly
> authored (at least with the author specified in the commit, which can easily be
> faked). It think it is completely fair, the author published their source for
> others to use and modify, if someone else can pick up that maintenance fairly
> easily then they have achieved their goal, otherwise it will die with their loss
> of interest.

It's one of the reasons we promote using the Boost license. It enables anyone to pick up the fallen flag.

On Thursday, 23 April 2015 at 15:43:43 UTC, 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

Personally, I think the bigger problem with projects on code.dlang.org is that there is no vetting process. Any and all projects are accepted, with no requirement for a project to be "good". A lot of projects in there are both unusable and not particularly useful in the first place.

Of course, having someone review a project before it's accepted into the repository makes a huge amount of work, and that's manpower that probably isn't available.

I think a simple voting system would be a good idea combined with the ability to sort the projects on category and on number of votes. Good projects will naturally gravitate towards the top then. Un-kept, buggy projects will fall to the bottom too, potentially solving your problem too!

On Friday, 24 April 2015 at 08:05:18 UTC, wobbles wrote:
> On Thursday, 23 April 2015 at 15:43:43 UTC, 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
>
> Personally, I think the bigger problem with projects on code.dlang.org is that there is no vetting process. Any and all projects are accepted, with no requirement for a project to be "good". A lot of projects in there are both unusable and not particularly useful in the first place.
>
> Of course, having someone review a project before it's accepted into the repository makes a huge amount of work, and that's manpower that probably isn't available.
>
> I think a simple voting system would be a good idea combined with the ability to sort the projects on category and on number of votes. Good projects will naturally gravitate towards the top then. Un-kept, buggy projects will fall to the bottom too, potentially solving your problem too!

let's just use the github stars system. i guess the github API allows us to query those too. maybe we can even star a project from the registry too ?!

On 04/24/2015 12:08 PM, extrawurst wrote:
> 
> let's just use the github stars system. i guess the github API allows us to query those too. maybe we can even star a project from the registry too ?!

Interesting idea, but github centric. We already have download numbers
and would just need to cache and show them in a prominent place.
You can already add a badge to your project with it's download numbers,
see http://shields.io/.

On 04/23/2015 08:49 PM, Steven Schveighoffer wrote:
> If you are going to fork, you need to give it a new name. This is standard practice for open source projects.

It's a common practice on github to take over small but no longer maintained projects. You give credit to the original author and things should be fine.

On 04/23/2015 05:43 PM, Jesse Phillips wrote:
> 
> 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].

Write a mail to Söhnke, he can change the project owner. In the mid-term we want to have admins for dub-registry (https://github.com/D-Programming-Language/dub-registry/issues/90).