llvm dev - Dec 2018 - New LLVM git repository conversion prototype

On Thu, Dec 13, 2018 at 7:18 AM Alex Bradbury via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Thu, 13 Dec 2018 at 15:07, Hans Wennborg via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > On Thu, Dec 13, 2018 at 3:34 PM James Y Knight <jyknight at
google.com>
> wrote:
>
> > > We don't *need* it, no. But it might be useful.
> > >
> > > The purpose of this tag would not be for people to check out, but
> rather to allow "git describe" to return more interesting results
when run
> on master.
> > >
> > > See David Jones' email from Nov 16.
> >
> > Ah, okay. "git describe" is new to me :-) I still think
v8.0.0-base is
> > a better name though. v8.0.0-dev really sounds like something one
> > might check out to get the latest dev version.
>
>
Hmm, I wouldn't worry too much about checking out an old tag by accident...
that puts your client into detached head state, and git prints a nice, long
warning. (That sort of mistake should be obvious pretty quickly.)

v8.0.0-branchpoint might be even clearer, though obviously a little
longer.
>
Whatever the convention we choose, it's going to be painful to change once
folks get used to it. (So the wording of the tag is not entirely
inconsequential.) My expectation is that the `git describe` aliases will be
the typical way to refer to commits in a git world, and aliases like
v8.0.0-branchpoint-1234-abcdef seem a bit long to me... when I think about
how often I type "rNNNNNN" today, the "-branchpoint" part
seems almost
obsequious.

For a development tag, we should probably try to keep it short, simple, and
obvious. After all, we're fundamentally talking about a tag used for
development, not releases; something short, like "master-v8" would
yield
concise, obvious aliases like "master-v8-1234-abcdef01". (Tags on
release
branches are a fundamentally different matter, and could continue looking
exactly like they do today.)

FWIW, the conventions I've seen have been inconsistent. One possible
consideration: the "-dev" suffix is sometimes used to indicate a dirty
workspace, but git describe puts the --dirty suffix after the hash. (So
it's unambiguous, in any case.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181213/790fc7dc/attachment.html>

David Jones via llvm-dev <llvm-dev at lists.llvm.org> writes:
>     v8.0.0-branchpoint might be even clearer, though obviously a
>     little longer.
>
> Whatever the convention we choose, it's going to be painful to change
> once folks get used to it. (So the wording of the tag is not entirely
> inconsequential.) My expectation is that the `git describe` aliases
> will be the typical way to refer to commits in a git world, and
> aliases like v8.0.0-branchpoint-1234-abcdef seem a bit long to me...
> when I think about how often I type "rNNNNNN" today, the
> "-branchpoint" part seems almost obsequious.
FWIW we use "split" to mark such commits.  So it would be
v8.0.0-split.
But see below.
> For a development tag, we should probably try to keep it short,
> simple, and obvious. After all, we're fundamentally talking about a
> tag used for development, not releases; something short, like
> "master-v8" would yield concise, obvious aliases like
> "master-v8-1234-abcdef01". (Tags on release branches are a
> fundamentally different matter, and could continue looking exactly
> like they do today.)
"master" could be confusing for downstream.  For example we have a
setup
where our development happens on "master" and we have a branch called
"upstream_master" to pull from upstream.  It would be confusing to see
a
tag called "master" on a branch not named "master."

"v8.0.0-split/dev/branchpoint/whatever" could also be confusing to
downstream as it could conflict with downstream named tags if their
products happen to have version number conflicts.  Follwing Duncan's
suggestion, would llvm.org-8.0.0-split (or suggest some other suffix)
work?  I know it's longer but it would be unambiguous.

"Duncan P. N. Exon Smith via llvm-dev" <llvm-dev at
lists.llvm.org> writes:
> I have a mild preference for "llvm.org-8.0.0" (instead of
> "llvm-8.0.0"), since llvm.org is unambiguously a point of origin,
> whereas "llvm" could just refer to the content. E.g., some
downstreams
> might package their product with the name "llvm".
I have a slight preference for that too, for the same reasons.

                            -David

On Thu, Dec 13, 2018 at 11:25 AM David Greene <dag at cray.com> wrote:
> David Jones via llvm-dev <llvm-dev at lists.llvm.org> writes:
> > For a development tag, we should probably try to keep it short,
> > simple, and obvious. After all, we're fundamentally talking about
a
> > tag used for development, not releases; something short, like
> > "master-v8" would yield concise, obvious aliases like
> > "master-v8-1234-abcdef01". (Tags on release branches are a
> > fundamentally different matter, and could continue looking exactly
> > like they do today.)
>
> "master" could be confusing for downstream.  For example we have
a setup
> where our development happens on "master" and we have a branch
called
> "upstream_master" to pull from upstream.  It would be confusing
to see a
> tag called "master" on a branch not named "master."
>
> "v8.0.0-split/dev/branchpoint/whatever" could also be confusing
to
> downstream as it could conflict with downstream named tags if their
> products happen to have version number conflicts.  Follwing Duncan's
> suggestion, would llvm.org-8.0.0-split (or suggest some other suffix)
> work?  I know it's longer but it would be unambiguous.
>
>
(Just a side note: "split" seems ambiguous to me, in the sense of
whether
it's before or after the branch is cut: does it point to the start-point of
the release branch? Or does it point to the commit that bumps the version
number, which is [probably] immediately after? If the former, then `git
describe` would attribute the last commit to the wrong release; if the
latter, it's really not a "split," since it's only an ancestor
of one of
the sides. In any case, as long as the name we pick is consistently
reachable from master, and not from the release branch; and release branch
tags continue not to be reachable from master; then I think we'll be fine.)


> "Duncan P. N. Exon Smith via llvm-dev" <llvm-dev at
lists.llvm.org> writes:
>
> > I have a mild preference for "llvm.org-8.0.0" (instead of
> > "llvm-8.0.0"), since llvm.org is unambiguously a point of
origin,
> > whereas "llvm" could just refer to the content. E.g., some
downstreams
> > might package their product with the name "llvm".
>
> I have a slight preference for that too, for the same reasons.
>
I like Duncan's suggestions for release naming, and I could imagine
something like:

tags/llvm.org/v8.X.Y - development
tags/llvm.org/release/v8.0.0-rc1 - release candidate

heads/llvm.org/release_80 or heads/llvm.org/release/v8.0 - release branch
(the former matches existing branch names)

The more I look at it, the more I think the development tag should not
contain a valid, complete semver identifier -- those should be reserved for
tags pointing to release branches. (The whole impetus of adding dev tag is
that the tags on release branches are generally not ancestors of the master
HEAD.) Either v8 or v8.0 would satisfy that, since they are missing
minor/patch levels; something like v8.X.Y seems even clearer to me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181213/d5657e66/attachment.html>

On Thu, Dec 13, 2018 at 5:31 PM David Jones <dlj at google.com>
wrote:
>
> On Thu, Dec 13, 2018 at 7:18 AM Alex Bradbury via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>
>> On Thu, 13 Dec 2018 at 15:07, Hans Wennborg via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> >
>> > On Thu, Dec 13, 2018 at 3:34 PM James Y Knight <jyknight at
google.com> wrote:
>>
>> > > We don't *need* it, no. But it might be useful.
>> > >
>> > > The purpose of this tag would not be for people to check out,
but rather to allow "git describe" to return more interesting results
when run on master.
>> > >
>> > > See David Jones' email from Nov 16.
>> >
>> > Ah, okay. "git describe" is new to me :-) I still think
v8.0.0-base is
>> > a better name though. v8.0.0-dev really sounds like something one
>> > might check out to get the latest dev version.
>>
>
> Hmm, I wouldn't worry too much about checking out an old tag by
accident... that puts your client into detached head state, and git prints a
nice, long warning. (That sort of mistake should be obvious pretty quickly.)
I thought checking them out was the main use for tags. For example, if
I want to build version 4.9.0 of gcc, I clone their repo, check out
the gcc-4_9_0-release tag, and build. The detached state is fine since
I'm not planning to commit there. I might be using git all wrong of
course :-)
>> v8.0.0-branchpoint might be even clearer, though obviously a little
longer.
That suggests the tag is where we branched for 8.0.x though, but I
think the idea is to put the tag at the version bump, right after the
7.0.x branch point. So I don't think branchpoint is a good name -- it
seems we're already thinking it means different things :-)

> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
David
> Greene via llvm-dev
> Sent: Thursday, December 13, 2018 2:26 PM
> To: David Jones
> Cc: llvm-dev
> Subject: Re: [llvm-dev] New LLVM git repository conversion prototype
> 
> David Jones via llvm-dev <llvm-dev at lists.llvm.org> writes:
> ...
> > For a development tag, we should probably try to keep it short,
> > simple, and obvious. After all, we're fundamentally talking about
a
> > tag used for development, not releases; something short, like
> > "master-v8" would yield concise, obvious aliases like
> > "master-v8-1234-abcdef01". (Tags on release branches are a
> > fundamentally different matter, and could continue looking exactly
> > like they do today.)
> 
> "master" could be confusing for downstream.  For example we have
a setup
> where our development happens on "master" and we have a branch
called
> "upstream_master" to pull from upstream.  It would be confusing
to see a
> tag called "master" on a branch not named "master."
Same here. Our "master" is not the upstream "master."
> 
> "v8.0.0-split/dev/branchpoint/whatever" could also be confusing
to
> downstream as it could conflict with downstream named tags if their
> products happen to have version number conflicts.  Follwing Duncan's
> suggestion, would llvm.org-8.0.0-split (or suggest some other suffix)
> work?  I know it's longer but it would be unambiguous.
> 
> "Duncan P. N. Exon Smith via llvm-dev" <llvm-dev at
lists.llvm.org> writes:
> 
> > I have a mild preference for "llvm.org-8.0.0" (instead of
> > "llvm-8.0.0"), since llvm.org is unambiguously a point of
origin,
> > whereas "llvm" could just refer to the content. E.g., some
downstreams
> > might package their product with the name "llvm".
> 
> I have a slight preference for that too, for the same reasons.
Works for me.  We actually put both the upstream and local versions into
our release-branch names because we could never keep them straight.
--paulr

On Thu, 13 Dec 2018 at 20:30, Hans Wennborg <hans at chromium.org> wrote:
> > On Thu, Dec 13, 2018 at 7:18 AM Alex Bradbury via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> >> v8.0.0-branchpoint might be even clearer, though obviously a
little longer.
>
> That suggests the tag is where we branched for 8.0.x though, but I
> think the idea is to put the tag at the version bump, right after the
> 7.0.x branch point. So I don't think branchpoint is a good name -- it
> seems we're already thinking it means different things :-)
Thanks for the catching that, you're right.

Best,

Alex