[lldb-dev] Stopping "stop reason = exec"

[Chris Lattner via lldb-dev]

Hi all,

Is there anything I can put into my lldb init script to prevent LLDB from 
stopping on exec?  Every time I run a program I get this super irritating 
behavior:

Thanks for any help!

-Chris


Process 20310 launched: 
'/Users/clattner/Projects/build/Xcode-ReleaseAssert+swift-DebugAssert/swift-macosx-x86_64/Debug/bin/swift'
 (x86_64)
Process 20310 stopped
* thread #2, stop reason = exec
frame #0: 0x00010984f000 dyld`_dyld_start
dyld`_dyld_start:
->  0x10984f000 <+0>: popq   %rdi
0x10984f001 <+1>: pushq  $0x0
0x10984f003 <+3>: movq   %rsp, %rbp
0x10984f006 <+6>: andq   $-0x10, %rsp
Target 0: (swift) stopped.
(lldb)
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Moderating lldb-dev/lldb-commits mailing lists

[Chris Lattner via lldb-dev]

Hi All,

I’ve been moderating the lldb mailing list for a very long time now, but I 
don’t think it makes sense for me to continue.  Is there anyone interested in 
taking over this (important to the community) responsibility?  Thanks!

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

Re: [lldb-dev] Code ownership resignation

[Chris Lattner via lldb-dev]

On Nov 16, 2016, at 3:55 PM, Enrico Granata via lldb-dev 
 wrote:
> I would recommend that the community consider Jim Ingham for taking over data 
> formatters. He is already code owner for Objective-C runtime and ValueObject.
> I'd like to recommend that the remaining part of Value* (Value.h/Value.cpp) 
> go to Greg Clayton.
> 
> Zachary Turner has done a lot of great work on our test suite infrastructure, 
> and I am confident that the community would be well served by having him 
> serve as code owner for that portion of the project going forward.
> 
These all make sense to me.  Assuming no objections in the next 24 hours, Jim, 
Greg, and Zachary, please update the CODE_OWNERS file, congrats!

Thank you for all your contributions to LLDB Enrico!

-Chris

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

Re: [lldb-dev] Final Result - GitHub Survey

[Chris Lattner via lldb-dev]

On Nov 9, 2016, at 2:53 AM, Renato Golin via lldb-dev  
wrote:
> Folks,
> It's been one week after the initial results were shared and three
> days after the last answer, so I think it's time to close down and
> publish the final results.
> 
> The ODF, XLS and CSV files are at:
> 
> http://people.linaro.org/~renato.golin/LLVM%20Move%20to%20GitHub.zip
> 
> The overall result is the same, and it's still in sync with what was
> discussed on the BoF session and I reported back last week:
> 
> GitHub, not only Git, still has a massive support and the split
> between mono/multi repo still exists and need to be sorted out.

Thanks Renato!

Per the extensive discussion on the list and at the Developer Meeting, it seems 
clear that GitHub is the path forward for LLVM.  We still need to resolve 
exactly what that means (mono vs multirepo, etc), but we should take it for 
granted that we’re moving to github.  This will simplify the design space, and 
help focus the discussion.

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

[lldb-dev] Relicensing discussion @ llvm-dev

[Chris Lattner via lldb-dev]

Hi LLDB folks,

FYI, I kicked off a thread about relicensing on LLVM.  It impacts LLDB as well, 
but it would be great to keep the discussion centralized on one list:
http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html

-Chris

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

Re: [lldb-dev] LLDB Evolution

[Chris Lattner via lldb-dev]

> On Aug 26, 2016, at 6:12 PM, Zachary Turner via lldb-dev 
>  wrote:
> 
> Back to the formatting issue, there's a lot of code that's going to look bad 
> after the reformat, because we have some DEEPLY indented code.  LLVM has 
> adopted the early return model for this reason.  A huge amount of our deeply 
> nested code could be solved by using early returns. 

FWIW, early returns are part of the LLVM Coding standard:
http://llvm.org/docs/CodingStandards.html#use-early-exits-and-continue-to-simplify-code
 


So it makes sense for LLDB to adopt this approach at some point.

I don’t have an opinion about whether it happens before or after the "big 
reformat", but I guess I agree with your point that doing it would be good to 
do it for the most egregious cases before the reformat.

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

Re: [lldb-dev] LLDB Evolution

[Chris Lattner via lldb-dev]

> On Aug 15, 2016, at 8:50 AM, David Jones via lldb-dev 
>  wrote:
> 
> On Mon, Aug 15, 2016 at 2:36 AM, Pavel Labath via lldb-dev 
> > wrote:
> I've sampled the python code from the llvm repository, and it seems to
> be using a mixture of 4-, 2-, and even 8- character indent, with 4
> being the most prevalent. So, I think we can safely stay with status
> quo.
> 
> 
> (Comment from the peanut gallery...)
> 
> Python does have a language-level style guide (PEP-8):
> 
> https://www.python.org/dev/peps/pep-0008/ 
> 
> 
> If code is going to be reformatted, then it may be best to try to converge on 
> exactly the PEP-8 style. Speaking as a project "outsider" (i.e., not an 
> active contributor), but someone with Python background, anything that 
> diverges from standard Python style seems jarring (at least to me).

Also from the peanut gallery, but +1 for standardizing python code on the PEP-8 
standards.

-Chris

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

Re: [lldb-dev] LLDB Evolution

[Chris Lattner via lldb-dev]

> On Aug 11, 2016, at 3:40 PM, Zachary Turner via lldb-dev 
>  wrote:
> 
> 
> On Thu, Aug 11, 2016 at 3:28 PM Greg Clayton  > wrote:
> 
> > -  Will we stop putting m_ at the front of class ivars and g_ at 
> > the front of globals?
> 
> I believe these make things much clearer and I would love to see llvm and 
> clang adopt some way to identify member variables. "m_" might be too long, 
> but at least a leading "_" would be nice. I don't think there is anything in 
> the LLVM coding conventions that mentions how to name member variables is 
> there?
> Unfortunately there is.  The LLVM rule is: everything is camel case.  member 
> variables, local variables, global variables, it's all the same.  And that 
> also means you can't distinguish between members, globals, and locals by 
> looking at them because there's no difference.  I don't think anyone is 
> particularly fond of that rule, but it is what it is.  It's one of those 
> things where I really wish the LLVM rule was different (and I think everyone 
> else does too), but it's followed regardless.  I'm not opposed to doing 
> something different, but if we do we should minimize that difference as much 
> as possible.  Note that _ followed by an uppercase letter are reserved 
> identifiers in C++.  So if we're going to veer from LLVM here, maybe camel 
> case *followed* by an _ would be a reasonable compromise.
>  

I recommend approaching this in three steps: 

1) get the less-controversial changes done that Greg was outlining.
2) start a discussion in the llvm community about the concept of a 
member/global prefix.
2a) the community could agree that llvm-as-a-whole should move to prefixes or 
otherwise change the camel case policy.
2b) the community could agree that the existing policies are preferred
3) LLDB moves to whatever is the end result of the discussion.

I guess what I’m saying is that since the opinions about this are very strong, 
and because we haven’t really had that debate in the LLVM community, that it 
would be bad to proactively move to the LLVM style, simply to have to move back 
later.  Iff the (sure to be extensive) community discussion settles on the idea 
that prefixes are the wrong thing, then LLDB should remove them to be 
consistent.

-Chris

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

Re: [lldb-dev] LLDB Evolution

[Chris Lattner via lldb-dev]

> On Aug 11, 2016, at 11:36 AM, Zachary Turner  wrote:
> 
> I was thinking the same thing too.  I figured this was just for the interim.
> 
> Chris, did you mean to update the global LLVM style conventions?

Yes, I meant that this should get updated:
http://llvm.org/docs/CodingStandards.html#include-style

-Chris

> 
> On Thu, Aug 11, 2016 at 11:27 AM Jim Ingham  > wrote:
> Shouldn't this be made general and added to the llvm coding conventions?  I 
> was assuming that upon completion of this exercise, we would delete the lldb 
> coding conventions doc.
> 
> Jim
> 
> > On Aug 11, 2016, at 11:20 AM, Zachary Turner via lldb-dev 
> > > wrote:
> >
> > On Wed, Aug 10, 2016 at 10:37 PM Chris Lattner  > > wrote:
> >
> >> On Aug 9, 2016, at 3:01 PM, Zachary Turner via lldb-dev 
> >> > wrote:
> >>
> >> So perhaps it would be reasonable for us to standardize on something like 
> >> this:
> >>
> >>  • Main Module Header
> >>  • Local/Private Headers
> >>  • lldb/...
> >>  • llvm/...
> >>  • System #includes
> >
> > This makes sense to me, and matches what clang does as well.  I think that 
> > this is clearly in the spirit of the llvm include order standards, and I 
> > think it would be great to make this explicit in the coding standard doc.  
> > Can you send in a patch to update it to make this explicit?  I’ll review it.
> >
> > -Chris
> >
> > I actually just submitted the patch.  (Sorry, itchy trigger finger or 
> > something).  r278373.  If you have any comments let me know and I'm happy 
> > to iterate on it.
> >
> > ___
> > 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] LLDB Evolution

[Chris Lattner via lldb-dev]

> On Aug 11, 2016, at 7:41 AM, Pavel Labath  wrote:
> 
> I just committed another  header cleanup commit, which makes lldb
> clang-format-immune ( = it still compiles after a full reformat) on
> linux. Other OS's are still likely to have some missed dependencies.

Nice!

> However, when I tried running the test suite I got about 150 failures.
> Based on a sample of the errors, it looks like the problem is that
> clang format messes up the "// Place breakpoint here" annotations we
> use in the tests.
> Therefore, I propose to apply the clang-format to the lldb source code
> only as a first step. After that, as a second step, we can go through
> the tests and fix them up so that the comment markers are where we
> expect them to be.

Personally, I think that reformatting is most valuable for the debugger code 
itself.  The testsuite following standards seems like a separable issue, and 
much lower priority.

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

Re: [lldb-dev] LLDB Evolution

[Chris Lattner via lldb-dev]

On Aug 9, 2016, at 8:42 AM, Zachary Turner via lldb-dev 
 wrote:
> #2 could potentially be improved by lit style tests.  

+1 to this.

> Again, the real question is just how much effort are we actually prepared to 
> put into this?  I'd love it if there were entire days or weeks that were just 
> testing weeks, where all we did was add new tests (or refactor code to make 
> it more testable) and people didn't work on anything else.  I've been 
> inactive for a while because I've had to prioritize work on some things in 
> LLVM, but I could make time for something like that.

I think it makes sense to start with the big mechanical changes and try to do 
it in a single “change the world” commit to avoid disrupting version control 
history too much.  After that is done, the many various refactorings (fixing 
dependence cycles, improving the testing situation to be more lit like, sinking 
functionality into LLVM and reusing existing LLVM functionality more, etc) can 
all be done in parallel and independently over time.

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

Re: [lldb-dev] LLDB Evolution

[Chris Lattner via lldb-dev]

> On Aug 9, 2016, at 3:01 PM, Zachary Turner via lldb-dev 
>  wrote:
> 
> So perhaps it would be reasonable for us to standardize on something like 
> this:
> 
> Main Module Header
> Local/Private Headers
> lldb/...
> llvm/...
> System #includes

This makes sense to me, and matches what clang does as well.  I think that this 
is clearly in the spirit of the llvm include order standards, and I think it 
would be great to make this explicit in the coding standard doc.  Can you send 
in a patch to update it to make this explicit?  I’ll review it.

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

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

[Chris Lattner via lldb-dev]

On Jun 28, 2016, at 12:55 PM, Chandler Carruth via Openmp-dev 
 wrote:
> I think I agree with Chris with 3.10 being the worst possible outcome.
> 
> I'd be interested to understand why you or Chris thing 3.10 is the worst 
> possible outcome.
> 
> Chris has said it is because he thinks we'll never change the "3”,

Yes, that is one reason.

> but I don't understand why 3.10 is worse than 3.9 was in that respect.

Because it breaks from the established pattern we have, and means that we never 
get to 4.

> I happen to agree that we'll never change the "3", but I don't think this 
> makes 3.10 a particularly bad choice.

If you agree that we’ll never change the 3, then you are staying that you 
believe it is ok for the version number to be meaningless.  In that case, I 
can’t see why you’d object to a policy change.

I believe that the version number is important.  Which is why I care so much 
about it :-)

I think/hope we can agree that “Bitcode compatibility” is an obsolete notion to 
encode into the version number - from a historical perspective, we only used 
that as rationale because it happened to align well for the 1.9 to 2.0 
conversion and then used it as an excuse to shed some legacy in the 3.0 
timeframe.

Given that, and given that we have a time based release, we should either leave 
the versioning alone (3.9/4.0/4.1) or switch to a semantic versioning model 
3.9/4.0/5.0/6.0 or 3.9/40/41/42).

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

[Chris Lattner via lldb-dev]

> On Jun 28, 2016, at 8:40 AM, Hans Wennborg  wrote:
> 
>> 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”?
> 
> I think the main issue (besides users asking what's the big change in
> 4.0, which I agree is not a big problem) is that the bitcode
> compatibility policy is tied to the major version number.

If that is the confusion, then I suggest that we just document (in the release 
notes) what the supported compatibility range is for any release.  That makes 
it completely unambiguous, and means that we don’t have to make an arbitrary 
policy up front (exactly N years of support!), we can drive it based on the 
cost/benefit involved with making a specific change.

Besides, people “expecting” 4.0 to break compatibility will likely ask about 
it, and be pleasantly surprised :-).  I don’t think that the association of 
major number to bitcode compatibility is actually well known outside the core 
group of folks that hang out on llvm-dev anyway.

I think that there is a reasonable argument to be made for switching to a 
semantic versioning model.  Instead of 3.9, 4.0, 4.1 we would switch to 4.0, 
5.0, 6.0 and then “4.1” would be a patch release.  It appears that jumping to 
40 just freaks too many people out.

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

[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)

[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] [Openmp-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 19, 2016, at 12:25 AM, Hal Finkel  wrote:
> 
> a) LLVM has a time-based release cycle, not a schedule-based one.  As such, a 
> simple and predictable version number makes sense.
> b) The LLVM project as a whole is a lot bigger than LLVM IR, even given its 
> centrality to the project in some ways.
> c) I think that it makes sense to keep adding 0.1 to each major release going 
> forward well into the future.
> 
> On the topic of the pointer changes proposed, I really don’t think the 
> community is served by waiting for that.  The supposition seems to be that 
> we’d land it *without* upgrade support, but then bump the major version 
> number to indicate this.  If that’s the proposal, I think that doing such a 
> thing would be disastrous for the LLVM community as a whole
> To be clear, that's not at all what I was saying. The plan has always been to 
> have upgrade support. My thought was that once the pointer changes land, it 
> will mean major changes in how many frontends and IR transformations use the 
> API. A lot of out-of-tree frontends and passes support multiple versions of 
> LLVM, and use ifdefs to work around relevant API changes. For the most part, 
> this works reasonably, and the changes necessary between versions are not 
> often large (perhaps especially because we have time-based releases). I 
> suspect, however, that the amount of code changes necessary to adapt for the 
> pointer changes will be much larger, and so calling that a new major version 
> seems fitting.

API breakage isn’t a concern, every release of LLVM breaks APIs.   I don’t see 
a reason to “delay” LLVM 4.0.

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

[Chris Lattner via lldb-dev]

> On Jun 18, 2016, at 9:16 PM, Chris Lattner via llvm-dev 
>  wrote:
> 
> On Jun 14, 2016, at 1:32 AM, Richard Smith via cfe-dev 
> > wrote:
>> I think that this is the right approach, and we happen to have a natural 
>> forcing function here: opaque pointer types. I think we should increment the 
>> major version number when opaque pointer types are here, as it will be a 
>> major breaking change, and then we'll have a version 4.0. Until then, unless 
>> something else breaking comes up, 3.10 sounds fine to me.
>> 
>> We're talking about version numbers for the entire LLVM project here, which 
>> encompasses a lot more than LLVM IR, and for many parts of which LLVM IR is 
>> utterly irrelevant. I'm not convinced that tying version numbers to 
>> backwards-incompatible changes to IR is reasonable any more, and it doesn't 
>> seem hard to explicitly document the oldest version with which we are 
>> compatible (in fact, we need to do that regardless, whether we say it's "the 
>> same major version" or "everything since 3.0" or whatever else).
>> 
>> Given that our releases are time-based rather than feature-based, I don't 
>> see a distinct major / minor version being anything other than arbitrary, so 
>> I'd suggest we take 4.0 as our next release, 4.1 as the first patch release 
>> on that, 5.0 as the next release after that, and so on.
> 
> I completely agree with Richard here.  “Breaking of IR compatibility” was an 
> interesting metric for older and less mature versions of LLVM.  We can solve 
> the same sort of challenge (the desire to eject old autoupgrade code) by 
> having a sliding window of versions supported (e.g. version 4.5 supports back 
> to version 3.6).

Let me clarify.  What I’m trying to say is that:

a) LLVM has a time-based release cycle, not a schedule-based one.  As such, a 
simple and predictable version number makes sense.
b) The LLVM project as a whole is a lot bigger than LLVM IR, even given its 
centrality to the project in some ways.
c) I think that it makes sense to keep adding 0.1 to each major release going 
forward well into the future.

On the topic of the pointer changes proposed, I really don’t think the 
community is served by waiting for that.  The supposition seems to be that we’d 
land it *without* upgrade support, but then bump the major version number to 
indicate this.  If that’s the proposal, I think that doing such a thing would 
be disastrous for the LLVM community as a whole: we need to have at least some 
sliding window of support for older formats.

-Chris

___
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] GitHub anyone?

[Chris Lattner via lldb-dev]

On Jun 6, 2016, at 10:07 AM, James Y Knight via cfe-dev 
 wrote:
> +1 to that. I would strongly suggest that we continue to commit to master 
> first, like we've always done in llvm.
> 
More generally, I suggest that we keep a discussion about moving hosting and 
svn->git to *just* those topics.  Any changes of workflow should be deferred 
until after and if these changes happen.

-Chris


> 
> On Jun 6, 2016 11:44 AM, "Joerg Sonnenberger via cfe-dev" 
> > wrote:
> On Mon, Jun 06, 2016 at 10:32:45AM -0500, via llvm-dev wrote:
> > My only hesitation with this is that this requires use of cherry-pick,
> > which is not idea.  The way most git repositories work is to put
> > everything that should go into a release branch in the release branch
> > *first* and then merge the release branch to master, ensuring that
> > everything going out in a release will make it into the next release.
> > This is how the gitflow workflow works, for example.
> 
> The model of "commit to oldest first" is IMO one of the most stupid
> concepts I have ever seen in git "workflows". It is contrary to the way
> software development works and essentially just a bad workaround for
> broken cherry picks. I've seen more than one project starting to use
> this model due to advocacy after deciding to use git, stumble around
> with it for a release or two and then going back to a normal release
> management approach. Even the argument you have presented here does not
> make sense to me. Just because a change has been committed to a release
> branch, doesn't mean it won't get replaced later.
> 
> Joerg
> ___
> 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] GitHub anyone?

[Chris Lattner via lldb-dev]

> On Jun 2, 2016, at 11:42 AM, via lldb-dev  wrote:
> 
> Yeah, I get that and I actually don't mind keeping a linear history.
> But we definitely should branch for release.  Given release branches,
> there are a number of questions and tradeoffs about how to backport
> changes from master/latest development to a release.  Some of those
> options break linear history.  This is the kind of workflow stuff we
> should clarify if possible.

+1 for branching for official llvm.org releases, and each branch should have 
its own linear history (from its branch point).

I don’t think we want people’s random projects and development branches on 
llvm.org.  They can clone to repo off to their own fork on github and do what 
they want there.

-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] GitHub anyone?

[Chris Lattner via lldb-dev]

On Jun 2, 2016, at 11:01 AM, d...@cray.com wrote:
> 
> What exactly is the concrete benefit of monotonically increasing
> revision numbers?  It's completely foreign to git's architecture.
> 
> Putting this requirement on git is going to severely limit how the
> history is allowed to look.  Maybe that's what people want, I don't
> know.  We certainly haven't missed them since moving to git.

I think we *want* to severely limit how history is allowed to look.  We don’t 
want the entire development history of your long-lived branch coming to 
mainline.

When a patch is accepted to an llvm.org repository, it is committed as an 
atomic unit.  It is expected to be reviewed (pre or post), include testcases, 
and uphold the standards of the project *in that unit*.  There is no value in 
providing additional details.  

If there were, then the patch should be committed as a linear series of 
independent pieces, each of which lives up to the project’s standards.

-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] GitHub anyone?

[Chris Lattner via lldb-dev]

> On May 31, 2016, at 12:31 PM, Renato Golin via llvm-dev 
>  wrote:
> There has been some discussion on IRC about SVN hosting and the perils
> of doing it ourselves. The consensus on the current discussion was
> that moving to a Git-only solution would have some disvantages, but
> many advantages. Furthermore, not hosting our own repos would save us
> a lot of headaches, admin costs and timed out connections.

Personally, I’m hugely in favor of moving llvm’s source hosting to github at 
some point, despite the fact that I continue to dislike git as a tool and 
consider monotonicly increasing version numbers to be hugely beneficial.

The killer feature to me is the community aspects of github, allowing people to 
get involved in the project more easily and make “drive by” contributions 
through the pull request model.  Github also has a very scriptable interface, 
allowing integration of external bug trackers etc into the workflow (which is 
good, because its bugtracker is anemic).

> 4. We currently host our own SVN/Git, ViewVC and Klaus, Phabricator,
> etc. Not only this incurs in additional admin cost, but it also gets
> outdated, locally modified, and it needs to be backed up, etc. GitHub
> gives all that for us for free.

Yes, it would be great to get out of this business.

> 5. We can still use Bugzilla (and lock GitHub's own bug system), but
> we can also use GitHub's system to manage releases (it's actually
> quite good for that).

If we made this change, I think we should only change one thing at a time: 
change source hosting, but not phabricator or the bug tracker.  We could then 
discuss moving off phabricator to the github PR model, etc.

> 6. GitHub has automated testing of merge requests, meaning we can have
> pre-commit tests enabled on a set of fast bots, triggered by GitHub's
> own validation hooks.

This works pretty well.  The major problem is with tests that are flakey.

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

[lldb-dev] License & Patents discussion on llvm-dev

[Chris Lattner via lldb-dev]

FYI, I just started a discussion on llvm-dev about the license & patents 
situation in the project, it also affects LLDB, so if you’re interested, please 
check it out there.

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