Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?
+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 > > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.or
Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
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] Sequential ID Git hook
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] FYI: Landing the initial draft for an LLVM Code of Conduct
I don’t know what you meant to imply by “residual clause” — if you meant “it’s not particularly important”, then I suggest it is left out entirely. Apparently at least a few of us have interpreted it to say “the committee reserves the right to kick you out for any behaviour that violates our standards which you exhibit anywhere, even if it is completely unrelated to the llvm community”. Personally, I’m just going to ignore it, and thus don’t really care whether it stays or goes — but I do find it overreaching and intrusive, and completely inappropriate in such a code of conduct. On Jun 30, 2016, at 5:11 PM, Daniel Berlin via llvm-dev wrote: > That's just a residual clause. > It's not sanely possible to enumerate all the possibilities here (IE if you > stalk and murder someone in the llvm community, you are going to get kicked > out of the community, regardless of if you did it in a controlled space) > I mean, i'm subject to legal ethics rules that are very similar, and those > could get me kicked out of an entire profession :) > > I guess one could write "In addition, violations of this code outside these > spaces may, in rare > cases, affect a person's ability to participate within them, when the conduct > amounts to an egregious violation of the communitie's social standard." > > But it's not, in practice, any different. > > Basically, if you are looking for complete and total bright line proscribed > standards, they pretty much don't exist anywhere except in criminal statutes > :) > > > > On Thu, Jun 30, 2016, 2:45 PM Robinson, Paul wrote: > I expect Rafael's concern is because the code also says: > > > > In addition, violations of this code outside these spaces may, in rare > cases, affect a person's ability to participate within them. > > > > So it can apply outside spaces explicitly sponsored by LLVM, in undefined > circumstances. > > --paulr > > > > From: cfe-dev [mailto:cfe-dev-boun...@lists.llvm.org] On Behalf Of Daniel > Berlin via cfe-dev > Sent: Thursday, June 30, 2016 1:37 PM > To: Rafael Espíndola > Cc: llvm-dev; cfe-dev; openmp-dev (openmp-...@lists.llvm.org); LLDB > Subject: Re: [cfe-dev] [llvm-dev] FYI: Landing the initial draft for an LLVM > Code of Conduct > > > > > > > > On Thu, Jun 30, 2016 at 1:23 PM, Rafael Espíndola > wrote: > > I am strongly opposed to it as it stands. > > Who decided this and with what authority? As written the code of > conduct tries restrict the acceptable opinions one may voice even in > channels not related to llvm at all. > > errr, it says: > > "This code of conduct applies to all spaces managed by the LLVM project or The > > LLVM Foundation. This includes IRC channels, mailing lists, bug trackers, LLVM > > vents such as the developer meetings and socials, and any other forums created > > by the project that the community uses for communication. " > > > > > > How does this cover channels not related to llvm? > > > > With this in place I will not consider myself a member of the llvm > community anymore and would be terrified to interact with another llvm > developer in a social setting. > > > > That would be sad, but i guess i'm not sure what is causing that. Is it that > there is discretion in there that you are afraid may apply to you if taken to > some extreme? > > > > Rafael > > On 30 June 2016 at 14:55, Chandler Carruth via cfe-dev > > wrote: > > Hello folks, > > > > As mentioned some time ago[1], we’ve had a long (looong) series of > > discussions about establishing a code-of-conduct for the LLVM project as a > > whole over on the llvm-dev thread and the http://reviews.llvm.org/D13741 > > code review. > > > > The discussion has largely died down for some time, and towards the end > > there has been pretty wide support for the draft wording we have now. It > > isn’t perfect, and there are still some important questions around forming > > the advisory committee to handle reporting, but I think the wording is at a > > good point of compromise in a challenging area. > > > > Based on the support, I’m going to land the patch that adds the draft. I’m > > hoping this will immediately provide good advice and guidance, and I’m > > hoping to see motion on setting up a reasonable advisory committee and > > resolving any issues around reporting so we can make this an official part > > of the community. > > > > I sending this as a heads up so folks are aware, not to start a new > > discussion thread. There are existing discussion threads[2] on llvm-dev if > > folks want to join in active discussion or we can start fresh ones, but I > > would encourage people to carefully read the discussion that has already > > taken place to avoid revisiting areas that have already been heavily > > discussed. > > > > Also, many thanks to the folks who provided all their opinions on the > > mailing list threads and in person in long discussions about this topic. > > > > Thanks, > > -Chandl
