On 7 March 2012 02:13, Chad <innocentkil...@gmail.com> wrote: > On Tue, Mar 6, 2012 at 6:42 PM, K. Peachey <p858sn...@gmail.com> wrote: >> On Wed, Mar 7, 2012 at 5:20 AM, Diederik van Liere <dvanli...@gmail.com> >> wrote: >>> My concern is not about the UI of Gerrit, I know it's popular within >>> WMF to say that it's UI sucks but I don't think that's the case and >>> even if it was an issue it's only minor. >> >> We are changing from a CR system where everything (or atleast almost >> everything) was displayed on a single (and non confusing) page to a >> system that to plainly put it, is a clusterfuck of confusing (And i'm >> known for choosing the more time consuming/evil/painful methods of >> doing things), >> > > I'll be the first to admit that Gerrit may not be the single most intuitive > piece of software. But to call it a clusterfuck is doing it a disservice. > The learning curve is steeper than our home-grown CodeReview tool, > but I honestly don't think it's insurmountable.
TL;DR: I've said to many people that I have concerns about this move, so I'm trying to explain what concerns me and asking what are the benefits for me. Usually when something is replaced with more complicated solution, there are some needs it addressed or new benefits it brings. But honestly, I'm quite happy with the current tools with all their shortcomings. We actually get stuff done, even if breaking lots of things while doing that and only noticing so late that the only option is to fix it as well as possible. So what are the benefits of Git+Gerrit+Gated trunk? I can think many tasks it makes harder (for me), but I can hardly think any benefits (for me). The ops/lead engineers might be happy when they get a stable master. But if that is because development slows down due to increased hurdles getting stuff into the master, is it really a benefit at all? The "wait until you can't revert" model above is certainly not going to work with gated trunk, and I doubt that anybody suddenly starts reviewing those big refactorings or commits to the areas of codebase nobody really knows when we switch over. Our code base is very old and complex to the extend that many areas of it are not understood but only few developers, if anyone. Yet those few developers do not have the time to review patches or improve those areas of the code to the extend that other developers would be able to learn them and work on them. We need to keep modernizing our core code, making it less complex and designing good interfaces. I think the current state of core is already limiting innovation in extensions. Rather than solving our review problem, I think GiGeGa might even make it worse by slowing the type development work mentioned above. So once again, what are the benefits for me? The advantages listed at http://www.mediawiki.org/wiki/Git/Conversion#Rationale don't apply to me: * I rarely work off-line * I spend about 30 minutes a week merging code (this is supposed to be easier) * I spend around 10 hours a week reviewing code (this is going to be much more difficult) * I do many commits per day (not easier, don't know yet how much more difficult) From this I gather the people who benefit most are people who just want to do some small fix, fire it and forget it and people who spend lots of time merging or traveling. One benefit I would like to see is that WMF would feel the pain needed to get the code of its various projects reviewed. It has many projects with single or few developers but nobody is assigned to do the code review on them from the very beginning. I'm afraid it will just find some way around requirement. -Niklas -- Niklas Laxström _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
