search for: mainlines

On Jul 22, 2011, at 2:02 PM, Andrew Trick wrote: >> Of course, if you've used SVN extensively, you've been trained to think >> that history has to be somewhat linear, and perhaps even that the trunk >> branch is the only one needing QA attention. Migration from SVN to Git >> is hard because you have to change the mental model, not just command >> names and

On Jul 23, 2011, at 5:37 AM, FlyLanguage wrote: >>>> After git, mainline will still be the most important branch for >>>> the *project*, >>>> but you will work with quite a few branches on parallel. >>>> >>>> >>>> Who's mainline? :) Be prepared to assign a super-merger, like Linus, >>>> to maintain

On Mon, Jul 16, 2012 at 11:44:25AM -0700, Owen Anderson wrote: > Tom, > > I think it might be productive to fork this thread to discuss making the requirements for upstreaming a new LLVM target more explicit and open. I'd also like to gauge interest in an idea I've discussed privately with a few community members, namely the concept of having a semi-official

On Jul 22, 2011, at 3:45 PM, Bob Wilson wrote: > > On Jul 22, 2011, at 3:33 PM, fly language wrote: > >> >> After git, mainline will still be the most important branch for the *project*, >> but you will work with quite a few branches on parallel. >> >> >> Who's mainline? :) Be prepared to assign a super-merger, like Linus, to maintain the

Dear Pawel and All, Pawel (and other release managers), can you ask the project maintainers for each project whether they want a release branch before creating it next time? Alternatively, can you leave branch creation up to the project maintainers as in the past? Pawel, you created a release_32 branch of SAFECode last night without my consultation. That commit itself is fine since we just

Owen/Chandler/etc.., While I have no issue with having a more complete and documented method of submitting backends, the problem is the barrier to entry for some backends is being significantly raised, where they did not exist in the past. In the past AMD has reported issues that we have found from internal development to LLVM, along with patches in some cases. Some have been fixed, but others are

Mainline and 4.3 branch GCC libstdc++ have removed string.h access from STL map etc. As a result several LLVM System files and others do not compile on mainline and 4.3. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070518/5ad77408/attachment.html>

John, > Dear Pawel and All, > > Pawel (and other release managers), can you ask the project maintainers > for each project whether they want a release branch before creating it > next time? Alternatively, can you leave branch creation up to the > project maintainers as in the past? I think asking project maintainers for a go/no-go for branch creation is a very good idea that

On Jul 22, 2011, at 3:33 PM, fly language wrote: > > After git, mainline will still be the most important branch for the *project*, > but you will work with quite a few branches on parallel. > > > Who's mainline? :) Be prepared to assign a super-merger, like Linus, to maintain the "mainline". > > The git workflow works really really great, but it does

Chris, I am doing Cygwin builds at the moment so it will not be immediately attended to. Do you want it done for 2.0 ? Or could it be a post 2.0 patch which I suggest as 4.3 branch is not up for a release too soon ? Aaron ----- Original Message ----- From: "Chris Lattner" <sabre at nondot.org> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent:

When we back port patches from FSF GCC mainline, we decorate them with 'mainline' markers, for example /* APPLE LOCAL begin 4229621 mainline */ .... /* APPLE LOCAL end 4229621 mainline */ There are many examples of such markers in source. These markers help us resolve conflicts when we merge current sources in mass with FSF GCC mainline. They also help solve mysterious failures

On Fri, 18 May 2007, Aaron Gray wrote: > Mainline and 4.3 branch GCC libstdc++ have removed string.h access from > STL map etc. > > As a result several LLVM System files and others do not compile on > mainline and 4.3. Okay, will you please prepare and submit a patch that adds the needed #include's? -Chris -- http://nondot.org/sabre/ http://llvm.org/

On Mon, Aug 07, 2023 at 04:00:49PM -0700, Chris Maness wrote: > When are these likely to hit the mainline release code? linux-next tomorrow. The first 7 patches are scheduled for mainline as they were merged + tested without any hiccups. These last few patches I'll wait and see. If nothing blows up on linux-next perhaps I'll include them to Linux for mainline during the next merge

...this is moving from llvm-commits to llvm-dev. On Feb 10, 2012, at 12:14 PM, Sergei Larin <slarin at codeaurora.org> wrote: > 1) Can a BB presented to the MI scheduler be _not_ terminated (end on a non > terminator MI) under any circumstances? Below you are speaking about "Empty > blocks, or blocks with only a single instruction that not a terminator..." - > What

The attached patch is a backport of patch 98010 from the gcc svn. It is useful mostly to make the porting of more ARM patches easier, but will be needed when we start to use C++ on ARM. Could someone please commit it to the svn? Thanks, Rafael -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-gcc-98010.patch Type: text/x-patch Size: 13491 bytes Desc: not

I know that this is not the appropriate place :). You know someone can alternative to gluserfs ?:) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20090107/63b68a0d/attachment.html>

Hello Are there plans to merge the hpn-ssh (http://www.psc.edu/networking/projects/hpn-ssh/) and the LPK (http://code.google.com/p/openssh-lpk/) into the mainline openssh. Adding lpk has been logged as a bug in bugzilla as They are two patches that I always apply as the performance boost from hpn-ssh is substantial to say the least, and centralisation of the authorized_keys into a LDAP server

On Nov 29, 2006, at 11:27 AM, Devang Patel wrote: > When we back port patches from FSF GCC mainline, we decorate them > with 'mainline' markers, for example > > /* APPLE LOCAL begin 4229621 mainline */ > .... > /* APPLE LOCAL end 4229621 mainline */ > > There are many examples of such markers in source. These markers > help us resolve conflicts when >

We have a central samba file share for our designers (who all use OSX boxes, and mostly use Macromedia products) to work off of. I've lately been able to track down a lot of application quirks (mostly problems with errors when saving, about files being locked) to the Mac resource fork files being indefinitely locked. Here's a sample from a `smbstatus` 14853 DENY_NONE 0x1

On 9/9/11 1:08 PM, Jack Howarth wrote: > Are there any plans to add CMake support to the build of > SAFECode? No, there are no current plans to do so. Is not having CMake support a show-stopper for you? I imagine adding support for it would be straightforward. > Also are there any current instructions for building > llvm/clang with SAFECode support from current svn? Yes.