From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:4864:20::42d; helo=mail-wr1-x42d.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 821D62116823F for ; Fri, 12 Oct 2018 06:27:23 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id g15-v6so13440766wru.9 for ; Fri, 12 Oct 2018 06:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=KHEDPhXCgTXSvyk65PJU3kzaXix0drYy6yAIxMJ3jRY=; b=XFD3V1/2OhCaFT5lGY7axYElbBxcr/bVaYOyOOiy3DHkBPQeXnuN/Cua99cIG8CLCv Y1PBhDuNpWIXOgdUXx2V0gcC7Cro45LKGkcyrH1JJVELH0Df2YUx1r7gG7ZNIMqyaJQO xHwgMlPhVnvnhcj1SzXPWHycyVpsPWoPt5UPE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=KHEDPhXCgTXSvyk65PJU3kzaXix0drYy6yAIxMJ3jRY=; b=eAAKE6YzMeP/879wcxeo7EWpH040aGZeViDxmDgdDkMeJiYfOq9hSGQO9Vmyk3eB8J 0zABiyMn4E3Sxv9OCZOuh/BYybh4m1OaGQbajLHNwU3riSzAlcoXVSjxXxizHxQWsWJ4 QhpdnAl63cJJfEdl00i4TPUxPdr278eF3XbfJYSJlI+Wk5JGa4yd4hYFiMZzL6v9Mmcn yFkaqqYTSnpGMHWNwTDaORf72J0r3oftYyXynZwi9I5qtlH/I4DbG/vTOebRN7b11STq vLxfchqr0+ybqTMzDZeqAnkzsPeYOk6gXQjLVitpxnPJEViZjlljvDw2MbMzZp3y4kg7 xrFg== X-Gm-Message-State: ABuFfojcqEuEnWSQ3P9ibBg2jzAoVSa1zeJVSNoxYonkRIyLif/Y9hN+ pT8m9x3J34inpIqKDl9xW/maWA== X-Google-Smtp-Source: ACcGV63PiHcWrvPePyKMYJ04wW27oLIlUg/NklInloLU/xncV7YqdsDBiy6rzqE1GhdqIa9AMTVddw== X-Received: by 2002:a5d:4cc3:: with SMTP id c3-v6mr5545232wrt.75.1539350841539; Fri, 12 Oct 2018 06:27:21 -0700 (PDT) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id l4-v6sm1355865wrb.92.2018.10.12.06.27.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 12 Oct 2018 06:27:20 -0700 (PDT) Date: Fri, 12 Oct 2018 14:27:19 +0100 From: Leif Lindholm To: stephano Cc: edk2-devel@lists.01.org Message-ID: <20181012132718.mgpg3f42hjulcwfk@bivouac.eciton.net> References: MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: TianoCore Community Meeting Minutes X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 13:27:24 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Stephano, Thanks for pulling this together. Some comments below. On Thu, Oct 11, 2018 at 10:43:57AM -0700, stephano wrote: > Thank you all for a great set of meetings! > > This is an overview of the topics discussed and the tasks that were > assigned. Please feel free to send me any questions or comments. > > Licensing > --------- > Licensing was discussed and no questions or comments came up. Please feel > free to contact me directly if you would like more info. > > Community Meetings > ------------------ > Community meetings will be held regularly. We will plan public bug scrubs > and design meetings. Meeting formats will use zoom and be held 2 times per > day to accommodate all time zones. So I didn't comment on the call (which I dialled in to, using a phone, because that was the only thing that wasn't going to delay me 10 minutes), but I would prefer a conferencing system that does not require binary downloads to participate in. I know at least one organisation that would be prevented from using it until they had explicit approval (which could take a while), and it puts me in the position of having to keep a spare x86 machine on my desktop in order to participate. Solutions I know would work in this scenario (i.e. work without plugins or downloads in any modern browser) are: - google hangouts (requires accounts, not ideal for China) - Skype (not SFB though, only plain old Skype) - Bluejeans (requires organiser account) Sure, I could attend via the Android app for zoom, but it would make it tedious to paste links to/from chat and put me on a tiny screen. > Invites will be posted to the mailing > list and the wiki. Since the mailing list does not allow attachments, I will > work on getting an "add to calendar" link attached to the wiki page. > > I will send out a poll to see if the community would be interested in a > Slack channel. I'm happy to admin it if there is interest. > > I will also be setting up a specific meeting, probably next month, to > discuss general code and commit message standards. > > > Patch Workflow Improvement > -------------------------- > We would like to find a more modern, user friendly patch workflow that fits > (as best as it can) most company's workflow. > It is recommended that the > community familiarize themselves with some of the options that are out there > so that we can pose useful questions / comments at the next meeting. Please > be sure to research up-to-date information and not rely on old info. Options > and tools discussed included: > -Github > -Gitlab > -Phabricator > -Gerrit > > The was a concern raised over potential lock-in to Github's, specifically in > regards to history retention. > Several Github users brought up that this shouldn't be an issue. Hopefully they said more than that. What does "shouldn't be an issue" mean. Were these users from multiple organisations? > Shawn mentioned some benefits to stock Github such as > it is always up to date, it includes APIs to extract data, pull > requests Since we are discussing multiple different development systems, can we try to be a bit more explicit? This is referring to github's web-based branch-based ticketing system, yes? I know language drift and all, but https://www.kernel.org/doc/html/latest/maintainer/pull-requests.html is what pull request means to at least 3 participants in this conversation. > lend themselves to simple(r) automation, and it has a much more modern web > UI than Gerrit. It seems somewhat less than ideal to me that all of the github proponents were on the opposite call to me and Laszlo (and Ard). Were any of them Asia-based or could we try to get them on the call with Europe next time? I'm sure me and Laszlo could be somewhat more accommodating than your 7AM, but we're not going to stay up for a 3/4AM meeting about source control. > Several community members including Marcin and Rebecca have used Phabricator > and can recommend it. Intel has used Gerrit internally and can recommend its > use. I don't think we had anyone from ARM on either of the calls, but I know they use gerrit internally. For those who weren't on the call I was on, I am _not_ a fan of gerrit - but if the deciding factor (as suggested above) is to best align with the internal processes of contributing organisations, then gerrit wins hands down. > No one voiced any issues with Bugzilla and several from the community > thought that we should continue to use it. > > Improvements to the Build Process > -------------------------------- > We would like to gather a list of concrete specific proposals. Nate > mentioned that there will always be some specialized tooling because of the > nature of BIOS. Shawn mentioned that we need to keep in mind that making > development easier for current developers should be a priority over making > the processes easier for newcomers. I will send out emails asking for > specific feedback on some of these topics: > > -Which toolchains are being used, which are validated, and which are known > to create reproducible builds. > -When toolchains are known to be orphaned, should they be archived or simply > removed. > -Could we add some kconfig-like tool that allows introspection into what > type of builds are available. Well, in our call this was more about the ability to enable larger groups of functionality without having to explicitly list every single module included. > -How can we better track the code quality of BaseTools and the current build > system on the whole. Should we add a "requires documentation change" flag to > BZ so that it will be easier to compile a list of required doc changes. Could we also have a thread on someting that you sort of mention in the text, but not the bullet points?: - Suggestions for improvements to BaseTools. > Changing to LF instead of CRLF > ------------------------------ > It was agreed that this is a good idea but that we should create a test repo > to verify this change before implementing it. It was noted that this will > cause some overhead with tasks like git blame, however the benefits outweigh > the costs. > > Switching to Standard C Types > ----------------------------- > Both Shawn and Nate mentioned that the current system has been in place for > a long time and some people prefer the current setup. I can start an email > discussion around this issue specifically if anyone feels strongly that we > should be using standard types. So, I don't think we made it this far down the agenda on the US-EU call. One way would be to simply explicitly permit it, possibly with the constraint that every module needs to pick one and stick with it, unless people object. I think we'll want to discuss this in a US-EU call as well. > Using Git Submodules (like we do with OpenSSL) > -------------------- We didn't make it here either. What would we use it _for_? I think the openssl case makes a lot of sense, but what else? > Many in the group liked this idea. I will engage with the communities to > gauge their interest in taking patches or helping with our integration of > their software. I think we do need to discuss it on the US-EU call as well before we do anything else. > Public CI > --------- > This subject was not discussed at length but there seems to be quite a bit > of community interest. We will discuss this more in the next meeting. Please > familiarize yourself with some possible solutions, with a focus on > supporting Windows + Linux + Mac. Some possible solutions include: > > https://azure.microsoft.com/en-us/blog/introducing-azure-devops/ > https://cirrus-ci.org/ > > Mike has tried out Cirrus with some success. Some positive points to Cirrus > include: > -Build time of ~ 7 Minutes (clone edk2, apt-get all dependent tools, build > BaseTools, and build 3 versions of OVMF) > -Caching of VM contents so reduce build times of subsequent builds > -We could use platforms like OVMF to boot FW and provide test results from > tools like MicroPythonTestFramework > -Cirrus includes integration with docker I wouldn't have anything to add on this topic in a US-EU call, but thanks for the links. Regards, Leif