Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Renato Golin via lldb-dev]

On 27 June 2016 at 01:20, Matthias Braun  wrote:
> I really liked the the solution proposed earlier in this thread: Do nothing 
> server side, but instead use
> `git rev-list --count master` on the client side (which takes 0.9s on my 
> machine) to get the number of the commit. So nothing to do on the ID part IMO.

Mehdi replied to this proposal:

"it does not help to solve the cross-repository problem, we need a
"meta integration repository"."


> As for updating the meta repository: We could disable write access for the 
> normal llvm developer and delegate the submodule bumping to an external
> server. I believe this would be an easy enough job for buildbot or jenkins.

The plan is to disable all write access to this repository (otherwise
we'll create a nightmare). Having an external counter could be
problematic due to synchronisation issues.

If the hook doesn't work, we'll have serious problems.

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

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Rafael Espíndola via lldb-dev]

>> As for updating the meta repository: We could disable write access for the 
>> normal llvm developer and delegate the submodule bumping to an external
>> server. I believe this would be an easy enough job for buildbot or jenkins.
>
> The plan is to disable all write access to this repository (otherwise
> we'll create a nightmare). Having an external counter could be
> problematic due to synchronisation issues.
>
> If the hook doesn't work, we'll have serious problems.

So, I probably missed something, but what was the main objection to
just using submodules? This would put llvm inside clang instead of the
other way around. When changing an API one currently has to

* Change llvm.
* Quickly change clang and hope no bot picks up a revision with only
the llvm change.

With submodules it becomes

* Change llvm.
* Change clang and in the same atomic commit change what revision the
submodule points to.


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

Re: [lldb-dev] [cfe-dev] [llvm-dev] Git Move: GitHub+modules proposal

[James Y Knight via lldb-dev]

Two problems:
1) Submodules have some UX problems for developers around updating the
parent project and its effects on the submodule which make them annoying to
use.
2) I find the advantage you claim especially scary and bad. Put another
way: if a developer *doesn't* make a commit to clang with the new submodule
pointer, clang will not actually start using the new version of LLVM until
someone gets around to updating the pointer. Meaning, the next time anyone
*ELSE* goes to update the submodule pointer in clang, they would have to,
effectively, integrate all of the as-yet-untested-with-clang changes from
llvm, and fix any problems that might cause. I really don't think we want
that.

What I do think would be nice is a way to associate commits to llvm and
commits to clang as one unit that updates a parent repository. I've
mentioned before that gerrit seems to have that functionality.

I think it'd be a great idea to do some testing, and make a second proposal
centered around using Gerrit to manage commits to the github repository,
versus committing to github directly. I'm not sure if I'll have time to do
that properly, though.


On Mon, Jun 27, 2016 at 10:39 AM, Rafael Espíndola 
wrote:

> >> As for updating the meta repository: We could disable write access for
> the normal llvm developer and delegate the submodule bumping to an external
> >> server. I believe this would be an easy enough job for buildbot or
> jenkins.
> >
> > The plan is to disable all write access to this repository (otherwise
> > we'll create a nightmare). Having an external counter could be
> > problematic due to synchronisation issues.
> >
> > If the hook doesn't work, we'll have serious problems.
>
> So, I probably missed something, but what was the main objection to
> just using submodules? This would put llvm inside clang instead of the
> other way around. When changing an API one currently has to
>
> * Change llvm.
> * Quickly change clang and hope no bot picks up a revision with only
> the llvm change.
>
> With submodules it becomes
>
> * Change llvm.
> * Change clang and in the same atomic commit change what revision the
> submodule points to.
>
>
> Cheers,
> Rafael
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Renato Golin via lldb-dev]

On 27 June 2016 at 15:39, Rafael Espíndola  wrote:
> So, I probably missed something, but what was the main objection to
> just using submodules? This would put llvm inside clang instead of the
> other way around. When changing an API one currently has to

