Is this project being actively worked, or is it abandoned?
LarrySmith-1437 opened this issue · comments
I've used this library quite a bit, and have always liked it. I stopped in to see how things are going, to find a lot of issues and outstanding pull requests.
I'm curious to know if there's anyone who is an active custodian for the project and if it's receiving any updates or fixes.
Yes, there are people working on the project. One of the issues, four eighty five (spelled out to prevent auto issue link) was responded to by part of the community barely 14 days ago.
I also respond as well to some of the questions.
What is the reason you ask? Would be great to have another contributor etc! Any help is certainly welcome and appreciated
I watch the issue queue and try to help out with questions, but I don't really have the time to actively develop this project. I'm happy to accept pull requests too, but I don't own the project so I'm a little hesitant about making huge architecture changes. Bug fixes are A-OK though.
That said, the project's owner has been in and out of contact (mostly out) for the past few years so I'm not sure if/when he will come back.
Well, there were a few reasons that prompted me to ask. This is the library I go to for command line parsing support. My apps are moving over to .net core and .net standard. Given it's importance to me, I wanted to see how it was doing.
When I started looking around at the project overall, I saw a high count of outstanding (not closed) issues, outstanding code pulls, no code commits since 2/17 (until, I see now, there was just a commit today for the readme.md), plus a whole host of forks, many of which are dead, including the one that the original author designated in the Wiki as his favorite to take on the mantle temporarily as a maintained fork, namely https://github.com/cosmo0/commandline
That plus it's had a beta release pending since at least midway through 20015... It lead me to wonder.
Really the worst sin that I see here are people actively trying to contribute, whose work lies scattered among the 14 still open pull requests that are months and even years old.
It's sad, but this smells like a zombie library.
I'd like to append my answer. I think in stating my reasons for asking the question, I may have sounded a little negative. I'm not negging the project, I love it! I've just been away from the pulse of it a good long time.
So, are there people who are minding the store? Someone with the permissions to act on the issues and code? (maybe the owner could be put upon to turn over the mantle?)
If not here, then is there an active fork to take on the lead?
So after thinking about this more, there seems to be no leader in place, and nobody wants to take the role. Not a problem... life throws things at people and you gotta adjust. @gsscoder if you're listening, chime in! We need to push the project forward.
I am tempted to nominate myself for creating an official fork and new official nuget package and being the driving force for new releases, managing issues, reviewing pull requests etc
If I'm wrong that there no leadership here, let's discuss it.
We have to start moving the project forward. This is why it makes the most since to start a team and adopt the project into the team and allow for a more responsible group of people instead of a single.
I'm also going to research appveyor support of team based instead of individual accounts and switch other OSC projects into team based as well, so I dont become the bottleneck of progress.
So next steps would be:
- Establish new leadership of the project. I will assist and push the agenda forward as a (self)nominated leader to get this project on track.
- Deal with ownership of the code.
-- Option A, we petition github admins to either mark this exact repo as abandoned or defunct with a proper link to our team based repo. We then start manually dealing with the pull requests, perhaps a bulk copy/transfer of issues via code (github apis) from this repo to the new one
-- Option B, we petition github admins to transfer ownership of this repo to the team. This obviously is best because issues/pull requests/etc dont get lost and have to be recreated.
@ericnewton76 I've been thinking about this lately as well. I think it would be good if you or someone else picked up a fork to integrate more meaningful changes/features to the library. Once that is done I can make an additional commit to this repo that deletes all files except the README, noting that the project has moved. If @gsscoder finds the time to work on this again, he can restore from the previous commit and keep working.
I guess that once the new leadership and team for the fork is established and settled, it would be great that the team proposes to the community a basic roadmap for the new fork, with same major user stories and a rough time frame for the main items on the roadmap.
Just to give some more feedback on the roadmap to propose, it would be awesome if it (eventually) includes a branch for a .NET Core version and a branch for the (existing) .NET Standard version.
Kind regards, GEN
FYI @gaston-e-nusimovich both the latest beta and the master branch of this repository fully support .net core (standard 1.5, if I remember correctly)
Road map for time being is simple:
- get to a stable version to publish to nuget. Realistically the current codebase appears stable enough to at least put out a formal v2 release. You guys will have to clue me in on how ready for release it is. Timeframe mid Nov 2017.
- Full support for lowest NetStandard support, i'm thinking NetStandard 1.3 for Framework v4.5.2+. Address issues with that low of netstandard support or just say unsupported. I see some conditional compilations in there, would like to minimize that as much as possible... thats the whole point of NetStandard in the first place. Timeframe mid Dec 2017 (possibly)
- Squash any real major bugs for a solid v2.1 release. Timeframe end of Jan 2018
For New Features, I dont know what really would be needed beyond whats already here. Call out issues on this discussion of desired features.
@nemec do you have direct commit powers to this repo? do you have the ability to go to settings and transfer ownership? if so, we should create a github team, add yourself, gsscoder, myself and then we can start establishing pull request reviewers and branch management to control the process of releasing.
Then we have to petition nuget to reassign that packageid to the team (if possible) so we can get some formal proper releases out there
I have commit privileges but no access to the repository settings (I think that's reserved for gsscoder). As a co-owner of the NuGet package it looks like I can add new owners at will, so I don't think it will be a problem to add you. There is no built-in concept of team ownership:
"For example, the Microsoft ASP.NET packages are co-owned by microsoft, aspnet, and sometimes individuals on the feature team. The ‘microsoft’ and ‘aspnet’ accounts are simply set up with a mailing list email address that reaches the teams that manage the accounts."
If you don't mind, will you do the team setup + fork? I think you've come up with a good plan.
Maybe it is time to fork the project and move on...
I have had pull request to add pluggable object factories open since july
FYI, new github organization created, "commandlineparser" at https://github.com/commandlineparser with nemec, myself, gsscoder as co-leaders
Forked this repo into https://github.com/commandlineparser/commandline
General Question: I have found a python3 script that can copy github issues from repo to repo. So should we copy all OPEN issues only, or ALL issues as preservation?
IMHO, I suggest that you copy only open issues into the new repo. Any user can navigate back to the previous repo and search for any given closed issue.
In the new repo, commandlineparser/commandline here's a few things I'd like to do to have more process control around releasing:
- I also propose having a formal release branch that actually kicks off a release build into Nuget/Github Releases/etc. All developer forks/work is still based on master. Release will never really have actual commits to it, but provides a last stop guard on the road to publishing a release during build/deployment process.
- Update Appveyor with correct version number and Fake to actually utilize it. It does support "2.1.1-beta" and a pull request could make a pull request that includes an update the version number if their pull request makes a breaking change (ie, increment major) I think nemec, myself and others will end up coordinating on that and having final say, by either submitting a commit into master updating appveyor.yml with correct version then merge into release
Any objections?
Started an issue that will be a progress report in the new repo:
I am good with that , can we move open pull requests to the new repo automatically as well ?
i know there is an import tool not sure if that works with other github repos or not
guess not , looks like it only does repo cloning