Discussion in 'BukkitDev Information and Feedback' started by emericask8ur, Jun 28, 2012.
Mine approved in 3 hours like a boss. Kthxbai.
Can't tell if grateful... or sarcastic... :l
Grateful! But if you dont believe me then.
I was one of those pieces of meat!
So do I. It's not like I have anything better to do all day.
Hey Bukkit team, whats the approval times on the forum now? It's almost 2 days and still not approved here.
The forum system is being phased out, don't expect things to be approved.
Being phased out, but not completely phased out? So being approved should still happen, right? I did read about it being phased out, but still being approved for now until that date comes.
Well yes, some projects are still approved, but it's /only/ when the moderators have spare time to go through submissions, which is not a lot of the time. We are coming close to the point where the last pieces will fall into place at BukkitDev, and we will be able to get rid of the forum plugin system completely, so there's really no point in making the forum staff waste their time on that.
Reminder- Don't ask for (subtlely or otherwise) a promotion, especially if it takes the thread off topic.
Okay, on topic then. It took ~18 hours for my last file to be approved, which I can't complain about, but I did wish that approval times stayed under 12 hours. :/
nala3 We are in the process of training 5 new staff, and our existing bot (called h31ix) broke down, so we've had a few instances where the queue may have taken a bit longer than desired. However, we are constantly striving to keep the approval times low.
I know you are, and I understand that it's a pain to look through all of the submissions.
I find it fascinating so far actually !
*takes note of this*
The last time I submitted, it took 2 minutes for the project to be approved and 5 minutes for the file
Is he open source? I wouldn't mind scanning the code some, maybe submitting a few patches, here and there...
Would it help any if projects were assigned to a staff and between versions you just check what code changed? Just a thought.
When I do changes at my job and forgot what it was (because it's such a huge unorganized project) I compare both file source to see what changed.
No, it wouldn't help and it wouldn't work. What if the assigned staff member is in vacation or sick or just wants to take care of other things for a few days? We are just volunteers who, and you can count on that, put a lot of effort in our tasks. After all, this a hobby to most of us. And even if we take it very serious, there are sometimes more important things in our life. So it's better for everyone if something gets done by someone who is currently available. The time zones would be another problem in this matter.
For the second point: this would mean that everyone would keep all files on the disk, what is not practical. When I'm clearing my Recycle Bin after reviewing a bunch of files at the end of the day, I usually delete around 1500 files and more. Also the directory (or package) structure may change between versions, what makes comparing different versions even more complicated.
this forum was very discouraging after 7 hours you begin to lose hope. (plugin is RWtorchLight)
We get through plugins as quickly as we can. 7 hours is a long nap. Don't worry, we get through them all
seven hours and you start to lose hope? You can watch lord of the rings (3hrs long per part!) and come back with the plugin approved by the orange staff of the Bukkit Dev's
That should work out great because that's what we do!
Watch the whole trilogy between each plugin!
you guys... 7 hours is nothing. Ive had it take over a day:0
But then again, one day it took less then 10 minutes:3
What about adding some checkboxes to the BukkitDev file upload page? Plugin authors can declare this way what type of update it is. Suggestions: "Compatiblity Fix", "New Features", "Various Fixes and Improvements" and "Critical Bug Fix".
When "Critical Bux Fix" is checked the plugin will be highlighted (red) in the list of files to approve. "Compatibility Fix" releases could be highlighted too (orange) - especially if a new Minecraft/Bukkit version is out.
Abuse of the system:
The BukkitDev team is decompiling every plugin - so I think they read the changelogs before they do this. When reading the changelog and decompiling the plugin I think it is obvious if "Critical Bug fix" is correct or not. If a user abuses the system, the checkboxes will be disabled for this project and all new files will have low importance.
How I handle critical updates (I am managing a plugin which has not so many users):
If I get a bug report, I try to fix it as soos as possible. When the fix is done, I push my changes to GitHub and create the binary .jar and upload it to BukkitDev. Then I send a PM to the bug reporter (and to anyone else who said he has problems with the bug) containing the direct link to the unapproved file.
I know this is probably not 100% agreeing with the BukkitDev rules but I think if you have a critical bug on your server you are happy about an update as soon as possible.
They may decompiling each plugin, but they only search for malicious code or code that is against the bukkit TOS and not if you fixed a bug, added some new features.
Everyone could abuse it and it would be too much work for them to check if it was really just a "critical bug fix" or not.
lfrst05 in the case of truly critical issues (not little bug fixes, but exploit patches and the like), you can contact (harass) us on the plugin dev IRC channel (#bukkitdev on esper). Generally someone's around who can forward the message up the chain (or I'm just stalking the channel as often happens). Other than fixes on the scale of exploit or data loss, I don't think there's anything that necessitates establishment of a priority. Another thing that can be done for extreme risk updates, would be reporting the file you've just submitted so we notice the report (if I see anybody do this for a non-priority update I will just delete the file out of spite love).
Just some ideas (i have no idea if its possible):
Make 2 queue's ("normal" and "emergency") an emergency update is a update to prevent dataloss and exploits.
Set som goal for the queue's (normal = max 24h, emergency = max 6h), then the plugins dev's have a "time plan".
Make the queue size public, so devs can see why its taking so long.
And last a "thank you" to the staff for the work you do for the community for free in your spare time!
Separate names with a comma.