I don't think the consensus was to change the order of inclusion (llvm
into clang), but to *not* change anything else at this stage.

That's one of the reasons the umbrella project with sub-modules was
the most accepted solution, because we can later change the inclusion
order (if we all agree, etc), without changing the underlying storage.


> * Change llvm.
> * Change clang and in the same atomic commit change what revision the
> submodule points to.

Having one repository inside another was rejected due to the problems
it brings for development, validation and release. James has just
pointed a few of those problems for development.

An umbrella project with a commit hook and an auto-update would make
sure all commits are synchronised correctly. Though, indeed, this will
mean we'll still have the trouble of buildbots picking up one commit
and not the other, I don't think this is a big enough problem that we
should mess up everyone's workflow.

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

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

[Hans Wennborg via lldb-dev]

On Fri, Jun 24, 2016 at 5:55 PM, Saleem Abdulrasool
 wrote:
> On Fri, Jun 24, 2016 at 5:43 PM, Dmitri Gribenko via cfe-dev
>  wrote:
>>
>> On Fri, Jun 24, 2016 at 4:41 PM, Hans Wennborg via llvm-dev
>>  wrote:
>> > Richard suggested that since we do time-based rather than
>> > feature-based releases, the distinction between a release with or
>> > without major changes is arbitrary, and we should move to a scheme
>> > where we update the major version number on each release (4.0, 5.0,
>> > etc.) with minor releases in between (4.1, 5.1, ..).
>>
>> If we are truly committed to doing time-based releases, we can switch
>> to time-based version numbers, Year.Month, for example, if we were to
>> release in June it would be 16.06.  We can use an extra digit for
>> minor releases.
>
>
> This would mirror other projects doing the same, so there is precedent.
> Although radically different from the current model, I think it has some
> merit.  When people report bugs with 3.1, its actually hard to estimate how
> it is (roughly estimating it via ~6mo release cycle does really work).  This
> would certainly make it easier.
>
> Its a good alternative though it does mean that we no longer have the
> ability to indicate a major shift.  However as Chris already pointed out,
> LLVM is much more stable these days and perhaps worrying about major shifts
> which are unseen is looking for a problem to solve rather than solving a
> problem at hand.
>
> +1 on this suggestion.

I'm not a fan of this idea. While I can see the reasoning behind it, I
think we would end up with pretty confusing-looking version numbers. I
suppose it's too radically a departure from the usual schemes for my
taste.

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

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

[Hans Wennborg via lldb-dev]

On Sun, Jun 26, 2016 at 1:20 PM, Chandler Carruth via cfe-dev
 wrote:
> On Sun, Jun 26, 2016 at 10:01 AM Xinliang David Li via cfe-dev
>  wrote:
>>
>> I also believe this is the simplest versioning scheme*. It eliminates all
>> future debates on this topic (e.g, when to bump major version etc) and
>> solves the problem once and for all --  which is another plus :)
>
>
> Except that we'll have to keep dealing with people who are confused why we
> have two version numbers but they don't mean anything. That's why I think if
> we don't want major/minor going forward, we should remove the '.' regardless
> of what number we pick.

We can't remove the '.' completely though, as we need it for Tom's
stable releases.

That's what concerns me about going to the scheme Richard and Rafael
suggested, of bumping the major version each time: we'd release 4.0,
and would Tom's dot-release then be 4.1? That would be confusing to
those who are used to our current scheme. Chris suggested going
straight to 40 to avoid this, but that also seems a bit extreme.

Thanks,
Hans


