Re: [edk2-announce] Community Meeting Minutes

[Laszlo Ersek <lersek@redhat.com>]

On 02/08/19 07:41, Rebecca Cran wrote:
> On Thursday, 7 February 2019 11:30:38 MST stephano wrote:
> 
>> My apologies if I was not clear in the minutes. We are not rejecting 
>> Github, but rather taking time to evaluate how we can supplement 
>> Github's features to emulate our current patch review requirements. We 
>> do not want to rush into change and risk losing data or causing 
>> frustration for those developers currently contributing on a regular basis.
>>
>> I am currently working off this list of issues that Laszlo brought up:
>>
>> https://lists.01.org/pipermail/edk2-devel/2018-December/033509.html
>>
>> To be clear, Laszlo is not the only package maintainer that has voiced 
>> these concerns. The longevity of pull request branches and the fact that 
>> email notifications lack context are top on my list. There are several 
>> ways to overcome these obstacles, and finding the best solution will 
>> ensure that if we transition to Github, that transition is successful.
>>
>> The ability to allow developers to work offline (or with intermittent 
>> connections) is an important aspect as well. We cannot practice 
>> exclusionary or ostracizing behaviors if we expect to grow and maintain 
>> a community. I cannot imagine that Github has become as popular as it is 
>> if it cannot facilitate ease of offline use.
> 
> I wonder if Phabricator could be considered again, since I believe it supports 
> all the features mentioned: the only thing it doesn't support as a first-class 
> feature is mutli-patch reviews, which need to be done by linking separate 
> reviews together using the dependency feature. I wonder if it could either be 
> enhanced to support that, or people's workflow modified?

I don't see the workflow modification as viable. The "patch series"
concept is integral to every single open source project that I've ever
worked with. The evolution of a feature or a bug fix over a series of
patches is a core facet of programming and reviewing. It communicates a
thinking process, and that's what programming is about.

Enhancing Phabricator is of course an option, but I'm not sure how
practical that is. Then we start talking time frames and it becomes sort
of a competition. If GitLab added features of fixed the grave issues we
had found with it, we'd have to re-evaluate GitLab too. Or else, if we
had a completely leisurely time frame at our disposal, I would 100% vote
<sr.ht> -- see the introduction at <https://lwn.net/Articles/775963/>.
<sr.ht> gets right *everything* right from the design principles; too
bad it's only Alpha at this point. So how long do we wait?

What I find practical at this moment is what Stephano has been working
on (thank you for all that Stephano) -- collect & file official
improvement requests with GitHub, and then see how those things are
addressed. In my opinion (not having seen Gerrit anyway, which remains
to be evaluated, but not by me), GitHub is the direct runner up to the
mailing list, so improving GitHub would be the most practical. In
particular I envision the context improvements for the GitHub email
notifications as something very doable for GitHub.

Thanks,
Laszlo