Remaining fosshub packages are:
Furthermore
All those could be embeded or, if too big, alternative location can be found.
/cc @gep13 @ferventcoder @AdmiringWorm
@gep13 could you deprecate it ? I would do it but requirement is to get versions unlisted.
I think we should deprecate it ASAP as it doesnt work anyway.
@majkinetor let me know what you think of this: https://github.com/chocolatey/chocolatey-coreteampackages/pull/447
I've started working on embedding the codeblocks package.
codeblocks done: https://github.com/chocolatey/chocolatey-coreteampackages/pull/450
@majkinetor FossHub Extension package is now fully deprecated, and only listing the 0.6.1 package which simply writes out that it isn't supported any more.
Made audacity embeded. Used filehippo as download location.
BTW, it suffered from Vector smash. I hade to parse HTML using sls, check out its updater.
Vector smash kicked without -UseBasicParsing. When I added it, it blocked when accessing links property. Content property works always fine so far.
I have lightalloy embedable package ready (from filehippo) but on this page license doesn't allow redistribution.
Furthermore, the source code on github is 3y old, and it doesn't seem the package has users. I think we should simply deprecate the pacakge and unlist all of its versions.
@gep13 @AdmiringWorm
on this page license doesn't allow redistribution.
That is medocow's license. I can see how it might be confusing and probably technically not enforceable for them to add that.
"A License Agreement (further the "Agreement") is an agreement concluded between a User (a legal entity or an individual entrepreneur) and the medocow.com website about Light Alloy (the "Program")."
Perhaps the portable version has information on the actual license.
We are probably okay to deprecate it though.
Thanks for the input @ferventcoder.
I will deprecate the package.
Ok, this resolves our fosshub problems.
I think there may be a misunderstanding on deprecation of a package. Deprecation is to point to another package that will be maintained. If we are simply not going to offer a package anymore, you just simply unlist all versions.
I only now found out that lightalloy had stopped updating.
Don't remove the package; I added it for a reason. Deprecate reasons by @majkinetor are arbitrary:
Help fix the non-fosshub autopackage in stead: https://github.com/chocolatey/chocolatey-coreteampackages/pull/585
Deprecate reasons by @majkinetor are arbitrary
I disagree.
not too popular but more downloads than a hundred of chocolatey packages.
So what ? Should core team serve as pile of everything that ever existed ? Any new package means more maintenance means more overburn on developers here means people will leave and important packages will not get updated. Rather, its best to collect here mainstream tools because those are the kind that are served every day and people depend on them and they generate bunch of work already (especially with demand for parallel versions).
Keep in mind that this is the core repository it doesn't have the same standards nor motivation as random package submited by random user.
I disagree.
I shall rephrase: Deprecate reasons are _false_.
There __is__ active development. There __is__ a permissive license. There __are__ chocolatey users.
Furthermore, I don't think the core repository should be in the business of removing packages that it had previously picked up. For a time we actively brought in packages that were orphaned.
There was an ongoing discussion about whether it's better to bring all packages under one public repository, or make the core team selective and difficult-to-get-in, more of a prestige project. It was decided at the time that it was better to bring all packages together under one single repository where any volunteer with interest in (a fix for) a certain package can do a PR, rather than have them abandoned and outdated forever.
If this has changed, please update the readme.
This repository exists to bring community packages under one repository where they can be developed and maintained by the community.
One possible argument left is the number of downloads.
Keep in mind that this is the core repository it doesn't have the same standards
I read nowhere that packages shall be removed when they don't meet a certain popularity. I would wholeheartedly oppose such a policy.
But even if that's the case, I would like to point out that lightalloy had 350 downloads in a year, of which it was broken most of the time. Here are some other other packages hiding in the repository that need deprecation by those standards:
assaultcube had 950 downloads in 4 years. That's 340/year.qtox had 300 downloads in a year.becyicongrabber had 640 downloads in 4 years. That's 160/year. svg-explorer-extension has 600 downloads in 4 years. That's 150/year.vp8-vfw had 560 downloads in 4 years. That's 140/year.sauerbraten had 450 downloads in 4 years. That's 110/year. secret-maryo-chronicles had 360 downloads in 4 years. That's 90/year.Anyway, the lightalloy package is now up and running again.
There are chocolatey users.
Yeah, I was wrong, there are users