>> On Sun, Jun 26, 2016 at 7:21 AM, Reid Kleckner via cfe-dev
>>  wrote:
>>>
>>> I also support Chris's position of 4.0, 4.1 etc. I don't think
>>> "majorness" is that important, and we can sort out the bit code
>>> compatibility story some other way.
>>>
>>> Sent from phone
>>>
>>> On Jun 24, 2016 4:42 PM, "Hans Wennborg via llvm-dev"
>>>  wrote:

 On Mon, Jun 13, 2016 at 4:54 PM, Hans Wennborg 
 wrote:
 > Breaking this out into a separate thread since it's kind of a separate
 > issue, and to make sure people see it.
 >
 > If you have opinions on this, please chime in. I'd like to collect as
 > many arguments here as possible to make a good decision. The main
 > contestants are 4.0 and 3.10, and I've seen folks being equally
 > surprised by both.

 Thanks everyone for chiming in.

 Please correct me if I misrepresent your opinion here, but I need to
 try and summarize this thread for my own sanity:

 The thread started out with lots of support for 3.10, the reasoning
 being roughly that we shouldn't bump the major version number unless
 we want to signify major change (Mehdi, Hal, Blaikie, Saleem,
 Chandler, Anton, Eric, Aaron, Sean, Vikram).

 Richard suggested that since we do time-based rather than
 feature-based releases, the distinction between a release with or
 without major changes is arbitrary, and we should move to a scheme
 where we update the major version number on each release (4.0, 5.0,
 etc.) with minor releases in between (4.1, 5.1, ..).

 Chris advocated for "keep adding 0.1 to each major release" (in the
 decimal sense), i.e. 3.9, 4.0, 4.1, etc. I haven't seen anyone else
 suggest this. "I do not think it is reasonable at all to go to '3.10'
 after '3.9', because we will never get to '4.0'."

 Chris then expressed support for alternatively just incrementing the
 major version each time, as Richard suggested, but starting at 40.

 Rafael expressed support for the above, but starting at 4.0: "It is
 simply not worth the time to try to figure out what is 'major' in a
 project with so many different uses."

 Chandler said he didn't like Chris's "keep adding 0.1 to each major
 release" scheme: "we shouldn't just go from 3.9 to 4.0 because of some
 decimal correspondence", and said he was open to either going to 3.10
 with the current major/minor split, or if we don't want that, use
 Richard's suggestion.

 Michael pointed out that if we do change the numbering scheme,
 changing the binary compatibility guarantee to something time-based
 isn't equivalent to what we currently have.



 So, it seems we're at an impasse with several folks in favour of 3.10,
 Chris speaking out strongly against it, and Richard's option which has
 some traction and which no one's disagreed with so far, but which
 would be a bigger change.

 I'll have a think about this over the weekend.

 Cheers,
 Hans
 ___
 LLVM Developers mailing list
 llvm-...@lists.llvm.org
 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>> ___
>>> cfe-dev mailing list
>>> cfe-...@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>
>> ___
>> cfe-dev mailing list
>> cfe-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Rafael Espíndola via lldb-dev]

I think that trying to create a ordering/rev number between independent git
repositories is fundamentally unreliable.

If we want to keep llvm and clang in lock step we should probably probably
just have them in the same repository like
https://github.com/llvm-project/llvm-project.

Cheers,
Rafael
On Jun 27, 2016 11:10 AM, "Renato Golin"  wrote:

> On 27 June 2016 at 15:39, Rafael Espíndola 
> wrote:
> > So, I probably missed something, but what was the main objection to
> > just using submodules? This would put llvm inside clang instead of the
> > other way around. When changing an API one currently has to
>
> I don't think the consensus was to change the order of inclusion (llvm
> into clang), but to *not* change anything else at this stage.
>
> That's one of the reasons the umbrella project with sub-modules was
> the most accepted solution, because we can later change the inclusion
> order (if we all agree, etc), without changing the underlying storage.
>
>
> > * Change llvm.
> > * Change clang and in the same atomic commit change what revision the
> > submodule points to.
>
> Having one repository inside another was rejected due to the problems
> it brings for development, validation and release. James has just
> pointed a few of those problems for development.
>
> An umbrella project with a commit hook and an auto-update would make
> sure all commits are synchronised correctly. Though, indeed, this will
> mean we'll still have the trouble of buildbots picking up one commit
> and not the other, I don't think this is a big enough problem that we
> should mess up everyone's workflow.
>
> cheers,
> --renato
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Alexey Denisov via lldb-dev]

