Pull requests remain open for too long
#1
I think that Pull Requests are currently not processed fast enough, often sitting in queue for too long and eventually becoming in conflict with master. PR spoilage is a problem. I perfectly undrstand that Cuberite is a do-ocracy and that there are times when no one has time to review the PRs. Is there something we can do about this?

I'm just opening this for discussion, mentioning the problem but not a particular solution.
Reply
Thanks given by:
#2
A do-ocracy?Tongue

Is this a problem which needs fixing? Eventually someone will get around to them; if not the author, one of the maintainers.
Reply
Thanks given by:
#3
I agree with LogicParrot, I'm not involved in Cuberite development but I can see PRs fogotten there for more than 10 days or even more and indeed became outdated with master branch , so even if an issue is fixed, sometimes takes almost a month to be merged.
Reply
Thanks given by:
#4
I agree. The process of contributing in general was not enjoyable at all.
Reply
Thanks given by:
#5
Then just stop contributing. We have policies that have to be stuck to to maintain usable code. We also do this as a hobby so we aren't getting payed for doing maintenance on unmaintainable code. So just knock it off!
Reply
Thanks given by:
#6
Well that's a little rude @sphinxc0re.

I do agree that contributing can be a little confusing, especially for people who just started programming or working with Git, but all these things are there for a reason. They're there to keep the quallity of the code as high as possible and prevent new code that can cause more harm than good.
Reply
Thanks given by:
#7
Sorry @NiLSPACE I've been a little enraged since people decided to complain about our PR strategies over and over.
Reply
Thanks given by:
#8
(03-03-2016, 02:10 AM)SphinxC0re Wrote: Then just stop contributing. We have policies that have to be stuck to to maintain usable code. We also do this as a hobby so we aren't getting payed for doing maintenance on unmaintainable code. So just knock it off!

Really? I don't think you'll have to worry about contributors for long with that kind of attitude.

Edit: Got ninjad by SphinxC0re's reply, although the point is still valid. The contributors are doing this in their free time as well and criticism should be carefully evaluated and not met with a snarky response.
Reply
Thanks given by:
#9
I don't think I'm the one you're supposed to apologize to Wink

@warmist what was bugging you while contributing? That is something we'll have to work on. We're all working on Cuberite, so naturally we have to get along Smile
Reply
Thanks given by:
#10
(03-03-2016, 04:50 AM)NiLSPACE Wrote: @warmist what was bugging you while contributing? That is something we'll have to work on. We're all working on Cuberite, so naturally we have to get along Smile

I'm not saying it was awful. Just the general no-reaction whatsoever interspaced with one comment about one line. You do a rebase (because it's out of date yet again) then another line is not to standard for someone. It could just be me and my lack of concentration/effort but imho it should be more lax. Yes it would have more bugs be less maitainable but we are not building corporate software for the overlords - i get enough of that from my day job and having to adhere to yet another set of arbitrary rules (5 spaces between functions?! really? so that you could never see two functions and never understand any links between?) just saps my willpower to contribute at least at C++ side and seems like every comment is like somebody trying to find some fault so it would not get added in. </rant>

As for "if you don't like it don't contribute" - I understand that might sound very harsh and unfriendly, but what i'm saying is just because i believe that this could be better and Cuberite itself has HUGE potential. I mean you guys have done so much already and I'm very grateful and i'm really hoping this gets picked up by many more contributors (unless my estimates are off and there are no C++ programmers left in this minecraft+(c++)+has_time set).

So my solution (at least for now) is code for myself, in my own fork without any pull-req and style guides, and if anyone (including me) thinks that any of my code has merit i (or anyone else is welcome) could tidy the code up for the main fork. I will still create issues where i find bugs in main code and try to be active in forums and hopefully that is enough.
Reply
Thanks given by:




Users browsing this thread: 12 Guest(s)