On 04/19/2018 12:37 AM, 최우제 (Uze Choi) wrote:
> Dear IoTivity community,
>
> 1.4-rel branch has been created just before.
>
> According to the release process, branch should have been created when we
> make the RC1 tag.
>
> However, We delayed to create the release branch to minimize the gap which
> causes additional cherry pick work
>
> because there is lots of patches expected to be merged.
>
>>From the yesterday OSWG discussion, making release branch is better way to
> manage the CTT related bug intensively in the new branch.
>
> Currently there are several pending patches under the review finally
> destined to be merged, Please merge them into 1.4-rel branch.
> Antu(QA lead) is supposed to help this patch list management from yesterday
> OSWG CC.
This process will be eased if commit authors resubmit their patches
against 1.4-rel (and withdraw the ones set for master). Gerrit doesn't
have any easy way to do this. Then someone can merge these back into
master. [aside: I'm not sure who "someone" will be; Phil Coval did a lot
of heavy lifting during the 1.3 cycle, but he's said he's not really
available due to other duties].
It is of course simple enough to cherry pick (in fact, gerrit makes it
almost disturbingly easy - click a button and enter the new branch name)
but cherry picks aren't really an ideal model. Here is one description
of this problem:
====
In git, git cherry-pick copy/pastes a commit from one branch to another.
In doing so, when the commit is “pasted” onto the new branch, it now has
a new parent commit (which would be whatever the tip of that branch was
when the “paste” happened).
And since parent ids are part of the new commit’s SHA1 id, the pasted
commit now has a new commit id.
So you now have two physically distinct commits in your repository for
the same logical change. And no metadata tying them together.
Here is what the DAG would look like:
A -- B -- C -- E' trunk
\
D -- E release
Where E is the original hot fix commit on the release branch, and E' is
the copy of the E commit.
The DAG does not give any hints that these two separate commits are the
same conceptual change.
====
While we're at it, if anybody is still reading, it's helpful to write
clear commit messages, most especially the one-liner summary. This
document is often cited as the top resource for that topic:
https://chris.beams.io/posts/git-commit/
without pointing any fingers, we've had some pretty unhelpful commit
messages turn up recently (a couple of which I've been guilty of when a
"working title" for a quick change ended up being published without
being polished)
_______________________________________________
iotivity-dev mailing list
[email protected]
https://lists.iotivity.org/mailman/listinfo/iotivity-dev
