www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - code.dlang community transfer repository

reply "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
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
Apr 23 2015
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Apr 23 2015
parent reply "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
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.
Apr 23 2015
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Apr 23 2015
parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
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.
Apr 24 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 23 2015
prev sibling next sibling parent reply "wobbles" <grogan.colin gmail.com> writes:
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!
Apr 24 2015
parent reply "extrawurst" <stephan extrawurst.org> writes:
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 ?!
Apr 24 2015
parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
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/.
Apr 24 2015
prev sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
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).
Apr 24 2015