From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (NAM02-SN1-obe.outbound.protection.outlook.com [40.107.77.51]) by mx.groups.io with SMTP id smtpd.web11.11389.1587350464236934160 for ; Sun, 19 Apr 2020 19:41:04 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@vmware.com header.s=selector2 header.b=W2c24DLa; spf=pass (domain: vmware.com, ip: 40.107.77.51, mailfrom: awarkentin@vmware.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LggEZgC5zTr3+S5E7XMCVwqn5ivkLiIZazHar2C3iR2doJ6Ri9SzfUFkDcUTgrvPOFh311Fy+/F6zj68nnS4MvBMOCAi+InS4R19LIEMk0WPtIExjidKOmb1JIhXBbS+oMI8Z8IbIQTVGO2VTcvgPivGmND7tWjgWgVoy5cmhKLnJsDeGbKqlIk1HX/8LjcWoSfR5tPYCjdKlvVWLlIgfsRy6aabasdwWQeGPJtZ90GFyWl5DE4atzUKnA/KWt1FPHzuRlSMN/o2iwOjd278PPD2GlYT+sepVkLjScW5EFAy4Un3nrF0Mp9VdSGX3FEIjm4a4txIOQI48gRFKasRSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Qzrmu6ggZX2VVARkUHL3G0ztCXi0yZVUQeqyZTvNwqs=; b=oKRsYfKmSFWTDd+y9TluUUlnhavUIWx9XJaQUDLLsotYFMgCgBMdNpK8Diotx6HZSSLvP/ndpv6C5d4ocjtJKpjhwPKFDiL4ALnqVO2zLDoIkN3RERjPWEmqycZKQCl+yy0VaMVf4CWNmAEgBapUgGwzHASr8ZLDa9FMNmlJNX2dxSuk/ExXPm5tRwba2JLlrsN+UUGKH/NvndwDeVPi8vjs3gz7zRmusMwTscrwrpy9fJlMR9hiDKZ9t06Aeuog3zNgKg5Fh/Ox7HeGqHSjrdwt8ieIF1j/nnHmynOsBxnwMnmscngXm/zsRoB2FlyFKbqxnnExL8kdLxOl6mfueg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=vmware.com; dmarc=pass action=none header.from=vmware.com; dkim=pass header.d=vmware.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vmware.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Qzrmu6ggZX2VVARkUHL3G0ztCXi0yZVUQeqyZTvNwqs=; b=W2c24DLaHQug6AeHea6r2mHOwxayp0ERgOqbSNAeYQqFnqYQEyeqJS7WILkgfeU9gjiIYdHvuC7ttm09O6UIRpnQyzLbEH5YNU6yd44RR4g8M+R6pWppoP9cWNkZW7VClhhgt4QChfDRUyXjuEfRpIIC4yMneeM66dIyN6OTF5A= Received: from BN6PR05MB3411.namprd05.prod.outlook.com (2603:10b6:405:43::23) by BN6PR05MB3330.namprd05.prod.outlook.com (2603:10b6:405:41::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.11; Mon, 20 Apr 2020 02:41:01 +0000 Received: from BN6PR05MB3411.namprd05.prod.outlook.com ([fe80::5df3:40e3:521a:7f84]) by BN6PR05MB3411.namprd05.prod.outlook.com ([fe80::5df3:40e3:521a:7f84%5]) with mapi id 15.20.2921.027; Mon, 20 Apr 2020 02:41:01 +0000 From: "Andrei Warkentin" To: Andrew Fish , "devel@edk2.groups.io" CC: Pete Batard , Ard Biesheuvel , Samer El-Haj-Mahmoud , Leif Lindholm Subject: Re: [edk2-devel] [edk2-platform][PATCH v1 0/4] Platform/RaspberryPi : Enable TFTP shell command Thread-Topic: [edk2-devel] [edk2-platform][PATCH v1 0/4] Platform/RaspberryPi : Enable TFTP shell command Thread-Index: AQHWFksLVB8KW5eI1E6krRdTNHmDgaiAcbcAgAAM2gCAAFvq3oAABP0AgAAEA+qAAADzgIAAAwASgAA16E2AABUtgIAAB63y Date: Mon, 20 Apr 2020 02:41:01 +0000 Message-ID: References: <20200419130417.3298-1-samer@elhajmahmoud.com> <8d59e616-9910-4935-2e1f-5da75fc1d34a@arm.com> <831705c6-0915-ba1a-adc0-3078b2af1a43@akeo.ie> <28ac6ff0-86eb-fde7-63f6-c1c7dc0f0724@akeo.ie> <2046f801-45c2-f591-fdf8-18e2edb093d3@akeo.ie> <160753416257B0CA.29096@groups.io> , In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=awarkentin@vmware.com; x-originating-ip: [98.214.99.181] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ce0feb54-2c03-4f13-8c36-08d7e4d4439b x-ms-traffictypediagnostic: BN6PR05MB3330: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03793408BA x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN6PR05MB3411.namprd05.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:(4636009)(39860400002)(136003)(396003)(376002)(366004)(346002)(71200400001)(8936002)(2906002)(81156014)(8676002)(5660300002)(26005)(54906003)(110136005)(316002)(7696005)(53546011)(6506007)(55016002)(9686003)(478600001)(19627405001)(4326008)(86362001)(66556008)(966005)(66446008)(76116006)(186003)(33656002)(52536014)(83080400001)(66946007)(66476007)(64756008);DIR:OUT;SFP:1101; received-spf: None (protection.outlook.com: vmware.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: p1E9H7Hy3D46icw/3o4JZXNfwsF5+v145AhHmpwANngOsytJ77M7+b6iPyhB8sIFCvamkuA+ux/eG0d4O7cH4AwNZFnIl8zi0/495tf1HxiurBlBh872Ff5uZtvYoG5wsYSKkUkvMHKkFYudwDBlUvlip+/puCZ7cZaAYeJW+hHSXYuZey11eeHcAHxwpsGW8qtEgEgSAPscT8S5ii8QnmiI8jtIlxP5DYgoOqH/k2Jc6nvgrD+tJEexxMOv5RAWzBHT/mzbrhuTpADh2NhVYoJlD11o4PbCSRBdvBctDLw5APRYpw0qywRkQWBJ6Q7Q4oR17E+di6cqFuj7R9hgZSApg93UvFNLWDbHEqhahk/g3SL6mNQD24WlFW58Pa3ZDMMdtE6LFAI+uJqaTUsuQnMnhdLQpnC1EENFnYJmM8HKLYwr8VLWtaXDCvzVAAHFof3Z4QIu9bOLeHbRwoVau+yGzdtlx/D10HAze6RntalgRwZU+KdgDzxjl33kJDPUDKo4a/9SmPpZSZXiLR1TuA== x-ms-exchange-antispam-messagedata: rE/ijPvdHC6flEfdd8bFVrnzEO/Gvo0o2i9RBAbwCqPqcAqqOBdOE6ZidO5tpDKz2jNis4UacG+ywQiOPfKg4yeyhm+IqUA1rX9p5VhVNPnzM+kCFJClZNDGFiwur7loW2XnsPbwN2qqA+3QrFPjdQ== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-Network-Message-Id: ce0feb54-2c03-4f13-8c36-08d7e4d4439b X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2020 02:41:01.3392 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tnnRCU8o8ezZx5FppN8osoaScwb7ap+3xbQ6azNEL5k4q6Cx4EIxDBFuTLXgghrhj34MilUkii2cpUP11GX7UQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB3330 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_BN6PR05MB341154031D911F0125B1855BB9D40BN6PR05MB3411namp_" --_000_BN6PR05MB341154031D911F0125B1855BB9D40BN6PR05MB3411namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Andrew, This particular issue revolves around enabling a feature by default in the = DSC for Pi 3/4 platforms - the TFTP Shell command. Clearly, enabling this f= or Pi bears no effect on other Tiano platforms. So far I've heard something= about the TFTP code being somehow bad, but what does that have to do with = the Pi platform using it? If it's bad, delete it from Tiano. Or rewrite it. .../last/ time we got into a spat about the value of revving the Pi ACPI to= 6.3 (the ACPI support we contributed in the first place). So that patch ju= st got ignored. Not even sure what to do about that one... I don't know, the maintainers may in fact be in perfect agreement (I certai= nly do not know) - but certainly at odds with actual developers. So, there = appears to be a problem with the way edk2-platforms is run. Or at the very = least, I don't understand why it's run the way it's run. The RPi3/4 support is developed by a group of folks (https://rpi4-uefi.dev,= https://github.com/pftf). These folks (from Arm, from VMware, or unaffilia= ted) all follow their own goals, with some alignment, but there's overall c= onsensus that working upstream is A Good Thing and is worth the effort. We = loosely coordinate with each other (Discord, have a bug tracker, etc). How= ever, it seems that every patch we propose, to a code base that we largely = wrote and chose to upstream into edk2-platforms, gets put under the microsc= ope. That would be fair and square when we're talking about changes to shar= ed components, or code that for technical reasons (quality or design) does = not fit the implementation/design goals of Tiano. However, what ends up hap= pening is _maintainers_ taking arbitrary decisions, contrary to the communi= ty of developers behind the port. As a final say. I don't mean an abstract = mute community of developers. I mean the folks that specifically do all dev= elopment today for Tiano on Pi platforms. We have no control. We have no sa= y. Maintainers are certainly developers, and may have a stake and interest = in the code being reviewed, but at the end of the day they are maintainers = - they need to abstract away and agree to disagree on matters that are subj= ective and opinion-based. Why are maintainers making these calls? We brought these platforms into you= r garden because we were sold on the idea. Let us water them and take care = of them together. Instead, everything we do gets frisked with a strip searc= h. We have to spend our time constantly proving the value of our work inste= ad of using that very little valuable time we have to actually move the Pi = support forward. The outcomes are pretty serious. If you ask folks in the Arm community, the= y'll tell you "upstream first", and specifically cite lack of firmware bein= g upstreamed as being a serious problem. However, the way edk2-platforms is= structured, that goal is literally unobtainable because edk2-platforms dev= elopment doesn't scale, as all code gets funneled through the few maintaine= rs. I mean, why would anyone choose to upstream to edk2-platforms? For the = lack of positive reinforcement? For the tedious process with no light at th= e end of the tunnel? It turns developers away. It makes folks feel unvalued= and disenfranchised. You get to burn the midnight oil - pro bono - into so= mething only to have others tell you that you should have done something el= se or just get your proposals ignored. It's not really a community - our ch= oices, our code and our desire to CONTRIBUTE and BE RESPONSIBLE for a prope= r polished UEFI experience on the Raspberry Pi are worth absolutely nothing= here. Why does a maintainer have any say over platform-specific code, where there= is developer consensus on the trajectory and there are no over-arching tec= hnical concerns? Why can't individual platforms have their own maintainers? A From: Andrew Fish Sent: Sunday, April 19, 2020 8:03 PM To: devel@edk2.groups.io ; Andrei Warkentin Cc: Pete Batard ; Ard Biesheuvel ; Sa= mer El-Haj-Mahmoud ; Leif Lindholm Subject: Re: [edk2-devel] [edk2-platform][PATCH v1 0/4] Platform/RaspberryP= i : Enable TFTP shell command -100 since we don't use a points system :). The process is if the maintainers can not agree we let the Stewards decide.= The next Stewards meeting is May 5th, so in the mean time we can try to re= ach consensus as that is our preference for a process. Maybe it would be useful to summarize the issue and state the pro and cons? Thanks, Andrew Fish --_000_BN6PR05MB341154031D911F0125B1855BB9D40BN6PR05MB3411namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Andrew,

This particular issue revolves around enabling a feature by default in the = DSC for Pi 3/4 platforms - the TFTP Shell command. Clearly, enabling this f= or Pi bears no effect on other Tiano platforms. So far I've heard something= about the TFTP code being somehow bad, but what does that have to do with the Pi platform using it? If it's = bad, delete it from Tiano. Or rewrite it.

.../last/ time we got into a spat about the value of revving the Pi ACPI to= 6.3 (the ACPI support we contributed in the first place). So that patch ju= st got ignored. Not even sure what to do about that one...

I don't know, the maintainers may in = fact be in perfect agreement (I certainly do not know) - but certainly at o= dds with actual developers. So, there appears to be a problem with the way = edk2-platforms is run. Or at the very least, I don't understand why it's run the way it's run.

The RPi3/4 support is developed by a = group of folks (https://rpi4-uefi.dev, https://github.com/= pftf). These folks (from Arm, from VMware, or unaffiliated) all follow = their own goals, with some alignment, but there's overall consensus that wo= rking upstream is A Good Thing and is worth the effort. We loosely  coordinate with each other (Discord, ha= ve a bug tracker, etc). However, it seems that every patch we propose, to a= code base that we largely wrote and chose to upstream into edk2-platforms,= gets put under the microscope. That would be fair and square when we're talking about changes to shared compon= ents, or code that for technical reasons (quality or design) does not fit t= he implementation/design goals of Tiano. However, what ends up happening is= _maintainers_ taking arbitrary decisions, contrary to the community of developers behind the port. As a f= inal say. I don't mean an abstract mute community of developers. I mean the= folks that specifically do all development today for Tiano on Pi platforms= . We have no control. We have no say. Maintainers are certainly developers, and may have a stake and intere= st in the code being reviewed, but at the end of the day they are maintaine= rs - they need to abstract away and agree to disagree on matters that are s= ubjective and opinion-based.

Why are maintainers making these call= s? We brought these platforms into your garden because we were sold on the = idea. Let us water them and take care of them together. Instead, everything= we do gets frisked with a strip search. We have to spend our time constantly proving the value of our work instead= of using that very little valuable time we have to actually move the Pi su= pport forward.

The outcomes are pretty serious. If y= ou ask folks in the Arm community, they'll tell you "upstream first&qu= ot;, and specifically cite lack of firmware being upstreamed as being a ser= ious problem. However, the way edk2-platforms is structured, that goal is literally unobtainable because edk2-platforms = development doesn't scale, as all code gets funneled through the few mainta= iners. I mean, why would anyone choose to upstream to edk2-platforms? For the lack = of positive reinforcement? For the tedious process with no light at = the end of the tunnel? It turns developers away. It makes folks feel unvalu= ed and disenfranchised. You get to burn the midnight oil - pro bono - into something only to have others t= ell you that you should have done something else or just get your proposals= ignored. It's not really a community - our choices, our code and our desir= e to CONTRIBUTE and BE RESPONSIBLE for a proper polished UEFI experience on the Raspberry Pi are worth absolutely nothing here.

Why does a maintainer have any say ov= er platform-specific code, where there is developer consensus on the trajec= tory and there are no over-arching technical concerns? Why can't individual= platforms have their own maintainers?

A

From: Andrew Fish <afish= @apple.com>
Sent: Sunday, April 19, 2020 8:03 PM
To: devel@edk2.groups.io <devel@edk2.groups.io>; Andrei Warken= tin <awarkentin@vmware.com>
Cc: Pete Batard <pete@akeo.ie>; Ard Biesheuvel <ard.biesheu= vel@arm.com>; Samer El-Haj-Mahmoud <samer@elhajmahmoud.com>; Leif = Lindholm <leif@nuviainc.com>
Subject: Re: [edk2-devel] [edk2-platform][PATCH v1 0/4] Platform/Ras= pberryPi : Enable TFTP shell command
 
The process is if the maintainers can not agree we let the Stewards de= cide. The next Stewards meeting is May 5th, so in the mean time we can try = to reach consensus as that is our preference for a process. 

Maybe it would be useful to summarize the issue and state the pro and = cons?


Thanks,

Andrew Fish

--_000_BN6PR05MB341154031D911F0125B1855BB9D40BN6PR05MB3411namp_--