Changes to our Git infrastructure

[Jan Kundrát]

On Saturday, 3 January 2015 03:31:26 CEST, Ben Cooksley wrote:
> Regrettably there were one or two items which conflicted. I sided with
> the option which kept the barrier to entry as low
> as possible as that seemed to be the greater consensus within the thread.

Hi Ben,
thanks for compiling a list. However, I was hoping that the result from 
this first phase would include every mentioned feature (perhaps on a wiki 
page?), so that we can then discuss how many people find each of these 
features valuable. I did not include some of the bits which others already 
expressed when I wrote my reply.

Things I miss from the list you just gathered:

- Working on git trees, not patches. This directly translates into making 
the contributors familiar with our workflow, and therefore getting them 
"immersed" into what we're doing and helping bridge the gap between 
maintainers and contributors.

- Being able to tweak small bits of the review request straight from the 
web application (in the nice-to-have category; this is different from 
"Developers can tweak proposed changes easily before they are landed 
without the involvement of the submitter.").

- Retaining proper autorship (git author) of the original author without 
extra work.

I think it's also reasonable to add:

- Not needing a CLI tool in an "obscure language" (PHP, Java, .NET,...).

- Not needing a CLI tool or an explicit authorization at all for operations 
such as "download patch".

> - Project Management:
>   - Coherent and Performant
>   - One canonical place to get the desired information (no more duplication)
>   - Can either be links to elsewhere or directly hosted by the system
>   - Covers items like documentation (wiki, api), bug tracking, task
> boards, CI, code browsing and reviews, etc.

I'm confused by this part. This thread is called "Changes to our Git 
infrastructure". I see that "code review" is very relevant to that because 
some efficient tools do extend Git, but I don't understand why this list 
contains information about wikis, bug tracking and task boards. I do not 
think that we should be looking for a single tool to do everything (and the 
kitchen sink), so I would appreciate a bit more information on what exactly 
your opinion is here, and why so.

>   - A weaker case exists for clone repositories - making them more
> nice to have than critical.

I believe that people requested a place to store their changes which for 
some reason cannot be easily upstreamed, but at the same time they do not 
want to "bother" other folks by having a visible branch "in your face" in 
the main repo. If that is indeed the case, we should focus on this 
*concept* and put away the fact that it's right now implemented as 
GitHub-style "repository clones". Other tools might very well support such 
a scenario by something entirely different from clone repos.

> - Integrated:
>   A single application which handles everything will always be able to
> offer a better and more coherent experience than several applications
> we have connected to each other.

I do not agree with that. Well-integrated applications which work well 
together while doing one thing well are superior to a single tool which 
tries to do everything.

>   There is also a lower maintenance burden from an integrated
> application, as it is one piece of software to update - not 3 or 4.

I am volunteering to get my hands dirty, and I believe others have 
expressed their willing to join the sysadmin team as well. In particular, 
I'll be happy to take care of the Gerrit deployment and help others perform 
day-to-day maintenance of Gerrit. This includes participating in the rest 
of the Git-hosting business, anongit, repo hooks, etc. I'm also interested 
in CI, which is another area in which I can help.

I've worked as a sysadmin for a couple of years and am pretty familiar with 
treating the physical infrastructure of servers and gear as code.

> - Scalable:
>   The applications which make up our infrastructure need to be able to
> handle the demands we place on them without consuming resources
> unnecessarily.

That's a good goal, but seems very vague to me. When we move to next 
phases, it is important to spell out what these demands are to prevent 
possible misunderstandings.

> As this is quite an extensive list of requirements, we won't be able
> to get everyone what they're after. We'll have to do things on a best
> effort basis - depending on what is available, what features are
> missing, etc. Unfortunately there is no perfect solution here - it
> just does not exist.

I can see all of the above fulfiled with Gerrit, but I'm OK with waiting 
with a proper evaluation when we call for one.

With kind regards,
Jan

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/