From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2 1/1] linux: Make dtc install step more reliable
Date: Mon, 26 Nov 2018 08:58:03 +0100 [thread overview]
Message-ID: <20181126085803.254d439a@windsurf> (raw)
In-Reply-To: <bee731d7-dec3-399a-632b-7446e75fc034@andin.de>
Hello Andreas,
On Mon, 26 Nov 2018 08:50:35 +0100, Andreas Naumann wrote:
> > I hesitated a bit, but in the end decided to apply this to master.
> > Indeed, with the current code, it's really a matter of luck whether
> > host-dtc gets built before/after linux that determines if the dtc ->
> > linux-dtc symlink will be created or not. With this patch, regardless
> > of whether host-dtc is built before or after linux, we'll have the same
> > result. To me, this was a sufficient motivation to apply this patch to
> > master.
>
> Thanks for applying it. May I ask why you hesitated, was the commit
> message clear enough? Or just too small of an issue?
My hesitation was not whether to apply it or not, the explanation was
clear.
My hesitation was whether it should have been applied to our "master"
branch or to our "next" branch.
We have a release process that works as follows:
1 After a release, say 2018.08, we have two months of active
development. During this time period, all changes go to the master
branch: both fixes and major changes (package updates, new packages,
infrastructure changes, etc.)
2 After two months of development, we cut the -rc1 of the next
release, for example 2018.11-rc1. At this point, we stop merging new
development in the "master" branch, and only merge
bug/security/build fixes. In order to avoid completely stopping the
merge of new features, we open a "next" branch.
3 During one month, we have these split master/next branches, until
the final 2018.11 is released, from the master branch.
4 Once 2018.11 is cut, we merge "next" back into "master" and goto
step 1.
We are currently in step (2), so for each change we have to decide
whether the change should be committed to the master branch or the next
branch. Some changes are obvious: a build fix goes to master, a new
package goes to next. Some other changes are less obvious, and for this
specific patch, I hesitated a bit between applying to master and next.
That's all what I meant to say.
Does this clarify the hesitation ?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2018-11-26 7:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-13 15:50 [Buildroot] [PATCH v2 1/1] linux: Make dtc install step more reliable Andreas Naumann
2018-11-23 21:29 ` Thomas Petazzoni
2018-11-26 7:50 ` Andreas Naumann
2018-11-26 7:58 ` Thomas Petazzoni [this message]
2018-11-26 8:14 ` Andreas Naumann
2018-11-26 17:48 ` Peter Korsgaard
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=20181126085803.254d439a@windsurf \
--to=thomas.petazzoni@bootlin.com \
--cc=buildroot@busybox.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox