On Thu, Nov 8, 2018 at 12:14 PM Theodore Y. Ts'o wrote:
>
> On Thu, Nov 08, 2018 at 09:19:33AM -0800, Dan Williams wrote:
> >
> > I know at least StGit mail does not grok that "#"notation. I've
> > stopped using it in favor of a "Fixes:" tag. I would think "Fixes:" is
> > preferred over "# " if
On Thu, Nov 8, 2018 at 12:14 PM Theodore Y. Ts'o wrote:
>
> On Thu, Nov 08, 2018 at 09:19:33AM -0800, Dan Williams wrote:
> >
> > I know at least StGit mail does not grok that "#"notation. I've
> > stopped using it in favor of a "Fixes:" tag. I would think "Fixes:" is
> > preferred over "# " if
On Thu, 8 Nov 2018, Greg KH wrote:
> On Thu, Nov 08, 2018 at 08:58:32PM +0100, Thomas Gleixner wrote:
> > Fixes: 1234567890AB ("subsys/comp: Short summary")
> > Backport-to: 4.14
>
> Ick, no. Just stick to the "Fixes:" tag. My scripts can now track when
> a patch is backported to a
On Thu, 8 Nov 2018, Greg KH wrote:
> On Thu, Nov 08, 2018 at 08:58:32PM +0100, Thomas Gleixner wrote:
> > Fixes: 1234567890AB ("subsys/comp: Short summary")
> > Backport-to: 4.14
>
> Ick, no. Just stick to the "Fixes:" tag. My scripts can now track when
> a patch is backported to a
On Thu, Nov 08, 2018 at 05:19:47PM -0500, Theodore Y. Ts'o wrote:
> On Thu, Nov 08, 2018 at 01:04:49PM -0800, Greg KH wrote:
> > > (Also note that even with fast SSD's and/or everything in page cache,
> > > runnning "tag --contains " will take a good 3-4 seconds, and
> > > if the git packs are not
On Thu, Nov 08, 2018 at 05:19:47PM -0500, Theodore Y. Ts'o wrote:
> On Thu, Nov 08, 2018 at 01:04:49PM -0800, Greg KH wrote:
> > > (Also note that even with fast SSD's and/or everything in page cache,
> > > runnning "tag --contains " will take a good 3-4 seconds, and
> > > if the git packs are not
On Thu, Nov 08, 2018 at 01:04:49PM -0800, Greg KH wrote:
> > (Also note that even with fast SSD's and/or everything in page cache,
> > runnning "tag --contains " will take a good 3-4 seconds, and
> > if the git packs are not in the page cache, and/or you're unfortunate
> > enough to have your git
On Thu, Nov 08, 2018 at 01:04:49PM -0800, Greg KH wrote:
> > (Also note that even with fast SSD's and/or everything in page cache,
> > runnning "tag --contains " will take a good 3-4 seconds, and
> > if the git packs are not in the page cache, and/or you're unfortunate
> > enough to have your git
On Thu, Nov 08, 2018 at 01:06:15PM -0800, Greg KH wrote:
> On Thu, Nov 08, 2018 at 08:58:32PM +0100, Thomas Gleixner wrote:
> > On Thu, 8 Nov 2018, Paul E. McKenney wrote:
> > > On Thu, Nov 08, 2018 at 09:19:33AM -0800, Dan Williams wrote:
> > > > On Thu, Nov 8, 2018 at 1:13 AM Peter Zijlstra
>
On Thu, Nov 08, 2018 at 01:06:15PM -0800, Greg KH wrote:
> On Thu, Nov 08, 2018 at 08:58:32PM +0100, Thomas Gleixner wrote:
> > On Thu, 8 Nov 2018, Paul E. McKenney wrote:
> > > On Thu, Nov 08, 2018 at 09:19:33AM -0800, Dan Williams wrote:
> > > > On Thu, Nov 8, 2018 at 1:13 AM Peter Zijlstra
>
On Thu, Nov 08, 2018 at 08:58:32PM +0100, Thomas Gleixner wrote:
> On Thu, 8 Nov 2018, Paul E. McKenney wrote:
> > On Thu, Nov 08, 2018 at 09:19:33AM -0800, Dan Williams wrote:
> > > On Thu, Nov 8, 2018 at 1:13 AM Peter Zijlstra
> > > wrote:
> > > >
> > > > On Thu, Nov 08, 2018 at 08:40:12AM
On Thu, Nov 08, 2018 at 08:58:32PM +0100, Thomas Gleixner wrote:
> On Thu, 8 Nov 2018, Paul E. McKenney wrote:
> > On Thu, Nov 08, 2018 at 09:19:33AM -0800, Dan Williams wrote:
> > > On Thu, Nov 8, 2018 at 1:13 AM Peter Zijlstra
> > > wrote:
> > > >
> > > > On Thu, Nov 08, 2018 at 08:40:12AM
On Thu, Nov 08, 2018 at 03:14:25PM -0500, Theodore Y. Ts'o wrote:
> On Thu, Nov 08, 2018 at 09:19:33AM -0800, Dan Williams wrote:
> >
> > I know at least StGit mail does not grok that "#"notation. I've
> > stopped using it in favor of a "Fixes:" tag. I would think "Fixes:" is
> > preferred over
On Thu, Nov 08, 2018 at 03:14:25PM -0500, Theodore Y. Ts'o wrote:
> On Thu, Nov 08, 2018 at 09:19:33AM -0800, Dan Williams wrote:
> >
> > I know at least StGit mail does not grok that "#"notation. I've
> > stopped using it in favor of a "Fixes:" tag. I would think "Fixes:" is
> > preferred over
On Thu, 8 Nov 2018, Theodore Y. Ts'o wrote:
> On Thu, Nov 08, 2018 at 09:19:33AM -0800, Dan Williams wrote:
> >
> > I know at least StGit mail does not grok that "#"notation. I've
> > stopped using it in favor of a "Fixes:" tag. I would think "Fixes:" is
> > preferred over "# " if only because
On Thu, 8 Nov 2018, Theodore Y. Ts'o wrote:
> On Thu, Nov 08, 2018 at 09:19:33AM -0800, Dan Williams wrote:
> >
> > I know at least StGit mail does not grok that "#"notation. I've
> > stopped using it in favor of a "Fixes:" tag. I would think "Fixes:" is
> > preferred over "# " if only because
On Thu, Nov 08, 2018 at 09:19:33AM -0800, Dan Williams wrote:
>
> I know at least StGit mail does not grok that "#"notation. I've
> stopped using it in favor of a "Fixes:" tag. I would think "Fixes:" is
> preferred over "# " if only because it can be used to track
> fixes to commits that have
On Thu, Nov 08, 2018 at 09:19:33AM -0800, Dan Williams wrote:
>
> I know at least StGit mail does not grok that "#"notation. I've
> stopped using it in favor of a "Fixes:" tag. I would think "Fixes:" is
> preferred over "# " if only because it can be used to track
> fixes to commits that have
On Thu, Nov 08, 2018 at 08:58:32PM +0100, Thomas Gleixner wrote:
> On Thu, 8 Nov 2018, Paul E. McKenney wrote:
> > On Thu, Nov 08, 2018 at 09:19:33AM -0800, Dan Williams wrote:
> > > On Thu, Nov 8, 2018 at 1:13 AM Peter Zijlstra
> > > wrote:
> > > >
> > > > On Thu, Nov 08, 2018 at 08:40:12AM
On Thu, Nov 08, 2018 at 08:58:32PM +0100, Thomas Gleixner wrote:
> On Thu, 8 Nov 2018, Paul E. McKenney wrote:
> > On Thu, Nov 08, 2018 at 09:19:33AM -0800, Dan Williams wrote:
> > > On Thu, Nov 8, 2018 at 1:13 AM Peter Zijlstra
> > > wrote:
> > > >
> > > > On Thu, Nov 08, 2018 at 08:40:12AM
On Thu, 8 Nov 2018, Paul E. McKenney wrote:
> On Thu, Nov 08, 2018 at 09:19:33AM -0800, Dan Williams wrote:
> > On Thu, Nov 8, 2018 at 1:13 AM Peter Zijlstra wrote:
> > >
> > > On Thu, Nov 08, 2018 at 08:40:12AM +0100, Ingo Molnar wrote:
> > > > > + - Cc: ``cc-ed-person ``
> > > > > +
> > > > > +
On Thu, 8 Nov 2018, Paul E. McKenney wrote:
> On Thu, Nov 08, 2018 at 09:19:33AM -0800, Dan Williams wrote:
> > On Thu, Nov 8, 2018 at 1:13 AM Peter Zijlstra wrote:
> > >
> > > On Thu, Nov 08, 2018 at 08:40:12AM +0100, Ingo Molnar wrote:
> > > > > + - Cc: ``cc-ed-person ``
> > > > > +
> > > > > +
On Thu, Nov 08, 2018 at 09:19:33AM -0800, Dan Williams wrote:
> On Thu, Nov 8, 2018 at 1:13 AM Peter Zijlstra wrote:
> >
> > On Thu, Nov 08, 2018 at 08:40:12AM +0100, Ingo Molnar wrote:
> > > > + - Cc: ``cc-ed-person ``
> > > > +
> > > > + If the patch should be backported to stable, then
On Thu, Nov 08, 2018 at 09:19:33AM -0800, Dan Williams wrote:
> On Thu, Nov 8, 2018 at 1:13 AM Peter Zijlstra wrote:
> >
> > On Thu, Nov 08, 2018 at 08:40:12AM +0100, Ingo Molnar wrote:
> > > > + - Cc: ``cc-ed-person ``
> > > > +
> > > > + If the patch should be backported to stable, then
On Thu, Nov 08, 2018 at 09:19:33AM -0800, Dan Williams wrote:
> I know at least StGit mail does not grok that "#"notation. I've
> stopped using it in favor of a "Fixes:" tag. I would think "Fixes:" is
> preferred over "# " if only because it can be used to track
> fixes to commits that have been
On Thu, Nov 08, 2018 at 09:19:33AM -0800, Dan Williams wrote:
> I know at least StGit mail does not grok that "#"notation. I've
> stopped using it in favor of a "Fixes:" tag. I would think "Fixes:" is
> preferred over "# " if only because it can be used to track
> fixes to commits that have been
On Thu, Nov 8, 2018 at 1:13 AM Peter Zijlstra wrote:
>
> On Thu, Nov 08, 2018 at 08:40:12AM +0100, Ingo Molnar wrote:
> > > + - Cc: ``cc-ed-person ``
> > > +
> > > + If the patch should be backported to stable, then please add a '``Cc:
> > > + sta...@vger.kernel.org``' tag, but do not Cc
On Thu, Nov 8, 2018 at 1:13 AM Peter Zijlstra wrote:
>
> On Thu, Nov 08, 2018 at 08:40:12AM +0100, Ingo Molnar wrote:
> > > + - Cc: ``cc-ed-person ``
> > > +
> > > + If the patch should be backported to stable, then please add a '``Cc:
> > > + sta...@vger.kernel.org``' tag, but do not Cc
On Thu, Nov 08, 2018 at 10:12:51AM +0100, Peter Zijlstra wrote:
> On Thu, Nov 08, 2018 at 08:40:12AM +0100, Ingo Molnar wrote:
> > > + - Cc: ``cc-ed-person ``
> > > +
> > > + If the patch should be backported to stable, then please add a '``Cc:
> > > + sta...@vger.kernel.org``' tag, but do not
On Thu, Nov 08, 2018 at 10:12:51AM +0100, Peter Zijlstra wrote:
> On Thu, Nov 08, 2018 at 08:40:12AM +0100, Ingo Molnar wrote:
> > > + - Cc: ``cc-ed-person ``
> > > +
> > > + If the patch should be backported to stable, then please add a '``Cc:
> > > + sta...@vger.kernel.org``' tag, but do not
On Thu, Nov 08, 2018 at 08:40:12AM +0100, Ingo Molnar wrote:
> > + - Cc: ``cc-ed-person ``
> > +
> > + If the patch should be backported to stable, then please add a '``Cc:
> > + sta...@vger.kernel.org``' tag, but do not Cc stable when sending your
> > + mail.
>
> Can I suggest a more
On Thu, Nov 08, 2018 at 08:40:12AM +0100, Ingo Molnar wrote:
> > + - Cc: ``cc-ed-person ``
> > +
> > + If the patch should be backported to stable, then please add a '``Cc:
> > + sta...@vger.kernel.org``' tag, but do not Cc stable when sending your
> > + mail.
>
> Can I suggest a more
* Thomas Gleixner wrote:
> +Line breaks
> +^^^
> +
> +Restricting line length to 80 characters makes deeply indented code hard to
> +read. Consider breaking out code into helper functions to avoid excessive
> +line breaking.
> +
> +The 80 character rule is not a strict rule, so please
* Thomas Gleixner wrote:
> +Line breaks
> +^^^
> +
> +Restricting line length to 80 characters makes deeply indented code hard to
> +read. Consider breaking out code into helper functions to avoid excessive
> +line breaking.
> +
> +The 80 character rule is not a strict rule, so please
* Thomas Gleixner wrote:
> +Commit notifications
> +
> +
> +The tip tree is monitored by a bot for new commits. The bot sends an email
> +for each new commit to a dedicated mailing list
> +(``linux-tip-comm...@vger.kernel.org``) and Cc's all people who are
> +mentioned in
* Thomas Gleixner wrote:
> +Commit notifications
> +
> +
> +The tip tree is monitored by a bot for new commits. The bot sends an email
> +for each new commit to a dedicated mailing list
> +(``linux-tip-comm...@vger.kernel.org``) and Cc's all people who are
> +mentioned in
* Thomas Gleixner wrote:
> +Namespaces
> +^^
> +
> +To improve readability and to allow easy grepping for information the usage
> +of consistent namespaces is important. The namespace should be used as a
> +prefix for globally visible (inline) functions and variables. A simple rule
>
* Thomas Gleixner wrote:
> +Namespaces
> +^^
> +
> +To improve readability and to allow easy grepping for information the usage
> +of consistent namespaces is important. The namespace should be used as a
> +prefix for globally visible (inline) functions and variables. A simple rule
>
* Thomas Gleixner wrote:
> +Variable types
> +^^
> +
> +Please use the proper u8, u16, u32, u64 types for variables which are meant
> +to describe hardware or are used as arguments for functions which access
> +hardware. These types are clearly defining the bit width and avoid
>
* Thomas Gleixner wrote:
> +Variable types
> +^^
> +
> +Please use the proper u8, u16, u32, u64 types for variables which are meant
> +to describe hardware or are used as arguments for functions which access
> +hardware. These types are clearly defining the bit width and avoid
>
Lemme fill in the scheduler and locking/atomics bits as well:
> +The tip tree contains the following subsystems:
> +
> + - **x86 architecture**
> +
> + The x86 architecture development takes place in the tip tree except
> + for the x86 KVM and XEN specific parts which are maintained
Lemme fill in the scheduler and locking/atomics bits as well:
> +The tip tree contains the following subsystems:
> +
> + - **x86 architecture**
> +
> + The x86 architecture development takes place in the tip tree except
> + for the x86 KVM and XEN specific parts which are maintained
* Thomas Gleixner wrote:
> + - Signed-off-by: ``Patch handler ``
> +
> + SOBs after the author SOB are from people handling and transporting the
> + patch, but were not involved in development. If the handler made
> + modifications to the patch or the changelog, then this should be
> +
* Thomas Gleixner wrote:
> + - Signed-off-by: ``Patch handler ``
> +
> + SOBs after the author SOB are from people handling and transporting the
> + patch, but were not involved in development. If the handler made
> + modifications to the patch or the changelog, then this should be
> +
* Thomas Gleixner wrote:
> + - Fixes: 12char-SHA1 ("sub/sys: Original subject line")
> +
> + A Fixes tag should be added even for changes which do not need to be
> + backported to stable kernels, i.e. when addressing a recently introduced
> + issue which only affects tip or the current
* Thomas Gleixner wrote:
> + - Fixes: 12char-SHA1 ("sub/sys: Original subject line")
> +
> + A Fixes tag should be added even for changes which do not need to be
> + backported to stable kernels, i.e. when addressing a recently introduced
> + issue which only affects tip or the current
* Thomas Gleixner wrote:
> +Backtraces in changelogs
> +
> +
> +Backtraces can be useful to document the call chain which led to a
> +problem. Though not all back traces are really valuable because the call
> +chain is unique and obvious, e.g. in early boot code. Just
* Thomas Gleixner wrote:
> +Backtraces in changelogs
> +
> +
> +Backtraces can be useful to document the call chain which led to a
> +problem. Though not all back traces are really valuable because the call
> +chain is unique and obvious, e.g. in early boot code. Just
* Ingo Molnar wrote:
> With tail comments the code looks like this:
>
> res = dostuff(); /* We explain something here. */
>
> seed = 1; /* Another explanation. */
>
> mod_timer(_object->our_timer, jiffies + OUR_INTERVAL); /* We like
> to talk */
>
> res =
* Ingo Molnar wrote:
> With tail comments the code looks like this:
>
> res = dostuff(); /* We explain something here. */
>
> seed = 1; /* Another explanation. */
>
> mod_timer(_object->our_timer, jiffies + OUR_INTERVAL); /* We like
> to talk */
>
> res =
* Thomas Gleixner wrote:
> +Coding style notes
> +--
> +
> +Comment style
> +^
> +
> +Sentences in comments start with a uppercase letter.
> +
> +Single line comments::
> +
> + /* This is a single line comment */
> +
> +Multi-line comments::
> +
> + /*
> +
* Thomas Gleixner wrote:
> +Coding style notes
> +--
> +
> +Comment style
> +^
> +
> +Sentences in comments start with a uppercase letter.
> +
> +Single line comments::
> +
> + /* This is a single line comment */
> +
> +Multi-line comments::
> +
> + /*
> +
On Wed, Nov 07, 2018 at 06:44:07PM +0100, Thomas Gleixner wrote:
> On Wed, 7 Nov 2018, Thomas Gleixner wrote:
>
> > Add a document to the subsystem/maintainer handbook section, which explains
> > what the tip tree is, how it operates and what rules and expectations it
> > has.
>
> Peter asked me
On Wed, Nov 07, 2018 at 06:44:07PM +0100, Thomas Gleixner wrote:
> On Wed, 7 Nov 2018, Thomas Gleixner wrote:
>
> > Add a document to the subsystem/maintainer handbook section, which explains
> > what the tip tree is, how it operates and what rules and expectations it
> > has.
>
> Peter asked me
On Wed, Nov 07, 2018 at 06:10:12PM +0100, Thomas Gleixner wrote:
> Add a document to the subsystem/maintainer handbook section, which explains
> what the tip tree is, how it operates and what rules and expectations it
> has.
>
> Signed-off-by: Thomas Gleixner
A few more suggestions below, again
On Wed, Nov 07, 2018 at 06:10:12PM +0100, Thomas Gleixner wrote:
> Add a document to the subsystem/maintainer handbook section, which explains
> what the tip tree is, how it operates and what rules and expectations it
> has.
>
> Signed-off-by: Thomas Gleixner
A few more suggestions below, again
On Wed, 7 Nov 2018, Thomas Gleixner wrote:
> Add a document to the subsystem/maintainer handbook section, which explains
> what the tip tree is, how it operates and what rules and expectations it
> has.
Peter asked me to add a section about locking comments. I added it and
forgot to refresh the
On Wed, 7 Nov 2018, Thomas Gleixner wrote:
> Add a document to the subsystem/maintainer handbook section, which explains
> what the tip tree is, how it operates and what rules and expectations it
> has.
Peter asked me to add a section about locking comments. I added it and
forgot to refresh the
Add a document to the subsystem/maintainer handbook section, which explains
what the tip tree is, how it operates and what rules and expectations it
has.
Signed-off-by: Thomas Gleixner
---
Documentation/process/maintainer-handbooks.rst |2
Documentation/process/maintainer-tip.rst |
Add a document to the subsystem/maintainer handbook section, which explains
what the tip tree is, how it operates and what rules and expectations it
has.
Signed-off-by: Thomas Gleixner
---
Documentation/process/maintainer-handbooks.rst |2
Documentation/process/maintainer-tip.rst |
60 matches
Mail list logo