Hello there,

Renato, thank you for putting everything together.

Talking about second question (commits mailing list): github provides set
of various web hooks. I think here we are interested
In 'push'es particularly.

Besides that it has some CI related integrations: buildbots can update pull
request status to show if tests are passing or not. The builds can be also
triggered using web hooks (issue_comment with specific text). IIRC swift
and rust do this (and more) in a very similar way.

Cheers,
Alex.

[1] https://developer.github.com/webhooks


On Sunday, 26 June 2016, Renato Golin via llvm-dev 
wrote:

> So,
>
> It's been a while and the GitHub thread is officially dead, so I'll
> propose a development methodology based on the feedback from that
> thread. This is not *my* view, but all that was discussed in the
> threads.
>
> My objective is to form an official proposal to use Git as our main
> repository, overcoming all the problems we currently have without
> creating many others. In the end, I think Tanya wanted to make a vote,
> and see how string the community feels about it. The vote should be
> "Should we move to GitHub as the proposed workflow, or should we try
> to find another solution away from our own hosting?".
>
> The important part is that we *must* move from the current schema. It
> does not scale and the administrative costs are not worth the trouble.
> So, if we don't go with GitHub, we have to find another way out.
>
> The proposal
> ==
>
> Move to GitHub with N+1 projects: all current LLVM projects + the
> "llvm-projs" umbrella. The latter will have all other projects as
> "submodules" with the intent to:
>
>  1. Control the history via server hooks updating a unique and
> auto-increment identifier, which will apply to every commit on its
> submodules (ie, every other LLVM project).
>  2. Serve as a reference for releases, buildbots, etc., checking out
> only the necessary submodules for each.
>  3. Have additional logic to handle the additional complexity for
> mailing lists, tools, buildbots to deal with the umbrella project
> *only*.
>
> The existing LLVM projects (llvm, clang, compiler-rt, etc) will
> continue on their own repositories and be built locally just like they
> are today. You can check them out individually inside the final
> directory (llvm/tools/clang) or use symbolic links, just like we do
> today. You can also checkout "llvm-projs" and update only the required
> submodules, and use symbolic links.
>
> The llvm-projs umbrella will have its own versioning, and tools can
> report that ID as their "version", if they're not in a release branch.
>
> Release branches should be off of master and have a linear history,
> just like master, in the exact same way we do now with SVN. This will
> guarantee the umbrella project will be able to correctly
> auto-increment the ID and make sure current tools work as usual.
>
> We don't want private branches to end up in upstream LLVM (only
> upstream release branches), but that's perfectly natural in GitHub,
> where anyone can fork and implement their features and own releases
> off of the upstream official repositories.
>
> This can work as well for upstream development of "feature branches",
> where upstream developers contribute to both repositories, but keeping
> a specific feature in test separate. Merges will still have to be like
> it is today, one patch at a time, or risk reverting the whole merge
> window if the buildbots start breaking, which can be impossible if the
> window is large or two or more windows get committed at the same time.
>
> For "feature branches" we could use git-imerge, but that's for the
> future and not considered in the first stage of the move.
>
> Git Submodules
> -
>
> There were concerns is submodules would work with our flow, but the
> concerns were addressed by demonstrating that:
>
>  1. Submodules can work in an umbrella project, which controls the
> auto-increment ID
>  2. You can check-out individual modules or all, so work well for
> releases and buildbots
>  3. The history is shared with the root project, so git-bisect works
> out of the box
>
> The Alternatives
> -
>
> A few alternatives were proposed, but git submodules ended up being
> considered more thoroughly. Here are some of the reasons:
>
>  * Google repo:
>
> It's an independent tool, which may suite us today, but not
> necessarily tomorrow. It may work well with the infrastructure that is
> already set for it on other projects (mostly Google projects like
> Android), but it does require some tooling (like git submodules). The
> point is, that it's much more likely to exist tooling for official git
> features than third-party projects, especially on Windows.
>
>  * All-in-one:
>
> Proposals to have all projects inside one big repo were quickly
> dismissed due to the problems it creates to *users* of LLVM as a
> library, and to build

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Renato Golin via lldb-dev]

