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/