If we exclude bots its probably only somebody who did type lightalloy by mistake instad asdf ;)
Furthermore, I don't think the core repository should be in the business of removing packages that it had previously picked up. For a time we actively brought in packages that were orphaned.
Times change. For a reason.
If this has changed, please update the readme.
See guidelines on wiki. Also read about priorities:
https://github.com/chocolatey/chocolatey-coreteampackages/wiki/Package-priorities
Here are some other other packages hiding in the repository that need deprecation by those standards
I also didn't want to deprecate all existing packages but at that time we didn't have more then 2 constant maintainers. In the meantime nothing changed much, it went worst actually. Lightalloy also required knowledge of AHK/AU.
Listen, feel free to maintain lightalloy, I certainly don't mind even opposite. Just have some perspective, and don't think what I wrote there is personal preference. The core repo was in embarrassingly sorry state before me and few others took over to modernize it and move to AU. It took a half year of full time job to set it right (and another half to develop AU).
@majkinetor said:
The core repo was in embarrassingly sorry state before me and few others took over to modernize it
Thank you for that. I know disagreements and criticism can feel like total disregard for the good things. I love what you and others have done to this place.*
Although personally I'd phrase _"took over to modernize"_ as _"joined to modernize"_. People before you have spent time getting things up to a standard, including PRs to Chocolatey prior to the crowdfund.
*) Except for this policy of rejecting or deprecating packages. Everyone who created a package is part of the community. The README reminds us that this repository exists to bring those _"community packages under one repository"_. I still share that philosophy. Your philosophy is more like the _"core packages"_ concept. Only important/popular packages. You can see that this conflict is from ancient times in the ambiguity of this repository being named _"core team packages"_ and referred to as _"community packages"_ everywhere.
You developed AU? In that case you get +3 extra respect bonus points from me. It enhances things considerably.
Although personally I'd phrase "took over to modernize" as "joined to modernize". People before you have spent time getting things up to a standard, including PRs to Chocolatey prior to the crowdfund.
No and no.
You guys might want to behave politically correct but I am not on that train. I know what happened and it wasn't easy. Saying otherwise is just disrespectful. You have to give credit where credit is due. We basically rewrote everything and made it 100% transparent and repeatable. We could have started from the new repo and it would probably be way easier.
The README reminds us that this repository exists to bring those "community packages under one repository". I still share that philosophy. Your philosophy is more like the "core packages" concept.
README.md should be changed IMO (never did it because of intrusion factor). That was not only my philosophy but of the people involved in that moment (everything was extensively discussed on Gitter and here)- if you were present back then, perhaps things would be different). I am all for constructive criticism, but more importantly, I am more for 'get the stuff done' mentality in a manner that can maximize the bus factor - you have to think - when you are out of here, what will happen.
Everyone who created a package is part of the community
_Was_ the part of the community. One rarely _is_. People scratch their itch and then leave to other people to continue dealing with consequences. And the world is actually about consequences. Thats why its very hard to contribute to any serious foss project.
You developed AU? In that case you get +3 extra respect bonus points from me. It enhances things considerably.
Yes, and that was far from easy and not because of technological reasons. If the ambient were more responsive it would probably do everything on its own now.
Be all as it may, I value good arguing. Don't think that because I disagree that I don't value good input.
No and no. (..) You have to give credit where credit is due.
Well there's a paradox. Which is it? I'd say the top 5 committers to (pre-crowdsale) chocolatey deserve credit. Or rather everyone. And probably the top 10 committers to this repo. Or rather everyone. It gave traction. I don't want to turn this into a pissing contest because you'd win hands down and that's why you are entitled to some arrogance. It is however easy to disregard the things that lead up to a thing, and giving credit has nothing to do with PC.
If the ambient were more responsive it would probably do everything on its own now.
I think you've drilled down to the reason _why_ people left. That, and arguing. And the perfect solution fallacy. All with good intentions of course; you don't always get to be at the shaping stages of a thing. But still.