On 27 June 2016 at 17:03, Rafael Espíndola  wrote:
> I think that trying to create a ordering/rev number between independent git
> repositories is fundamentally unreliable.
>
> If we want to keep llvm and clang in lock step we should probably probably
> just have them in the same repository like
> https://github.com/llvm-project/llvm-project.

That is similar to the proposal we have, except that llvm-projects
will have sub-modules.

Having all of them in the same physical repository is a big problems
for those that only use a small subset of the components, which is the
vast majority of users, most of the time (all buildbots, Jenkins,
local development, downstream users, even releases don't clone all
repos).

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

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

[Xinliang David Li via lldb-dev]

Stable release can use a different numbering space -- a,b,c,d. 4.1a
means the first patch release of 4.1 release, etc.

David

On Mon, Jun 27, 2016 at 8:26 AM, Hans Wennborg  wrote:

> On Sun, Jun 26, 2016 at 1:20 PM, Chandler Carruth via cfe-dev
>  wrote:
> > On Sun, Jun 26, 2016 at 10:01 AM Xinliang David Li via cfe-dev
> >  wrote:
> >>
> >> I also believe this is the simplest versioning scheme*. It eliminates
> all
> >> future debates on this topic (e.g, when to bump major version etc) and
> >> solves the problem once and for all --  which is another plus :)
> >
> >
> > Except that we'll have to keep dealing with people who are confused why
> we
> > have two version numbers but they don't mean anything. That's why I
> think if
> > we don't want major/minor going forward, we should remove the '.'
> regardless
> > of what number we pick.
>
> We can't remove the '.' completely though, as we need it for Tom's
> stable releases.
>
> That's what concerns me about going to the scheme Richard and Rafael
> suggested, of bumping the major version each time: we'd release 4.0,
> and would Tom's dot-release then be 4.1? That would be confusing to
> those who are used to our current scheme. Chris suggested going
> straight to 40 to avoid this, but that also seems a bit extreme.
>
> Thanks,
> Hans
>
>
> >> On Sun, Jun 26, 2016 at 7:21 AM, Reid Kleckner via cfe-dev
> >>  wrote:
> >>>
> >>> I also support Chris's position of 4.0, 4.1 etc. I don't think
> >>> "majorness" is that important, and we can sort out the bit code
> >>> compatibility story some other way.
> >>>
> >>> Sent from phone
> >>>
> >>> On Jun 24, 2016 4:42 PM, "Hans Wennborg via llvm-dev"
> >>>  wrote:
> 
>  On Mon, Jun 13, 2016 at 4:54 PM, Hans Wennborg 
>  wrote:
>  > Breaking this out into a separate thread since it's kind of a
> separate
>  > issue, and to make sure people see it.
>  >
>  > If you have opinions on this, please chime in. I'd like to collect
> as
>  > many arguments here as possible to make a good decision. The main
>  > contestants are 4.0 and 3.10, and I've seen folks being equally
>  > surprised by both.
> 
>  Thanks everyone for chiming in.
> 
>  Please correct me if I misrepresent your opinion here, but I need to
>  try and summarize this thread for my own sanity:
> 
>  The thread started out with lots of support for 3.10, the reasoning
>  being roughly that we shouldn't bump the major version number unless
>  we want to signify major change (Mehdi, Hal, Blaikie, Saleem,
>  Chandler, Anton, Eric, Aaron, Sean, Vikram).
> 
>  Richard suggested that since we do time-based rather than
>  feature-based releases, the distinction between a release with or
>  without major changes is arbitrary, and we should move to a scheme
>  where we update the major version number on each release (4.0, 5.0,
>  etc.) with minor releases in between (4.1, 5.1, ..).
> 
>  Chris advocated for "keep adding 0.1 to each major release" (in the
>  decimal sense), i.e. 3.9, 4.0, 4.1, etc. I haven't seen anyone else
>  suggest this. "I do not think it is reasonable at all to go to '3.10'
>  after '3.9', because we will never get to '4.0'."
> 
>  Chris then expressed support for alternatively just incrementing the
>  major version each time, as Richard suggested, but starting at 40.
> 
>  Rafael expressed support for the above, but starting at 4.0: "It is
>  simply not worth the time to try to figure out what is 'major' in a
>  project with so many different uses."
> 
>  Chandler said he didn't like Chris's "keep adding 0.1 to each major
>  release" scheme: "we shouldn't just go from 3.9 to 4.0 because of some
>  decimal correspondence", and said he was open to either going to 3.10
>  with the current major/minor split, or if we don't want that, use
>  Richard's suggestion.
> 
>  Michael pointed out that if we do change the numbering scheme,
>  changing the binary compatibility guarantee to something time-based
>  isn't equivalent to what we currently have.
> 
> 
> 
>  So, it seems we're at an impasse with several folks in favour of 3.10,
>  Chris speaking out strongly against it, and Richard's option which has
>  some traction and which no one's disagreed with so far, but which
>  would be a bigger change.
> 
>  I'll have a think about this over the weekend.
> 
>  Cheers,
>  Hans
>  ___
>  LLVM Developers mailing list
>  llvm-...@lists.llvm.org
>  http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>>
> >>>
> >>> ___
> >>> cfe-dev mailing list
> >>> cfe-...@lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >>>
> >>
> >> ___
> >> cfe-dev mailing

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

