llvm dev - Jan 2019 - New LLVM git repository conversion prototype

On 12/18/2018 08:01 PM, Bruce Hoult wrote:
> On Tue, Dec 18, 2018 at 4:13 PM Tom Stellard via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 
>     There haven't been many more responses in the last few days, so can
we
>     try to come to some kind of consensus here?
> 
> 
> Can we please just get the repo up? I've been waiting two months since
it was promised, told bosses I'd have a permanent git repo of llvm up where
the hashes were never going to change under people again etc.
> 
> The remaining discussion seems to be about tags and branch names. Neither
of those changes hashes of commits or trees or blobs. Both can be fiddled with
after the fact without affecting anything else.
> 
Yes, I agree with you that we need to move forward.  I think enough people have
given
input that I'm personally fine if James just wants to make a final decision
based
on the responses so far.
> 
>     1. Release tags.  There were a lot of small variation on the tag names
for releases,
>     but it seems like the preferences was to use the llvm.org
<http://llvm.org> prefix,
>     so I'm going to propose using tag names like:
> 
>     llvm.org-8.0.0
>     llvm.org-8.0.0-rc1
> 
> 
> Fine.
>  
> 
>     2. Tags for commits in the master branch that bump the release version.
> 
>     Most of the discussion about this so far has been on what to put after
>     the version number (e.g. v8.0.0-dev, v8.0.0-base, v8.0.0-branchpoint).
>     Other things to consider about this tag is that it might be used in
>     a git describe alias to identify commits, so it would be helpful if
>     it was short.
> 
>     One idea I had after reading through all the responses was to use the
>     -git suffix on the tags. e.g. v8.0.0-git.  It's short and it's
clear
>     that you are getting something that isn't an official release.  It
>     also is similar to the 8.0.0svn version number that we currently use
>     to indicate a non-released version.  Which of these 4 options(
>     dev, base, branchpoint, git) do people prefer?
> 
> 
> Any. Even keeping 8.0.0svn would make some tools simpler.
> 
>  
> 
>     3. Branch names:
> 
>     It seems like there is some preference to include the minor version
number
>     in the release branch, so any strong objections to using
>     release/7.0.x as the branch naming?
> 
> 
> Actually, I do object to that.
> 
> A release branch is something that doesn't get any new features, only
bug/security fixes. When you start along the release/7.0 branch you will find
tags for 7.0.1, 7.0.2 etc but it remains the 7.0 *branch*.
> 
Are you suggesting release/7.0 instead of release/7.0.x?  If so, I agree.
> Also: is that .0 *ever* again going to be incremented? Not as far as I
know. It probably should have been dropped at release/4
> 
I am planning to do a 7.1.0 release due to a bug fix that breaks the ABI.

-Tom
> Also: I haven't seen anyone bike-shedding whether the tags should be
annotated tags or lightweight tags. I don't think that's because
everyone knows the difference and implicitly agrees on the answer :-) :-)
> 
> The answer (in any public repo, really) should be annotated tags, so they
include the committer name and the date.
>

On 12/19/18 8:28 AM, Tom Stellard via llvm-dev wrote:
 > On 12/18/2018 08:01 PM, Bruce Hoult wrote:
 >> On Tue, Dec 18, 2018 at 4:13 PM Tom Stellard via llvm-dev 
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
wrote:
 >>
 >>     There haven't been many more responses in the last few days,
so
can we
 >>     try to come to some kind of consensus here?
 >>
 >> Can we please just get the repo up? I've been waiting two months 
since it was promised, told bosses I'd have a permanent git repo of llvm 
up where the hashes were never going to change under people again etc.
 >>
 >> The remaining discussion seems to be about tags and branch names. 
Neither of those changes hashes of commits or trees or blobs. Both can 
be fiddled with after the fact without affecting anything else.
 >>
 >
 > Yes, I agree with you that we need to move forward.  I think enough 
people have given
 > input that I'm personally fine if James just wants to make a final 
decision based
 > on the responses so far.
Yes, please!! :)

 >
 >> Also: is that .0 *ever* again going to be incremented? Not as far as 
I know. It probably should have been dropped at release/4
 >>
 >
 > I am planning to do a 7.1.0 release due to a bug fix that breaks the ABI.
Is there going to be a parallel development of 7.1.x and 7.0.x?
Thats the only reason for doing (separate) branches.

regards,
   Fedor.

It's 2019, so time to bump this up.

The tagging question has been pretty clearly stated to not destroy the
commitish so we don't need that to be 100% perfect, and it seems like there
is a pretty solid starting point.

I had asked James to move the tagging of svn revision to follow the
conventions around git "trailers"[1]. That should be super mechanical
and
not a big deal.

James, can we get this rebuilt with the trailer change, initial tagging /
branching pattern, and rebuild into the official location? I would really
like to be able to announce that we have an official github mirror next
week and tell people to start using it. That will also make sure we can
reference it in the release announcement, etc.

I'm available any time this week to help w/ the github project and any
administration issues. (Or Tom can.)

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190102/a248cf1c/attachment-0001.html>

Sorry for the delay -- I was hoping to get this email sent out _before_
going *poof* for the holidays, but did not quite manage.

I've created a new conversion, at same url <
https://github.com/llvm-git-prototype>. The tree hashes are all the same as
before -- only the commit hashes have changed.

If no more objections, I propose the next step is to call it final, and
move that set of repositories over to <https://github.com/llvm/>.

The changes since last time:
- Changed "llvm-svn" trailer -- it's now in git trailer format,
"llvm-svn:
1234" instead of "llvm-svn=1234". If there are existing git
trailers, it's
added to the existing trailers. Generally there aren't, because,
unfortunately phabricator doesn't use git trailer formatting.
- The <https://github.com/llvm-git-prototype/llvm> repository has had most
of the branches removed, for convenience. Only the release branches and
tags remain. The others are all still available in <
https://github.com/llvm-git-prototype/llvm-legacy-branches>.
- The release branches and tags have been given nicer names. I ended up
choosing "llvmorg-7.0.1-rc1" for the tags, and "release/7.x"
for the
branches. I haven't done anything about the proposed branch-point tags yet
-- they can be added in the future.

On Wed, Jan 2, 2019 at 8:57 PM Chandler Carruth <chandlerc at gmail.com>
wrote:
> It's 2019, so time to bump this up.
>
> The tagging question has been pretty clearly stated to not destroy the
> commitish so we don't need that to be 100% perfect, and it seems like
there
> is a pretty solid starting point.
>
> I had asked James to move the tagging of svn revision to follow the
> conventions around git "trailers"[1]. That should be super
mechanical and
> not a big deal.
>
> James, can we get this rebuilt with the trailer change, initial tagging /
> branching pattern, and rebuild into the official location? I would really
> like to be able to announce that we have an official github mirror next
> week and tell people to start using it. That will also make sure we can
> reference it in the release announcement, etc.
>
> I'm available any time this week to help w/ the github project and any
> administration issues. (Or Tom can.)
>
> -Chandler
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190103/3efc242d/attachment.html>