On Thu, Jan 22, 2015 at 3:54 AM, Milian Wolff <m...@milianw.de> wrote: > On Wednesday 21 January 2015 11:44:00 Jan Kundrát wrote: >> Hi Ben, >> thanks for your proposal. A couple of points which I'm missing from the >> text, and a few further questions as well: >> >> 1) A detailed list of the issues which a competing proposal would have to >> address. Some glimpse of this is in the last paragraph, but that's just a >> very high-level description. Could you please provide a list of >> functionality that has to be supported by a replacement, so that we can >> work out how to get there? > > Yes, a simple bullet point list would be useful. I'll list some stuff below > also. > >> 2) It is unclear to me whether you plan to use Gitolite in future or not. >> At first, the proposal says that there are inherent scaling issues with it >> and that the replication is beyond its scaling limits, yet at the end of >> the document you say that a replacement has to support Gitolite metadata >> generation. I do not understand that. > > Agreed. > >> 3) The idea of rolling out Phabricator is not specified, so it's hard to >> get a proper understanding of what exactly will have to be done. What >> changes in workflow are going to be needed? What custom tooling will have >> to be written? How is Phabricator going to play with the rest of the >> infrastructure? What pieces of the infrastructure will actually remain? > > <snip> > >> 5) You're indicating a requirement for scratch repos to be present from the >> very beginning, yet you acknowledge that Phabricator won't have it for at >> least six months. > > Agreed. > >> 6) The discussion focuses in highlighting Phabricator's benefits, which is >> understandable from your point of view. However, much of the same things >> can be said about Gerrit as well, especially its backing by a well-known >> player, adoption by multiple companies and multinational corporations >> (SonyErisccon, SAP, KitWare,...) as well as by many FLOSS projects (Qt, >> Andorid, LibreOffice, Eclipse, OpenStack, WikiMedia, Typo3, Cyanogenmod, >> Tizen, and a ton of others). Its scaleability has also been verified by >> real-world use over many years (for far longer than Phabricator). > > Imo, quite the contrary. It concentrates on the issues the admins have with > their current setup, and then shows how Phabricator could help with that. > >> Now coming to Gerrit and its analyzis: > > <snip> > >> 9) I do not know what effort for integration with KDE Indentity you're >> referring to. It's a simple LDAP server, and the entire "integration" was >> trivial. It's really just a matter of configuring Gerrit to talk to LDAP, >> which I expect to be also the case with Phabricator. > > I don't see where this is mentioned in regard to Gerrit. I can only find LDAP > being mentioned when talking about the status quo for KDE, which does not > include Gerrit. > >> 4) You have indicated some (pretty important to me) limitations of >> Phabricator with a remark that "it's a fast moving software, we might get >> there eventually". I think that SW should be evaluated based on >> functionality present right now in the development version and not based on >> opened feature requests. We've been promising e.g. support for multiple >> accounts in Trojita for many years already, and it didn't make it happen. > > This belongs to the point below, imo. Or what are you referring to? If you do > mean the git integration, then yes, maybe it's important to you, but it's > really not important in the big picture, imo. And do note, I'd personally also > prefer gerrit for reviewing. > >> 10) Re Phabricator's support for submitting and retrieving changes via pure >> git, I believe you're overly optimistic in this regard. This is a pretty >> fundamental design decision which can only be retroactively fitted with >> asignificant amount of pain. > > As far as I understand it, we (KDE) won't jump to Phabricator in a matter of > days, rather it will take a few more months before we even start (correct?). > There are still some other blockers upstream, which will be resolved. Lets see > how this works out. Generally, I don't think its impossible to add this to > Phabricator. So lets not be overly pessimistic, nor optimistic. Maybe this > feature is added, maybe not. While I personally would also love to have it, > it's a minor detail compared to the rest of the feature set, imo.
That is correct - we have to evaluate it first, and no migration would be rushed through in a matter of days. Things have to be planned for, prepared, tested and pre-flight migrations run before the final production migration is done. > > <snip> > >> 12) WikiMedia uses Phabricator for issue tracking and nothing else -- it's >> just a Bugzilla replacement for them. According to publicly available >> information, their reasons for choosing Phabricator had everything to do >> with the PHP as a language known to all of their developers. They still use >> Gerrit for git repo management and code review. > > See http://www.mediawiki.org/wiki/Phabricator, what Jan says is true. But > WikiMedia is in the process of migrating away from Gerrit, so what Ben says is > also kinda true ;-) > > Now to the following: > >> 7) It is possible to have scratch repositories with Gerrit, but it's true >> that it will require a simple tool which verifies user's request and >> executes an API call with proper credentials. We're speaking about one >> trivial webapp or a shell script here. >> >> 8) There is no need for any modifications to Gerrit as your text implies. >> What is running and integrated into KDE right now is an unpatched release >> straight from upstream, with no custom plugins. >> >> 11) While the Gerrit trial has been running for a few months, being used by >> real KDE projects and generated actual feedback and tweaks, there's been no >> trial of Phabricator so far. In my opinion, it is premature to have a plan >> for migration to a particular tool prior to having verified said tool in >> production environment. In this regard, your proposal effectively discusses >> throwing away the results we got with Gerrit, and fails to provide some >> rationale for that. Indeed, the question is "where is Phabricator better >> than Gerrit", and I propose to focus on this aspect in future. >> >> So given that we're about to rebuild the whole Git infrastructure anyway, >> the counter-proposal is to build it around Gerrit this time. Based on what >> I know about KDE's infrastructure, Gerrit can fill in these roles without >> any problem. I would like to work with you towards that goal; are you >> interested? > > To my knowledge, here are some things that Gerrit does not provide, but > Phabricator potentially provides: > > - a project overview with a code browser, project meta data etc. pp. and a > list of commits inside a repository. Qt still uses gitorious for this, afaik > - the ability to get notified about new commits in a project. (this is > different from new reviews) > - Apparently the anongit problem, but Ben would need to fill in more details > here. > > then, there are some other things that are really nice to have in Phabricator, > which are not available in Gerrit. But, imo, they are not as important as the > above: > > - post-commit review > - project management, todo / kanban board > - issue tracker (only if we ever port the bugzilla content over) > - paste (only if that would replace paste.kde.org) > - wiki (only if that could be used to replace the existing wiki structure) > - various tools which would help with release management, e.g. calendars / > countdown timers / release branches > - overall, the app framework phabricator provides seems to indicate that its > easy to extend, contrary to what I heard from gerrit > > Please correct me if I'm wrong. I only know Gerrit from its usage in Qt. > > Bye > > -- > Milian Wolff > m...@milianw.de > http://milianw.de Thanks, Ben
