public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Andrew Fish <afish@apple.com>
To: Tim Lewis <tim.lewis@insyde.com>
Cc: Laszlo Ersek <lersek@redhat.com>,
	"Bjorge, Erik C" <erik.c.bjorge@intel.com>,
	edk2-devel@lists.01.org
Subject: Re: RFC: Proposal to halt automatic builds of Windows BaseTools executables
Date: Thu, 08 Mar 2018 14:19:45 -0800	[thread overview]
Message-ID: <BEADBAAF-025E-4EE2-ABB2-392F7A5F34A4@apple.com> (raw)
In-Reply-To: <017401d3b725$92422e00$b6c68a00$@insyde.com>

Tim,

It is not just an open source thing. In our world we can't build on the production servers with arbitrary binaries in the tree. We have to file paper work to get an exemption, and given we can build the tools in our source base the answer would always be don't check in the binary.

I would assume that a given EFI team at company X could always build and check-in tools binaries as part of their source control repo. But it would be good if that was easy and documented.

I'd also point out worse case this is all open source so another project could always provide tools snapshots....

Thanks,

Andrew Fish

> On Mar 8, 2018, at 1:36 PM, Tim Lewis <tim.lewis@insyde.com> wrote:
> 
> Laszlo, Erik --
> 
> I understand this dislike from some open source developers. I respect that and am glad that EDK2 provides a way to accommodate this preference. But "most" is a strong term. I would venture to say that a good number (and probably the majority) of the people using EDK2-derived code and tools are fine with the current situation.
> 
> The only reason I would have Python on most of my company's dev systems would be for EDK2. Since (a) the current system is working and (b) since the possibility for rebuild is available for those who want it, it doesn't weigh heavily enough IMO to change the current situation. 
> 
> Regards,
> 
> Tim
> 
> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com> 
> Sent: Thursday, March 8, 2018 1:19 PM
> To: Tim Lewis <tim.lewis@insyde.com>; 'Bjorge, Erik C' <erik.c.bjorge@intel.com>; edk2-devel@lists.01.org
> Subject: Re: [edk2] RFC: Proposal to halt automatic builds of Windows BaseTools executables
> 
> On 03/08/18 19:05, Tim Lewis wrote:
>> Erik --
>> 
>> What is the justification? Moving from more immediately usable to less 
>> immediately usable doesn't seem, on the surface, to be  a good direction.
>> Why not go the other direction and pre-build the binaries for the 
>> other environments?
> 
> I'd just like to offer one data point for the last question: most open source developers *really* dislike running any native binaries that were built by neither (a) themselves nor (b) the provider of their OS distribution.
> 
> To give you an example for (b), Fedora provides the "edk2-tools" package (built from the "edk2" source package), and "edk2-tools" definitely installs native binaries:
> 
> https://koji.fedoraproject.org/koji/rpminfo?rpmID=13354362
> 
> The difference is that these binaries were built in a build environment that matches the rest of Fedora [*] and is generally trusted by Fedora users.
> 
> [*] For example, binaries could be instrumented for security purposes system-wide; some buffer overflows in a native (C) application could be caught automatically as a result.
> 
> Thanks,
> Laszlo
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel



      reply	other threads:[~2018-03-08 22:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-07 17:56 RFC: Proposal to halt automatic builds of Windows BaseTools executables Bjorge, Erik C
2018-03-08  1:21 ` Gao, Liming
2018-03-08 18:05 ` Tim Lewis
2018-03-08 18:37   ` Andrew Fish
2018-03-08 19:52     ` Bjorge, Erik C
2018-03-08 21:18   ` Laszlo Ersek
2018-03-08 21:36     ` Tim Lewis
2018-03-08 22:19       ` Andrew Fish [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BEADBAAF-025E-4EE2-ABB2-392F7A5F34A4@apple.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox