I personally would not put MY seal of approval on something I didn’t build myself, but whatever.
Well, I’m sure a ton of closed-source freeware software developers will disagree with you on that one.
But one thing I absolutely don’t get. In what way does this whole idea make it easier for staff to review a plugin? They’ll still have to go through the same code. Also, it wouldn’t require building the plugin. And no, comments aren’t a valid argument:
/**
* @param user The user to give candy to.
**/
public void op(String user) {
...
}
Oh. that gives a user candy. Let’s skip it based on its comment…
Oh, do you also write that I have to agree to the Travis ToS now? Preferrably transfer the rights to my code to sponge so they can sublicense it for Travis so they are even allowed to host it?
And also, what if I don’t host my code on giithub at all?
Then why should the Sponge team? In 99% of cases their reputation is far greater than yours, and thus matters more for user trust.
Aside from closed-source freemium software (free for individuals, costs for organizations) they don’t exactly have much of a leg to stand on either.
You seem to be under the illusion that source code corresponds 1:1 to bytecode and will always cleanly decompile back. That’s no longer the case, both because of alternative JVM languages like Scala and features that had to be implemented as translations to old JVM instructions, either because it was cleaner that way or just because of backwards compatibility. Besides, did you hear about that recent decompiler exploit?
No need to transfer the rights, just provide it under a license so that they can sublicense it. Since it’s FOSS that’d be the case anyway, right?
I haven’t used it much, but Drone.io also seems to support Bitbucket. Travis was just an example that is already widely used.
I don’t care. I wouldn’t sell something I made to people if I didn’t build it.
Thats your opinion…
I know very well about how Java bytecode and decompilers work. There is no reason to talk down to me about it. And yes, I heard of that exploit that affected two decompilers afaik. But you seem to believe that code produced by decompilers greadly differs from the original source. That isn’t the case. The decompiled source may look different but will act exactly the same when compiled as the original source in pretty much all cases (and thats often just because the decompiler isn’t using the latest JLS). And if there is FOP or sth similar in the original code, it will still be there and visible in decompiled code.
Not necessarily. In fact, there are many licenses that are not OS by definition but involve making code publicly available.
Anyway, these services pretty much always require admin access to your repo or require you to edit your commit hooks. And no, I (and probably many others) are not going to open up administration of a repo to sponge staff. Also, how’d that review process work? They couldn’t review every commit anyway.
EDIT:
Don’t get me wrong on this, I’m not dead against some of the things you and @LokiChaos mentioned, I’m just a bit sceptical wether that is necessary and can be done in an efficient was that doesn’t require developers to adapt their development process on a large scale.
It technically accomplishes the same thing, but is generally far less readable than the original source.
Doesn’t matter, assuming Sponge has another licensing requirement than that the source is publicly available.
Both Bitbucket and GitHub support generating a diff between two arbitrary commits. Piece of cake to integrate that once you know which commits correspond to which releases.
It’s not too bad IMO, but dependng on what you use, the results can of course vary.
Yes they do. Although that brings us back to the argument wether or not it is enough to just check a diff… blah… blah. But yes.
So you’d make it so instead of an upload button there’d be a “Review Commit” (or similar) button? I still think that the implementation of some sort of CI would end up being quite complicated. And you’ll always find something that doesn’t work fwith the specific system you have in place for building.
I think that each plugin page should contain community votes and reviews, big and shiny “seal of approval” if plugin was checked by moderators, BUT server owner should be able to download plugin anyway. Page just can show a warning if plugin was not reviewed by moderators, but people running a server must use their own brains and choose: wait or take a risk.
Sorry about my poor English.
I like this idea the most. Being able to to quickly release hot fixes is often essential to plugins, and having a system like this would be great. If you trust the author, you can download it immediately, or you can even decompile the file(s) yourself if you’re not sure of their validity.
I’m all for that.
We should get our Essentials, WorldEdit, WorldGuard, … plugins together as soon as possible, that will help us extending our community by one or another server owner.
People familiar with StackExchange should find what I’m about to say somewhat familiar.
Start off with your first proposal of staff reviewing. As members gain higher reputation, members above a set reputation level can review plugins of new members.
Basically:
Staff & Trusted members review first round of plugins
As time goes, developers can also review plugins of newer members and their own plugins are instantly available
Only downside I can see is that a developer goes rogue.
I think a plugin should be instantly available, with a big warning, saying that it’s not verified by trusted (staff) members, which means that it could include highly malicious code.
That way the server owner had to decide whether to download it or not.
This is an interesting idea. I think it could be a real help when it comes to workload. Although the platform shouldn’t be entirely community moderated and reviewed.
@Pink__Slime
Really like that idea, an additional report button could still be placed next to each file, just in case something slips through. Maybe require review of two trusted users or one staff member to ensure that no single trusted user who got pissed in some way is able to distribute malicious code.
I like the Idea of having it that way. Having two trusted developers, or one Moderator. Though for the process of getting trusted developer; I think only moderators/admins can assign the rank of trusted developer once a certain status has been met. So for example the base requirement is 300 reviews (remember just an example, not suggesting this should actually be the requirement) of plugins. Once a developer reaches that status a moderator can determine if he is trusted enough to get the status.
Also to make sure developers don’t go rogue I think each plugin reviewers should be chosen at random. So not just any plugin reviewer can pick it up, and two developers wanting to hurt the community can.
People are assuming that there are and still will be tons of good willed people for the life of the project that are willing to spend countless thankless hours reviewing plugins for nothing in return. BukkitDev Staff were entirely picked from community members and it was a struggle to get people to review files after the excitement of being a new staff member wore off.
Sure, but there is no other way to do it if you do not want to go completely without any reviews I guess.
Of course it would be better to have some kind of reward system, either some kind of rank (virtuel thing users can be proud of) or something else (even though I got no other idea at the moment).
.