Discussion in 'BukkitDev Information and Feedback' started by black_ixx, Apr 4, 2013.
That file would not be on DBO, and we'd remove your project and likely ban you once we found out.
We're trying to give you a way to throw out your own versions as devs/beta/whatever without using the approval queue, and CI is the best way we've found to do that. The point is that the liability is not on our shoulders. People come to trust BukkitDev and its staff's judgement because of our track record, but that does not apply to your server. People have to make that decision themselves, and they can't complain to us if their trust is misplaced.
If you put malicious builds on a CI and we catch you, we'll ban you, but it isn't at all our fault.
So from my understanding, we are not allowed to link to unapproved files on DBO under any circumstance. So why are these pages even accessible to users who are not project members?
Many of the other projects that are hosted on CurseForge do not have these same restrictions we do, hence it is still visible.
I can clearly see it from your point (Bukkit as a malware-free platform), but I was asking myself: "If a CI, which clearly differs from Bukkit and doesn't give the feeling that the files are approved, is allowed - why isn't a webpage that completely differs from Bukkit as well?"
I quickly created an example to show you what I mean:
I could upload each dev-build on Bukkit, but I really don't want to do that to the approval team and it would slow down the process (e.g. fixing a bug.)
It's not a problem for me to send a PM to the person in question, but I would like to keep the whole conversation (and test-fixes) public.
I don't want to enforce this; I like the safety that Bukkit gives the users, but I would like to see you seeing my point there as well. If you don't want it I'll stick to your decision of course.
We have debated this extensively over multiple months. At the end of the day we keep coming back to our decision as mentioned.
Ok, I thought it was something like that. But if you subscribe to file updates then you are given a link to the unapproved file. I'm sure that this also cannot be changed by Bukkit but I was just wondering wut you guys thought of it.
Incorrect. For CI servers, you need to put the following disclaimer (source: the Bukkit wiki):
Those are unapproved builds, and they can be linked, albeit with a disclaimer.
What's wrong with sending the download link through a private message. Wouldn't that have been much easier than this entire conversation.
There is nothing wrong about it, only this one point above.
Well let's say your current build has a security hole and the players are able to cheat x (for example money or items). The server owners need it to be fixed as soon as possible and they are a huge amount of people. Sending private messages would take years and not everybody of the people will send a comment that he needs the fix. In this case PMs would not help very much.
Ok, then in this special case you could tell it the Bukkit Staff. But I think that PMs are not very helpful.
I see, I misread your original post, I thought you were saying only 1 person was after the updated version.
I guess you could have left a link in the comments, but i guess that would probably end up being removed, and maybe not everyone would of seen it. In response to your last post, I have to agree. There should be a way to link un-approved files. Although saying that, i uploaded a file yesterday and it was approved within around 3-4 hours. Not too long to wait i guess.
If the file is a fix that should be released instantly for everyone then upload it as normal and then click the "report file" button. Notice that you can get punished for abusing this.
What I don't get is, where is the difference between:
I mean, except that my custom site actually has an additional disclaimer.
Both clearly look apart from bukkit. If both would be linked via the disclaimer in a project, the later one would be removed saying don't link unapproved files, but seriously, it doesn't make any sense.
Yeah that's pretty much what I told them, why did you copy my words?
That's not a CI... it doesn't look like one.
This is a CI http://build.sk89q.com/
I'm amazed. I didn't know how a CI looks like. That was entirely my point. My argument is totally invalid now. You really got my point there. Good job.
(inbefore you notice I posted by own REAL CI before that link)
CreeperShift Sorry, http://creepcraft.net:8080/job/CraftArrows/ didn't load for me (blank page) so I thought it was just a random URL...
No, I actually set up a jenkins, which I think is totally idiotic for my small plugin. My point is, what really is the difference between linking to a real CI, without a disclaimer, without showing off the changes, or simply linking to my static page, which has a disclaimer and describes all the changes.
The jenkins has links to the build changes in the source code. It shows me what was changed and I can see if there is unwanted codes in there.
Your page looks hand made and the jar could have just about anything in it.
I could easily hide the sourcecode in the jenkins, it doesn't say it's required to be visible.
CreeperShift Well I'm fed up getting trolled here
This is a CI - http://creepcraft.net:8080/job/CraftArrows/
This is a website - http://creepcraft.net/CI/
It should be clear what is the difference. You are right, we do not specify the need to view the source code on the CI as we do not want to be overly restrictive, but that's always a nice addition. Ultimately the CI is up to you how you want to set it up.
Keep in mind allowing CI links on project pages is a privilege we allow for developers who want to allow a small subset of their users test their plugins before they are ready to release them to the general public. For small plugins, there is almost no need for a CI as you can utilize the Alpha/Beta/Release system on dev.bukkit.org, and you can reach out to the BukkitDev staff if you have a serious bug in your plugin that your latest unapproved file fixes.
What? If you keep going on and off about stuff I don't mean, then sure, no need to discuss with me.
Yes, of course it's clear whats the difference. I meant in terms of why it's not allowed, and what harm is done by using the static website.
As for using Alpha/Beta/Release system on dev.bukkit.org, you said it yourself. People think it's from bukkit.org and download it, no matter what it says. Then I have tons and tons of people complaining why there are debug messages, why x is not completely implemented yet and so on.
What I just don't understand is, where is the harm done if the website that is linked is not a CI? I mean, technically it has a disclaimer, it lists all the changes, it labels it as a beta builds, etc. It would just take away the need to spend extra resources to run the CI in the background.
What my main issue is here is why it's such a big problem for you guys to allow both. (No offense, I'm just trying to understand because it simply makes no sense for me).
Yes, you are trying to protect the user who doesn't know better, but will he act any differently whether hes confronted with a static page or a CI?
A CI is clear to an server admin what it is, and what its uses are. No one can be sure what a website is serving up.
You can document such on your change log for the file. You would get the same support questions on a CI link. I do not see any difference to what support you would need to provide.
We have stated many times we only allow CI links. Websites can be changed, altered, modified, redirected, or otherwise changed to provide an unfamiliar and alarming user experience. While you can argue that a CI link could also be altered, we would expect users would not abuse this concession we have made in our rules to allow CI links and make it undesirable for us to allow CI links in the future.
I do not see a need to expand our allowance of CI links to allow people to advertise their website which also happens to host development builds of their plugins. "Why don't you allow websites beyond a CI" is a very slippery slope we will not be going down.
Alright, although I strongly disagree, I see that you and your team have already set their minds to the decision and wont change it, so I will save myself the trouble of trying to convince you otherwise. I'll just leave my jenkins up and running, but if I really wanted to I could pretty much do all the harm you described up there with my jenkins aswell.
Anyways, thanks for at least clearing things up, I appreciate it!
You definitely could ruin it for everyone, you are correct. I do not see how that helps your cause in anyway.
I was just stating that it doesn't matter whether it's CI or a website, harm done is harm done. Anyways, I respect your decision so there is no need to continue discussing this
I disagree, it matters a great deal. You may not see the difference, but we do.
Separate names with a comma.