Mehdi Amini via llvm-dev
2016-May-02 21:26 UTC
[llvm-dev] [RFC] Helping release management
> On May 2, 2016, at 2:05 PM, Smith, Kevin B via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > >> -----Original Message----- >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of >> Quentin Colombet via llvm-dev >> Sent: Monday, May 02, 2016 1:35 PM >> To: llvm-dev <llvm-dev at lists.llvm.org> >> Subject: [llvm-dev] [RFC] Helping release management >> >> Hi, >> >> I am sending this proposal to get feedbacks on how we could make the >> tagging of bug fixes and regressions more obvious. The idea is to provide >> easily accessible information to help deciding what to cherry-pick in a release >> branch. >> >> * Context * >> >> People shipping compilers based on LLVM may not completely align with the >> official releases of LLVM. Thus, the stabilization of each custom release may >> happen at different period of time. Because of that, release managers have >> to come up with their own strategy to decide which commits should be >> cherry-picked during the stabilization of their release branch. >> >> For the official LLVM releases, people (committers, code owners, etc.) notice >> LLVM release managers that a given commit is worth pulling into the release. >> I would like to put in place something more systematic and that plays nicely >> with scripting and such that would extend this mechanism. >> > > This seems like a great idea to me. > >> * Proposal * >> >> 1. Use [Fix] for commit related to bug fixes. > > a specific form would be best: [Fix] PR12345, or [FIX] Bug introduced in r56789.The first line of the commit is interpreted as a "title" by "git based" tools. I rather have a self-contained first line and avoid *any* external reference there. (The commit message can be as long as you want). -- Mehdi> >> 2. Add a description of the problem in the commit message to help answer >> the following questions: >> - What is fixed? >> - Which targets are impacted? >> - What is required to trigger the bug? (I.e., how often the end users may >> encounter it.) >> - When was the bug introduced? > > This is super important for things that regress, and then get fixed before a PR is even filed. Even for a PR if the problem was introduced in a known > revision, having that in the commit message helps to understand whether some other revision is really safe to pull into a release. > >> >> #1 At the very least, I would like that each bug fix has a tag on the first line of >> the commit (i.e., what ends up in the subject line of the related email.) >> Something like [Fix] would do. >> Thanks to that tag, it would be possible to easily filter bug fixes in email and >> other cherry-picking helper tools, I believe. >> >> #2 Although it may be difficult to come up with that information, I believe it >> should be provided as the best of the committer knowledge. Indeed, this >> kind of information is useful to help release managers to ascertain how >> relevant is a change for their release and thus help them to decide whether to >> cherry-pick this change or not. >> >> What do people think? > > I like it. > >> >> Thanks, >> -Quentin >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
----- Original Message -----> From: "Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Kevin B Smith" <kevin.b.smith at intel.com> > Cc: llvm-dev at lists.llvm.org > Sent: Monday, May 2, 2016 4:26:30 PM > Subject: Re: [llvm-dev] [RFC] Helping release management > > > > On May 2, 2016, at 2:05 PM, Smith, Kevin B via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > > > > > > > >> -----Original Message----- > >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf > >> Of > >> Quentin Colombet via llvm-dev > >> Sent: Monday, May 02, 2016 1:35 PM > >> To: llvm-dev <llvm-dev at lists.llvm.org> > >> Subject: [llvm-dev] [RFC] Helping release management > >> > >> Hi, > >> > >> I am sending this proposal to get feedbacks on how we could make > >> the > >> tagging of bug fixes and regressions more obvious. The idea is to > >> provide > >> easily accessible information to help deciding what to cherry-pick > >> in a release > >> branch. > >> > >> * Context * > >> > >> People shipping compilers based on LLVM may not completely align > >> with the > >> official releases of LLVM. Thus, the stabilization of each custom > >> release may > >> happen at different period of time. Because of that, release > >> managers have > >> to come up with their own strategy to decide which commits should > >> be > >> cherry-picked during the stabilization of their release branch. > >> > >> For the official LLVM releases, people (committers, code owners, > >> etc.) notice > >> LLVM release managers that a given commit is worth pulling into > >> the release. > >> I would like to put in place something more systematic and that > >> plays nicely > >> with scripting and such that would extend this mechanism. > >> > > > > This seems like a great idea to me. > > > >> * Proposal * > >> > >> 1. Use [Fix] for commit related to bug fixes. > > > > a specific form would be best: [Fix] PR12345, or [FIX] Bug > > introduced in r56789. > > The first line of the commit is interpreted as a "title" by "git > based" tools. > I rather have a self-contained first line and avoid *any* external > reference there. > (The commit message can be as long as you want).+1 The title of each commit should briefly describe what the commit does. If we'd like to prefix the title with [Fix] or similar to indicate commits primarily intended as bug fixes, that sounds useful to me, but not essential. All of the other metadata should appear later in the commit message - it is the presence of this metadata we can search for in the commit logs that will be important. -Hal> > -- > Mehdi > > > > > > > >> 2. Add a description of the problem in the commit message to help > >> answer > >> the following questions: > >> - What is fixed? > >> - Which targets are impacted? > >> - What is required to trigger the bug? (I.e., how often the end > >> users may > >> encounter it.) > >> - When was the bug introduced? > > > > This is super important for things that regress, and then get fixed > > before a PR is even filed. Even for a PR if the problem was > > introduced in a known > > revision, having that in the commit message helps to understand > > whether some other revision is really safe to pull into a release. > > > >> > >> #1 At the very least, I would like that each bug fix has a tag on > >> the first line of > >> the commit (i.e., what ends up in the subject line of the related > >> email.) > >> Something like [Fix] would do. > >> Thanks to that tag, it would be possible to easily filter bug > >> fixes in email and > >> other cherry-picking helper tools, I believe. > >> > >> #2 Although it may be difficult to come up with that information, > >> I believe it > >> should be provided as the best of the committer knowledge. Indeed, > >> this > >> kind of information is useful to help release managers to > >> ascertain how > >> relevant is a change for their release and thus help them to > >> decide whether to > >> cherry-pick this change or not. > >> > >> What do people think? > > > > I like it. > > > >> > >> Thanks, > >> -Quentin > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
Philip Reames via llvm-dev
2016-May-05 01:04 UTC
[llvm-dev] [RFC] Helping release management
On 05/02/2016 02:43 PM, Hal Finkel via llvm-dev wrote:> ----- Original Message ----- >> From: "Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org> >> To: "Kevin B Smith" <kevin.b.smith at intel.com> >> Cc: llvm-dev at lists.llvm.org >> Sent: Monday, May 2, 2016 4:26:30 PM >> Subject: Re: [llvm-dev] [RFC] Helping release management >> >> >>> On May 2, 2016, at 2:05 PM, Smith, Kevin B via llvm-dev >>> <llvm-dev at lists.llvm.org> wrote: >>> >>> >>> >>>> -----Original Message----- >>>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf >>>> Of >>>> Quentin Colombet via llvm-dev >>>> Sent: Monday, May 02, 2016 1:35 PM >>>> To: llvm-dev <llvm-dev at lists.llvm.org> >>>> Subject: [llvm-dev] [RFC] Helping release management >>>> >>>> Hi, >>>> >>>> I am sending this proposal to get feedbacks on how we could make >>>> the >>>> tagging of bug fixes and regressions more obvious. The idea is to >>>> provide >>>> easily accessible information to help deciding what to cherry-pick >>>> in a release >>>> branch. >>>> >>>> * Context * >>>> >>>> People shipping compilers based on LLVM may not completely align >>>> with the >>>> official releases of LLVM. Thus, the stabilization of each custom >>>> release may >>>> happen at different period of time. Because of that, release >>>> managers have >>>> to come up with their own strategy to decide which commits should >>>> be >>>> cherry-picked during the stabilization of their release branch. >>>> >>>> For the official LLVM releases, people (committers, code owners, >>>> etc.) notice >>>> LLVM release managers that a given commit is worth pulling into >>>> the release. >>>> I would like to put in place something more systematic and that >>>> plays nicely >>>> with scripting and such that would extend this mechanism. >>>> >>> This seems like a great idea to me. >>> >>>> * Proposal * >>>> >>>> 1. Use [Fix] for commit related to bug fixes. >>> a specific form would be best: [Fix] PR12345, or [FIX] Bug >>> introduced in r56789. >> The first line of the commit is interpreted as a "title" by "git >> based" tools. >> I rather have a self-contained first line and avoid *any* external >> reference there. >> (The commit message can be as long as you want). > +1 > > The title of each commit should briefly describe what the commit does. If we'd like to prefix the title with [Fix] or similar to indicate commits primarily intended as bug fixes, that sounds useful to me, but not essential. All of the other metadata should appear later in the commit message - it is the presence of this metadata we can search for in the commit logs that will be important.+1 I would be strongly opposed to any proposal which involved putting less human readable context in the subject.> > -Hal > >> -- >> Mehdi >> >> >> >> >>>> 2. Add a description of the problem in the commit message to help >>>> answer >>>> the following questions: >>>> - What is fixed? >>>> - Which targets are impacted? >>>> - What is required to trigger the bug? (I.e., how often the end >>>> users may >>>> encounter it.) >>>> - When was the bug introduced? >>> This is super important for things that regress, and then get fixed >>> before a PR is even filed. Even for a PR if the problem was >>> introduced in a known >>> revision, having that in the commit message helps to understand >>> whether some other revision is really safe to pull into a release. >>> >>>> #1 At the very least, I would like that each bug fix has a tag on >>>> the first line of >>>> the commit (i.e., what ends up in the subject line of the related >>>> email.) >>>> Something like [Fix] would do. >>>> Thanks to that tag, it would be possible to easily filter bug >>>> fixes in email and >>>> other cherry-picking helper tools, I believe. >>>> >>>> #2 Although it may be difficult to come up with that information, >>>> I believe it >>>> should be provided as the best of the committer knowledge. Indeed, >>>> this >>>> kind of information is useful to help release managers to >>>> ascertain how >>>> relevant is a change for their release and thus help them to >>>> decide whether to >>>> cherry-pick this change or not. >>>> >>>> What do people think? >>> I like it. >>> >>>> Thanks, >>>> -Quentin >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>