[Chris Lattner via lldb-dev]

On Jun 27, 2016, at 8:26 AM, Hans Wennborg via llvm-dev 
 wrote:
> That's what concerns me about going to the scheme Richard and Rafael
> suggested, of bumping the major version each time: we'd release 4.0,
> and would Tom's dot-release then be 4.1? That would be confusing to
> those who are used to our current scheme. Chris suggested going
> straight to 40 to avoid this, but that also seems a bit extreme.

Extreme how?  What do you mean by “extreme"?

-Chris
___
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)

[Hans Wennborg via lldb-dev]

On Mon, Jun 27, 2016 at 3:29 PM, Chris Lattner  wrote:
> On Jun 27, 2016, at 8:26 AM, Hans Wennborg via llvm-dev 
>  wrote:
>> That's what concerns me about going to the scheme Richard and Rafael
>> suggested, of bumping the major version each time: we'd release 4.0,
>> and would Tom's dot-release then be 4.1? That would be confusing to
>> those who are used to our current scheme. Chris suggested going
>> straight to 40 to avoid this, but that also seems a bit extreme.
>
> Extreme how?  What do you mean by “extreme"?

Sorry, that might have been a poor choice of wording.

I just meant that change seems to have a much greater magnitude than
the other proposals. I realize that's sort of the point, to make the
change clear to users, but instinctively it feels wrong -- like
cheating by skipping 36 versions :-)

Thanks,
Hans
___
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)

[Chandler Carruth via lldb-dev]

On Mon, Jun 27, 2016 at 3:38 PM Hans Wennborg via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> On Mon, Jun 27, 2016 at 3:29 PM, Chris Lattner  wrote:
> > On Jun 27, 2016, at 8:26 AM, Hans Wennborg via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
> >> That's what concerns me about going to the scheme Richard and Rafael
> >> suggested, of bumping the major version each time: we'd release 4.0,
> >> and would Tom's dot-release then be 4.1? That would be confusing to
> >> those who are used to our current scheme. Chris suggested going
> >> straight to 40 to avoid this, but that also seems a bit extreme.
> >
> > Extreme how?  What do you mean by “extreme"?
>
> Sorry, that might have been a poor choice of wording.
>
> I just meant that change seems to have a much greater magnitude than
> the other proposals. I realize that's sort of the point, to make the
> change clear to users, but instinctively it feels wrong -- like
> cheating by skipping 36 versions :-)
>

Eh, if we're switching to a completely unrelated versioning scheme, it
doesn't seem completely unreasonable.

We could also count how many time-based releases we have had and use that...

:: shrug ::

I think counting from 4 or counting from 40 are all fine ways to number
releases.


>
> Thanks,
> Hans
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
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)

[Hans Wennborg via lldb-dev]

On Mon, Jun 27, 2016 at 3:40 PM, Chandler Carruth  wrote:
> On Mon, Jun 27, 2016 at 3:38 PM Hans Wennborg via lldb-dev
>  wrote:
>>
>> On Mon, Jun 27, 2016 at 3:29 PM, Chris Lattner  wrote:
>> > On Jun 27, 2016, at 8:26 AM, Hans Wennborg via llvm-dev
>> >  wrote:
>> >> That's what concerns me about going to the scheme Richard and Rafael
>> >> suggested, of bumping the major version each time: we'd release 4.0,
>> >> and would Tom's dot-release then be 4.1? That would be confusing to
>> >> those who are used to our current scheme. Chris suggested going
>> >> straight to 40 to avoid this, but that also seems a bit extreme.
>> >
>> > Extreme how?  What do you mean by “extreme"?
>>
>> Sorry, that might have been a poor choice of wording.
>>
>> I just meant that change seems to have a much greater magnitude than
>> the other proposals. I realize that's sort of the point, to make the
>> change clear to users, but instinctively it feels wrong -- like
>> cheating by skipping 36 versions :-)
>
>
> Eh, if we're switching to a completely unrelated versioning scheme, it
> doesn't seem completely unreasonable.
>
> We could also count how many time-based releases we have had and use that...
>
> :: shrug ::
>
> I think counting from 4 or counting from 40 are all fine ways to number
> releases.


This is what I arrived at after my weekend of thinking about version numbers:

While there's been many good arguments for doing something different
and revising our versioning scheme, I really just want to bump the
number with the least amount of work possible.

When we branch for 3.9, my plan is to bump trunk to 3.10, and then
focus my attention on getting 3.9 into a good state and shipping it.

After the branch, if someone wants to promote trunk to 4.0 because of
a feature, or because the 3-series is "done", go ahead. If someone
wants to spearhead getting us onto a scheme where we increment major
for each release, that's fine too, but I'm not going to drive it.

Thanks everyone for participating in the discussion. Hopefully this
result is not too disappointing.

Cheers,
Hans
___
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)

[Chris Lattner via lldb-dev]

On Jun 27, 2016, at 4:57 PM, Hans Wennborg  wrote:
>> Eh, if we're switching to a completely unrelated versioning scheme, it
>> doesn't seem completely unreasonable.
>> 
>> We could also count how many time-based releases we have had and use that...
>> 
>> :: shrug ::
>> 
>> I think counting from 4 or counting from 40 are all fine ways to number
>> releases.
> 
> 
> This is what I arrived at after my weekend of thinking about version numbers:
> 
> While there's been many good arguments for doing something different
> and revising our versioning scheme, I really just want to bump the
> number with the least amount of work possible.
> 
> When we branch for 3.9, my plan is to bump trunk to 3.10, and then
> focus my attention on getting 3.9 into a good state and shipping it.
> 
> After the branch, if someone wants to promote trunk to 4.0 because of
> a feature, or because the 3-series is "done", go ahead. If someone
> wants to spearhead getting us onto a scheme where we increment major
> for each release, that's fine too, but I'm not going to drive it.
> 
> Thanks everyone for participating in the discussion. Hopefully this
> result is not too disappointing.

