Re: [lldb-dev] [llvm-dev] [cfe-dev] Sequential ID Git hook

[Jim Rowan via lldb-dev]

On Jun 30, 2016, at 2:25 PM, Robinson, Paul via llvm-dev 
 wrote:

(talking about lots of tags)

> I don't know that it really scales well when you
> are talking about (long term) hundreds of thousands of them.

I can say from experience that it does not scale well.After some time, 
everyone would start feeling the pain.


Jim Rowan
j...@codeaurora.org
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by 
the Linux Foundation



___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Jim Rowan via lldb-dev]

On Jun 27, 2016, at 9:57 PM, Chris Lattner via llvm-dev 
 wrote:

> 
> I continue to think that 3.10 is the least defensible option out there.  

I agree, given that there isn’t a concurrent agreement that we want to define 
and conform to a semantic versioning scheme — and that agreement not only 
hasn’t happened but seems quite unlikely.

> We have a time based release process with no mechanism or attempt to align 
> behind “big” releases that could bring is to a 4.x number.  You might as well 
> call the release “10” at this point, since the "3.” will become archaic 
> legacy that we can’t shed.

Yes, that does seem likely.

> I still don’t understand what “confusion” could be caused by going from 3.9 
> to 4.0.  

I believe it is rooted in some folks expectation that the versions follow the 
semantic versioning paradigm.A numbering scheme that more directly 
indicated “time-based”, and that had less of a chance of being interpreted as 
conveying semantic content would indeed be less “confusing”.

> Could someone please elaborate on what the problem is that needs solving?  

I think the real point, mostly unspoken, is this expectation for semantic 
versioning.   Since that isn’t directly being discussed, I also don’t see a 
problem that needs solving.

Jim Rowan
j...@codeaurora.org
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by 
the Linux Foundation



___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

[Jim Rowan via lldb-dev]

+1

We use git exclusively within QC, so this looks like simplification to us.   
There was mention early in the thread of continuing to enforce linear history; 
that’s important to our internal integration machinery.   We do currently use 
the git-svn-id as a key for some of our internal processes, but it won’t be a 
problem to switch to something else.   

We use google repo to stitch together our build tree, so the submodule 
discussion is mostly a no-op for us (providing it ends up being the 
“llvm-project” flat tree implementation).

On Jun 1, 2016, at 1:51 PM, Matthias Braun via llvm-dev 
 wrote:

> So here's a straw-man proposal for a github migration:
> 
> 1. Register an official github project with the llvm foundation.
> 2. Setup another (read-only) mirror of llvm.org/git at this github project
> 3. Make sure we have ala llvm-project-submodules setup in the official 
> account. (Optional or necessary for the buildbots?) 
> 4. Update the buildbots to pick up updates and commits from the official git 
> repository
> 5. Update phabricator to pick up commits from the official git repository
> 6. Tell people living downstream to pick up commits from the official git 
> repository
> 7. Make sure bisecting with llvm-project-submodules is a good experience
> 8. Give things time to settle. We could play some games like disabling the 
> svn repository for a few hours on purpose so that people can test that their 
> infrastructure has really become independent of the svn repository.
> 9. Review and update llvm documentation.
> 10. Review website links pointing to viewvc/klaus/phab etc. to point to 
> github instead.
> ... Until this point nothing has changed for developers, it will just boil 
> down to a lot of work for buildbot and other infrstructure owners ...
> 11. Collect peoples github account information, give them push access. 
> Ideally while still locking the github repository somehow...
> 12. Switch svn repository to read-only and allow pushs to the github 
> repository.
> 13. Disable/remove/archive the svn repository.
> 
> - Matthias
> 
>> On Jun 1, 2016, at 11:31 AM, Mehdi Amini via llvm-dev 
>>  wrote:
>> 
>> 
>>> On Jun 1, 2016, at 11:18 AM, Renato Golin via llvm-dev 
>>>  wrote:
>>> 
>>> On 1 June 2016 at 17:02, John Criswell  wrote:
 Do you have a set of volunteers lined up to do such a migration? Getting
 people willing to do the migration will obviously be key, and that was the
 one thing I didn't see in the original email.
>>> 
>>> Hi John,
>>> 
>>> Well, first we need to know if people are in favour, then if the
>>> migration won't bring any serious problem, and then we can think of a
>>> migration plan. :)
>>> 
>>> So far, it seems people are mostly in favour, with a few that reported
>>> being locked into SVN. I had anticipated that, and have proposed
>>> GitHub's SVN integration, which allows read-write access, so it should
>>> be mostly ok. We need more tests on that side to be sure, though.
>>> 
>>> The biggest problem we're facing right now is how to sync the repos.
>>> The existing llvm-repos format with all projects as sub-modules seem
>>> to be a good candidate, but I still haven't seen a consensus on how
>>> we'd do that.
>>> 
>>> About the migration plan, most people seem to agree a step-by-step
>>> process is necessary.
>> 
>> I personnally disagree with that, see below.
>> 
>>> So, first we move to git-only, possibly with
>>> sub-modules
>> 
>> If you move to git-only without the rest of the infrastructure/scripts, 
>> we're losing the convenience we have today with svn, and the "user 
>> experience" will not be so great. We may face resistance to this change.
>> I advocate to first set it up till it reaches the point of "good enough" in 
>> term of usability before actually migrating.
>> 
>>> , then we move to GitHub/Lab/BB,
>> 
>> It means we first need to host our git, write the tooling around it, to then 
>> migrate to github. I don't see the benefit over migrating directly to 
>> github: if people have to change their configuration, better have one single 
>> change.
>> 
>>> then we move Phab to
>>> GitHub merge requests, etc.
>> 
>> Phab to GitHub merge requests is a totally separate discussion IMO, and this 
>> discussion can happen after a successful move.
>> 
>> 
>>> 
>>> Regarding volunteers, I haven't yet asked around yet, but I'm sure we
>>> have enough interested people to help. If everything else fails, I'm
>>> more than happy to do all of that myself. Though, I'd have to learn a
>>> lot more about sub-modules than I know today, which is effectively
>>> nothing. :)
>> 
>> I'll be happy to throw manpower into tooling/infrastructure to make it 
>> happen.
>> 
>> -- 
>> Mehdi
>> 
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
>