From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 22C7DA0A02; Tue, 18 May 2021 15:13:46 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0CA5C40692; Tue, 18 May 2021 15:13:46 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by mails.dpdk.org (Postfix) with ESMTP id 4131D40041 for ; Tue, 18 May 2021 15:13:44 +0200 (CEST) IronPort-SDR: 9H5Md8DxgvspR1uDsIZzGCLZjtcYza99fzV5fjz1YU6tgP7WkCQoMicbk2DJtBeZisSJfQL+TV IpkPm7CuMJAg== X-IronPort-AV: E=McAfee;i="6200,9189,9987"; a="286239998" X-IronPort-AV: E=Sophos;i="5.82,310,1613462400"; d="scan'208";a="286239998" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 May 2021 06:13:43 -0700 IronPort-SDR: BMKg5lodwI6N/X+0w13LDIdxafNM/1WRSKLuyGWQJM4PyzZ1IBJuKajHXOcrnBou2GbL8Cmmkp 9PfHvBdIWt3Q== X-IronPort-AV: E=Sophos;i="5.82,310,1613462400"; d="scan'208";a="439431570" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.224.73]) ([10.213.224.73]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 May 2021 06:13:41 -0700 To: Thomas Monjalon Cc: dev@dpdk.org, david.marchand@redhat.com, Asaf Penso , John McNamara References: <1610304247-11455-1-git-send-email-asafp@nvidia.com> <20210328190005.4185594-1-thomas@monjalon.net> <45ecbd36-089c-a8a6-740f-3660310dee9d@intel.com> <5731405.XtSjWBXQUY@thomas> From: Ferruh Yigit X-User: ferruhy Message-ID: <5fa24714-796e-c312-08df-d516e4f6e68e@intel.com> Date: Tue, 18 May 2021 14:13:38 +0100 MIME-Version: 1.0 In-Reply-To: <5731405.XtSjWBXQUY@thomas> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v6] doc: add release milestones definition X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 5/18/2021 1:25 PM, Thomas Monjalon wrote: > 18/05/2021 13:57, Ferruh Yigit: >> On 3/28/2021 8:00 PM, Thomas Monjalon wrote: >>> From: Asaf Penso >>> >>> Adding more information about the release milestones. >>> This includes the scope of change, expectations, etc. > [...] >>> +rc1 >>> +~~~ >>> + >>> +* Priority: new or updated API. >> >> Can we just say API or libraries? > > Yes > >> Overall what is the intention for the 'priority' information? Should we really >> split release candidates for libraries, driver and applications? >> We merge all as much as possible before -rc1. > > The idea is to simply reflect the priority > in case time is limited. But yes we always merge as much as possible. > >> Can we say this other-way around, API/library features can't be merged after -rc1. > > Correct > >> And similarly driver features shouldn't be merged after -rc2, application >> changes shouldn't merge after -rc3. >> Fixes can be merged anytime before -rc4. After -rc4 only critical fixes and >> documentation changes. >> >> Just I want to highlight that for example we merge documentation updates >> anytime, it doesn't have to wait -rc4, but below listing looks like different >> part only allocated for different -rc, which is wrong as far as I know. > > I understand the confusion and will try to make it clearer in next revision. > >>> +* New API should be defined and implemented in libraries. >>> +* The API should include Doxygen documentation >> >> s/should/must > > OK > >>> + and be part of the relevant .rst files (library-specific and release notes). >>> +* API should be used in a test application (``/app``). >>> +* At least one PMD should implement the API. >>> + It can be a draft but must be sent as a separate series. >> >> I am not sure if "must be sent as a separate series" needs to be highlighted, >> having all in the same series has a benefit to see bigger picture. If the driver >> patches acked/reviewed by its maintainers, I think it can be merged in single >> series. > > That's not the same kind of review for driver and API, > not the same time constraint, and not the same iterations. > I think it is more practical to suggest separate, > but it should not be "must". > >>> +* The above should be sent to the mailing list at least 2 weeks before -rc1. >>> +* Nice to have: example code (``/examples``) >>> + >>> +rc2 >>> +~~~ >>> + >>> +* Priority: drivers. >>> +* New features should be implemented in drivers. >> >> I already mentioned above, but this can cause misunderstanding. We want all >> driver implementation to be ready for proposal deadline, same as other patches. >> But because of its reduced scope (they don't affect all project but only >> specific vendor), we are flexible to get driver features for -rc2 and -rc3 too. > > -rc3 really? It should be exceptional so not mentioned here. > In practice we are having it, but agree to have it exceptional and not mention in the guide. >> Please check number of driver patches merged for a release, it is impossible to >> manage them within period between -rc1 & -rc2. >> Also some driver features are complex and big, they should be sent before >> proposal deadline so that they can be reviewed for the release. > > Yes sooner is better. The doc is about deadline + priorities, > showing the no-go limits, without warranty of merge if all good. > Is there a contradiction? > My concern is document can be read as, it is normal/expected to send driver patches after -rc1, because this documents as -rc2 task is driver patches. I am OK with it if it is clear that deadline is -rc2, but normal/expected is to have driver patches also before proposal deadline. >>> +* A driver change should include documentation >> >> s/should/must > > Sometimes there is no doc to change. Is "must" confusing? > I believe we can improve our documentation, there are some new features driver or library, not documented at all. But you are right, there may be driver features that may not require any documentation, but if there is a feature big enough for documentation, I am for having documentation as a 'must', not sure how to clearly document this. >>> + in the relevant .rst files (driver-specific and release notes). >>> +* The above should be sent to the mailing list at least 2 weeks before -rc2. >>> + >>> +rc3 >>> +~~~ >>> + >>> +* Priority: applications. >>> +* New functionality that does not depend on libraries update >>> + can be integrated as part of -rc3. >> >> Again for same issue, let me share my understanding, >> the -rc1 has been tested widely, after that each -rc gets less and less tests. >> So the -rc1 should have API/library changes, so that they will be tested more >> and will have more time to fix any issues, since library changes has biggest >> impact for the project. >> >> Next biggest impact is drivers. >> >> Applications and unit tests are internal to DPDK, they have no user impact, that >> is why we can get more risk with them and they can be merged even as late as rc3. >> >> And documentation doesn't have anything related to testing, or they don't >> introduce any risk for specific release, so they are merged until last stage of >> the release. > > Yes > >>> +* The application should include documentation in the relevant .rst files >>> + (application-specific and release notes if significant). >> >> s/should/must >> >>> +* It may be the last opportunity for miscellaneous changes. >> >> This is very vague, what does misch changes mean? > > Scripts, code cleanup, yes it is vague, we can remove. > >>> +* Libraries and drivers cleanup are allowed. >>> +* Small driver reworks. >>> +* Critical and minor bug fixes. >>> + >>> +rc4 >>> +~~~ >>> + >>> +* Documentation updates. >>> +* Critical bug fixes. > > >