All of lore.kernel.org
 help / color / mirror / Atom feed
From: gregkh at linuxfoundation.org (Greg KH)
Subject: [Linux-kernel-mentees] git: Behaviour of the stable-rc repo
Date: Sat, 6 Jul 2019 10:19:26 +0200	[thread overview]
Message-ID: <20190706081926.GA8177@kroah.com> (raw)
In-Reply-To: <20190706065655.GA10163@arch>

On Sat, Jul 06, 2019 at 12:28:07PM +0530, Amol Surati wrote:
> Hi,
> 
> Since yesterday, the stable-rc branch 'linux-5.1.y' has received new
> commits.

The stable-rc tree is a rebased mess of a git tree, don't use it unless
you really understand git :)

> There were 7 code-change-commits + 1 version-change-commit, which were
> based on the released 5.1.16. Now, when the branch has been refreshed
> (twice afaics) with new commits, those 8 previous commits have been assigned
> new identities (still based on 5.1.16).
> 
> It seems that there are 3 copies of those 8 commits.
> For e.g., the version-change-commit has these IDs -
> 
> 57f5b343cdf9593b22d79f5261f30243c07d6515,
> 925bedf91c6bb194cb6b23a553cb8469f3a2007f, and
> 2b5fd394355ac0b2cc9572232727cb2bce7c15a7
> 
> with 2b5... being the most recent ID (and the HEAD iinm).
> 
> Could you help me understand how these copies are created, and why?
> 
> Also, why do we want to commit the version update, if more commits are
> expected to arrive on top of it?

The stable kernel tree patches are kept as a series of patches that will
be applied on top of the previous version, using a tool called quilt.
That set of quilt patches can be found in the stable-queue.git tree on
git.kernel.org.

>From that quilt tree of patches, I generate the stable-rc tree every so
often so that people who only use git, have an easier way to test
things.  The tree is constantly rebased and rebuilt every time I do a
new push to it and a number of autobuilders and testing systems watch it
and send me automated reports when it changes.

So I recommend ONLY using it if you just always rebase, and treat it
like a "point in time" type of tree.

When I do a "real" -rc release, I do an announcement to the stable
mailing list and lkml and push out a compressed patch that you can apply
to the last released kernel, or you can pull from the stable-rc tree
(again rebasing) if that is easier for you to test from.

Does this help?  The stable-rc tree there is present only for those who
don't like dealing with quilt, and I never use it myself, I only
generate it for others who can use it for early testing.

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: gregkh@linuxfoundation.org (Greg KH)
Subject: [Linux-kernel-mentees] git: Behaviour of the stable-rc repo
Date: Sat, 6 Jul 2019 10:19:26 +0200	[thread overview]
Message-ID: <20190706081926.GA8177@kroah.com> (raw)
Message-ID: <20190706081926.1UfWcCSEsYtIF6Vdnya1K7oUioQ6R3cx3YbdjQE0T_I@z> (raw)
In-Reply-To: <20190706065655.GA10163@arch>

On Sat, Jul 06, 2019 at 12:28:07PM +0530, Amol Surati wrote:
> Hi,
> 
> Since yesterday, the stable-rc branch 'linux-5.1.y' has received new
> commits.

The stable-rc tree is a rebased mess of a git tree, don't use it unless
you really understand git :)

> There were 7 code-change-commits + 1 version-change-commit, which were
> based on the released 5.1.16. Now, when the branch has been refreshed
> (twice afaics) with new commits, those 8 previous commits have been assigned
> new identities (still based on 5.1.16).
> 
> It seems that there are 3 copies of those 8 commits.
> For e.g., the version-change-commit has these IDs -
> 
> 57f5b343cdf9593b22d79f5261f30243c07d6515,
> 925bedf91c6bb194cb6b23a553cb8469f3a2007f, and
> 2b5fd394355ac0b2cc9572232727cb2bce7c15a7
> 
> with 2b5... being the most recent ID (and the HEAD iinm).
> 
> Could you help me understand how these copies are created, and why?
> 
> Also, why do we want to commit the version update, if more commits are
> expected to arrive on top of it?

The stable kernel tree patches are kept as a series of patches that will
be applied on top of the previous version, using a tool called quilt.
That set of quilt patches can be found in the stable-queue.git tree on
git.kernel.org.

>From that quilt tree of patches, I generate the stable-rc tree every so
often so that people who only use git, have an easier way to test
things.  The tree is constantly rebased and rebuilt every time I do a
new push to it and a number of autobuilders and testing systems watch it
and send me automated reports when it changes.

So I recommend ONLY using it if you just always rebase, and treat it
like a "point in time" type of tree.

When I do a "real" -rc release, I do an announcement to the stable
mailing list and lkml and push out a compressed patch that you can apply
to the last released kernel, or you can pull from the stable-rc tree
(again rebasing) if that is easier for you to test from.

Does this help?  The stable-rc tree there is present only for those who
don't like dealing with quilt, and I never use it myself, I only
generate it for others who can use it for early testing.

thanks,

greg k-h

  reply	other threads:[~2019-07-06  8:19 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-06  6:58 [Linux-kernel-mentees] git: Behaviour of the stable-rc repo suratiamol
2019-07-06  6:58 ` Amol Surati
2019-07-06  8:19 ` gregkh [this message]
2019-07-06  8:19   ` Greg KH
2019-07-06  9:19   ` suratiamol
2019-07-06  9:19     ` Amol Surati
2019-07-06  9:41     ` gregkh
2019-07-06  9:41       ` Greg KH
2019-07-06  9:45       ` gregkh
2019-07-06  9:45         ` Greg KH
2019-07-06 15:08         ` suratiamol
2019-07-06 15:08           ` Amol Surati
2019-07-06 15:06       ` suratiamol
2019-07-06 15:06         ` Amol Surati
2019-07-13  8:32       ` sheriffesseson
2019-07-13  8:32         ` Sheriff Esseson
2019-07-13 14:37         ` gregkh
2019-07-13 14:37           ` Greg KH
2019-07-13 16:07           ` sheriffesseson
2019-07-13 16:07             ` Sheriff Esseson
     [not found]           ` <20190713160035.GA11449@localhost>
     [not found]             ` <20190713160707.GA18148@kroah.com>
2019-07-13 19:59               ` sheriffesseson
2019-07-13 19:59                 ` Sheriff Esseson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190706081926.GA8177@kroah.com \
    --to=unknown@example.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.