From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id DF7EC20352A89 for ; Fri, 1 Dec 2017 03:56:42 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D1E381F56B; Fri, 1 Dec 2017 12:01:08 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-33.rdu2.redhat.com [10.10.120.33]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4B55E614E6; Fri, 1 Dec 2017 12:01:07 +0000 (UTC) To: "Ni, Ruiyu" , "Gao, Liming" , Felix Poludov , "afish@apple.com" Cc: "edk2-devel@lists.01.org" References: <9333E191E0D52B4999CE63A99BA663A00302B63C30@atlms1.us.megatrends.com> <9333E191E0D52B4999CE63A99BA663A00302B64F9B@atlms1.us.megatrends.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E188BBE@SHSMSX104.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5BAD9592@SHSMSX104.ccr.corp.intel.com> From: Laszlo Ersek Message-ID: <6a47d052-450d-09de-9cc3-acaa8aada3ab@redhat.com> Date: Fri, 1 Dec 2017 13:01:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5BAD9592@SHSMSX104.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 01 Dec 2017 12:01:08 +0000 (UTC) Subject: Re: edk2 interface deprecation policy X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 11:56:43 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 12/01/17 03:27, Ni, Ruiyu wrote: > I prefer to remove all deprecated items because I like clean:) > But then lots of customer complains may come. > > So just provide my thoughts: > Deprecated items can be separated into: > > 1. Definitions: E.g.: UgaDraw protocol, DriverConfiguration2 protocol > Keep: > But harm the newbie developers because they don't know which interfaces should depend on. > Remove: > A pure world. > But easy to cause build break. Yet easy to fix by downloading the definitions from old revision. > Proposal: > Move all deprecated definitions to a DeprecatePkg/OldPkg. > > 2. Modules. E.g.: IntelFrameworkModulePkg/Universal/BdsDxe, IntelFrameworkModulePkg/Bus/Isa/* > Keep: > Increase feature owner's maintain effort. > Cause confusing because new features won't be enabled in deprecated modules. > Remove: > A pure world. > But easy to cause build break. Yet easy to fix by downloading the definitions from old revision. > Proposal: > Keep it if in IntelFramework[Module]Pkg because in future the two pkgs will be deprecated. > Move it to DeprecatePkg/OldPkg if in Mde[Module]Pkg > > 3. Libraries: E.g.: IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode > Same as #2. > > So how about we create another GIT repo and store the DeprecatePkg/OldPkg. > Old consumers can download old stuffs from the other GIT repo. > Eventually the IntelFramework[Module]Pkg can be moved to that repo as well. I really like the DeprecatedPkg idea, but I think the package should live in the *same* edk2 repository. Similarly to EdkCompatibilityPkg. The benefit is that deprecation can occur gradually, and it all will be part of one common git history. (I don't feel strongly about this topic, I just thought I'd comment on the "separate git repo" part -- I think there's value in keeping DeprecatedPkg in edk2.) Thanks Laszlo >> -----Original Message----- >> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Gao, >> Liming >> Sent: Friday, December 1, 2017 9:51 AM >> To: Felix Poludov ; afish@apple.com >> Cc: edk2-devel@lists.01.org >> Subject: Re: [edk2] edk2 interface deprecation policy >> >> Felix: >> I agree to define the tag to specify the deprecated definition, library and drivers. >> If so, user can easily know which one is not used any more. But, I think we can >> still keep them in edk2 project, because they have no negative impact. >> >> Thanks >> Liming >>> -----Original Message----- >>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of >>> Felix Poludov >>> Sent: Friday, December 01, 2017 6:12 AM >>> To: afish@apple.com >>> Cc: edk2-devel@lists.01.org >>> Subject: Re: [edk2] edk2 interface deprecation policy >>> >>> I agree. It would be beneficial to have a mailing list discussion on >>> how to deal with the deprecated item. >>> In some cases it would make sense to tag an interface as deprecated, >>> but keep in the code base for a while (6 month?) before actually deleting it. >>> >>> -----Original Message----- >>> From: afish@apple.com [mailto:afish@apple.com] >>> Sent: Thursday, November 30, 2017 11:57 AM >>> To: Felix Poludov >>> Cc: edk2-devel@lists.01.org >>> Subject: Re: [edk2] edk2 interface deprecation policy >>> >>> Felix, >>> >>> I don't think we have one.... >>> >>> Adding new interfaces does not impact the downstream projects, but >>> depreciating interface can break stuff. Seems like it might at least be >>> a good idea to have a depreciation discussion on the mailing list. I'm >>> open to other suggestions.... >>> >>> Thanks, >>> >>> Andrew Fish >>> >>>> On Nov 30, 2017, at 6:00 AM, Felix Poludov wrote: >>>> >>>> Does edk2 have a policy regarding deprecation of interface definition >>> headers? >>>> I can see that definition of the UgaDraw protocol that was deprecated >>>> years >>> ago (I believe in UEFI 2.0) is still part of the code base; yet, >>> definition of the SMM Communication ACPI Table that was deprecated this >>> year in UEFI 2.6B has already been removed. >>>> >>>> Please consider the environment before printing this email. >>>> >>>> The information contained in this message may be confidential and >>> proprietary to American Megatrends, Inc. This communication is >>> intended to be read only by the individual or entity to whom it is >>> addressed or by their designee. If the reader of this message is not >>> the intended recipient, you are on notice that any distribution of this >>> message, in any form, is strictly prohibited. Please promptly notify >>> the sender by reply e-mail or by telephone at 770-246-8600, and then delete or >> destroy all copies of the transmission. >>>> _______________________________________________ >>>> edk2-devel mailing list >>>> edk2-devel@lists.01.org >>>> https://lists.01.org/mailman/listinfo/edk2-devel >>> >>> >>> Please consider the environment before printing this email. >>> >>> The information contained in this message may be confidential and >>> proprietary to American Megatrends, Inc. This communication is >>> intended to be read only by the individual or entity to whom it is >>> addressed or by their designee. If the reader of this message is not >>> the intended recipient, you are on notice that any distribution of this >>> message, in any form, is strictly prohibited. Please promptly notify >>> the sender by reply e-mail or by telephone at 770-246-8600, and then delete or >> destroy all copies of the transmission. >>> _______________________________________________ >>> edk2-devel mailing list >>> edk2-devel@lists.01.org >>> https://lists.01.org/mailman/listinfo/edk2-devel >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel >