On 01/31/2015 10:37 AM, Jan Kundrát wrote:
About the "we could" vs. "we will" in general, I have to admit I'm slightly confused by that. The proposal is careful to describe what is available today, and to make a clear difference in saying what needs to be done in future. Maybe some part needs clarification -- what parts do you think are more of the yes-this-would-be-nice-but-I'm-worried nature?
I just wanted to make the point (but I agree I made it a bit poorly) that it's worth differentiating between features the proposed solutions are guaranteed to deliver right away, and features they may enable in the future, but only if certain other conditions are met, e.g. raw infrastructure expansion. That's not a knock against your proposal, though - it's much easier to e.g. ask for hardware donations when you can point to a clearly identifyable need. --- snip --- I'd like to summarize my current feelings on both proposals. Here's what I think gerrit's strong points are: * There's undeniably synergy and cultural alignment with middleware communities we depend on to be had. Qt is using gerrit and we intend to remain a major stakeholder in Qt development, which means a sizable number of KDE developers need to be familiar with gerrit anyway. KDE using gerrit lowers the barrier for KDE developers to work upstream, and for folks in the wider Qt community to involve themselves in KDE. Particularly for Frame- works development this could be a boon. * gerrit and the community around gerrit (which includes Jan) appears to have considerable chops when it comes to solving hard infrastructure problems like advanced CI and replication. This is stuff that can enhance the quality of our products by improving our processes, but it also stands to make KDE a more attractive envi- ronment for incubating new projects. Infrastructure should not be the sole platform we run recruitment on, but staying competitive is important, and one way to do that is to try and lift things only a community of KDE's size can lift -- and that can e.g. include gathering donations for fancy CI cluster setups. Here's what I think Phabricator's strong point is: * From what I've seen and played with so far, I really like the UI. This is a short bullet, but an important one. * In terms of cultural alignment, I see communities like Blender and Wikimedia pick Phabricator. Lowering the barrier for cross-pollination with communities like this seems very attractive to me, because there's types of talent engaged in those communities that we need more of in KDE, e.g. designers and artists. * I expect the above drivers to make it more likely that Phabricator will develop functionality that will make it more useful for these types of contributors. For example, good diff viewers for visual assets, good handling of screenshot attachments to change proposals, etc. I feel like it is less likely that gerrit will become similarly useful for non-code assets. * The conflation of change review and issue tracking in Phabricator makes sense in the above context as well, and could greatly improve our non-programming develop- ment processes. In short, I don't see gerrit benefit our non-code contributors at all, but I see a shot at Phabricator doing so. Given all of this, I find it really hard to have a firm opinion at this point. Both proposals promise strong benefits to different aspects of what the community is doing, which makes this an exercise in weighing those aspects and predicting future outcomes based on different ratios between them. That said, at this point, I have more experience work- ing with gerrit than with Phabricator, and I think that's something that needs to be addressed as part of this process. I think we should proceed with setting up a test instance and giving it a spin, this should help with getting things into clearer focus. Cheers, Eike