I continue to think that 3.10 is the least defensible option out there.  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.

Trust me, I’ve seen this happen several times in the past in multiple different 
products (both open source and proprietary), and have had success leading one 
to a more predictable release number pattern like I’m advocating for.  This is 
a problem that we are simply walking into by naming it 3.10, there is no reason 
to do that.

I still don’t understand what “confusion” could be caused by going from 3.9 to 
4.0.  Could someone please elaborate on what the problem is that needs solving? 
 If it is that people don’t understand what is major about the release, I would 
say “who cares”?  

-Chris
___
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

[lldb-dev] Problem of building lldb on Mac

[Jeffrey Tan via lldb-dev]

Hi,

I followed instructions in http://lldb.llvm.org/build.html to build lldb on
Mac.

I opened "*lldb/lldb.xcworkspace*" in Xcode7.3.1, select lldb-tools scheme
and build, I always got build error below. I have tried "brew install
cmake" but the installed cmake version does not match what build script is
looking for.

*Questions:*
Do I suppose to find and download 3.1.2 version of cmake to get this
working? Do I miss anything? Thanks.

...

/bin/sh -c
/Users/jeffreytan/Library/Developer/Xcode/DerivedData/lldb-acenblzastrxbocknmwzltsmlasq/Build/Intermediates/lldb.build/DebugClang/lldb-core.build/Script-261EECA21337D399001D193C.sh


[0/1] Re-running CMake...

/bin/sh: /usr/local/Cellar/cmake/3.1.2/bin/cmake: No such file or directory

FAILED: build.ninja

/usr/local/Cellar/cmake/3.1.2/bin/cmake -H/Users/jeffreytan/local/lldb/llvm
-B/Users/jeffreytan/local/lldb/llvm-build/Debug+Asserts/x86_64

ninja: error: rebuilding 'build.ninja': subcommand failed

Traceback (most recent call last):

  File "/Users/jeffreytan/local/lldb/scripts/Xcode/build-llvm.py", line
340, in 

build_llvm_if_needed()

  File "/Users/jeffreytan/local/lldb/scripts/Xcode/build-llvm.py", line
334, in build_llvm_if_needed

build_llvm(ninja_binary_path)

  File "/Users/jeffreytan/local/lldb/scripts/Xcode/build-llvm.py", line
328, in build_llvm

subprocess.check_call([ninja_binary_path], cwd=cmake_build_dir,
env=cmake_environment())

  File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py",
line 540, in check_call

raise CalledProcessError(retcode, cmd)

subprocess.CalledProcessError: Command
'['/Users/jeffreytan/local/lldb/ninja/ninja']' returned non-zero exit
status 1
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[NAKAMURA Takumi via lldb-dev]

It has also submodules.
https://github.com/llvm-project/llvm-project-submodule

Both llvm-project(-tree) and (-submodule) have refs/notes/commits.

On Tue, Jun 28, 2016 at 1:13 AM Renato Golin via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> On 27 June 2016 at 17:03, Rafael Espíndola 
> wrote:
> > I think that trying to create a ordering/rev number between independent
> git
> > repositories is fundamentally unreliable.
> >
> > If we want to keep llvm and clang in lock step we should probably
> probably
> > just have them in the same repository like
> > https://github.com/llvm-project/llvm-project.
>
> That is similar to the proposal we have, except that llvm-projects
> will have sub-modules.
>
> Having all of them in the same physical repository is a big problems
> for those that only use a small subset of the components, which is the
> vast majority of users, most of the time (all buildbots, Jenkins,
> local development, downstream users, even releases don't clone all
> repos).
>
> cheers,
> --renato
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev