search for: bdfl

...to delete the entire build tree and start again. > > I think svn works better than git as an authoritative upstream > > Would you mind expanding on this? What problem specifically is being solved? Linus and Guido both use DVCS's and the authoritative upstream is whatever URL the BDFL says it is. Monotonic version numbers are the biggest advantage. It is easy to see that r1234432 contains the bug fix introduced in r1234430. It is very hard to see if version 23bef194ac contains the bug fix added in 23bef19412. This makes interaction with bugzilla and so on much easier. If som...

...d system that uses file hashes instead of last-modified times? > I think svn works better than git as an authoritative upstream Would you mind expanding on this? What problem specifically is being solved? Linus and Guido both use DVCS's and the authoritative upstream is whatever URL the BDFL says it is. Thanks, Greg On Thu, Nov 15, 2012 at 9:38 AM, <dag at cray.com> wrote: > David Chisnall <David.Chisnall at cl.cam.ac.uk> writes: > > > clock skew (which is easy to get in a VM) can confuse Ninja in a way > > that doesn't give helpful errors. > &...

David Chisnall <David.Chisnall at cl.cam.ac.uk> writes: > clock skew (which is easy to get in a VM) can confuse Ninja in a way > that doesn't give helpful errors. This is a significant issue. I would not want to transition to cmake+ninja before this is fixed. -David

...id.Chisnall at cl.cam.ac.uk> wrote: >> > I think svn works better than git as an authoritative upstream >> >> Would you mind expanding on this? What problem specifically is being solved? Linus and Guido both use DVCS's and the authoritative upstream is whatever URL the BDFL says it is. > > Monotonic version numbers are the biggest advantage. It is easy to see that r1234432 contains the bug fix introduced in r1234430. It is very hard to see if version 23bef194ac contains the bug fix added in 23bef19412. This makes interaction with bugzilla and so on much easier...

...uk> wrote: > >> > I think svn works better than git as an authoritative upstream > >> > >> Would you mind expanding on this? What problem specifically is being > solved? Linus and Guido both use DVCS's and the authoritative upstream is > whatever URL the BDFL says it is. > > > > Monotonic version numbers are the biggest advantage. It is easy to see > that r1234432 contains the bug fix introduced in r1234430. It is very hard > to see if version 23bef194ac contains the bug fix added in 23bef19412. > This makes interaction with bugzi...

...better than git as an authoritative upstream >>> >> >>> >> Would you mind expanding on this? What problem specifically is being >>> >> solved? Linus and Guido both use DVCS's and the authoritative upstream is >>> >> whatever URL the BDFL says it is. >>> > >>> > Monotonic version numbers are the biggest advantage. It is easy to see >>> > that r1234432 contains the bug fix introduced in r1234430. It is very hard >>> > to see if version 23bef194ac contains the bug fix added in 23bef1941...

alan said: > I think I am in agreement, > if by "isn't necessary" you mean to say that > simply providing more features to Markdown > doesn't force end users to use them, > or even really know they exist. except that wasn't what i meant. i mean that it's not necessary to trade simplicity in order to get the power of additional

...think svn works better than git as an authoritative upstream >> >> >> >> Would you mind expanding on this? What problem specifically is being >> >> solved? Linus and Guido both use DVCS's and the authoritative upstream is >> >> whatever URL the BDFL says it is. >> > >> > Monotonic version numbers are the biggest advantage. It is easy to see >> > that r1234432 contains the bug fix introduced in r1234430. It is very hard >> > to see if version 23bef194ac contains the bug fix added in 23bef19412. This >&gt...

...think svn works better than git as an authoritative upstream >> >> >> >> Would you mind expanding on this? What problem specifically is being >> >> solved? Linus and Guido both use DVCS's and the authoritative upstream is >> >> whatever URL the BDFL says it is. >> > >> > Monotonic version numbers are the biggest advantage. It is easy to see >> > that r1234432 contains the bug fix introduced in r1234430. It is very hard >> > to see if version 23bef194ac contains the bug fix added in 23bef19412. This >&gt...

...tive upstream >>>>> >> >>>>> >> Would you mind expanding on this? What problem specifically is being >>>>> >> solved? Linus and Guido both use DVCS's and the authoritative upstream is >>>>> >> whatever URL the BDFL says it is. >>>>> > >>>>> > Monotonic version numbers are the biggest advantage. It is easy to see >>>>> > that r1234432 contains the bug fix introduced in r1234430. It is very hard >>>>> > to see if version 23bef194ac contain...

...g to the other repository, and have to mechanically go and rename all their variables. While I personally like your naming convention slightly better than LLVM's, and a few other conventions slightly better than yours, I really don't care. I think we (and by we, I mean Chris in his role as BDFL of the LLVM coding standards) should pick a naming convention, and stick to it. If Chris wants to switch LLVM's guidelines for new code going forward to match yours, I'm fine with that. If he wants to make up a third convention, I'm fine with it. As long as I can train my fingers to wri...

On Jan 20, 2013, at 10:18 PM, Chandler Carruth wrote: > Sorry, I wasn't trying to suggest anything vague, but rather refer to my previous (perhaps ill founded) understanding about the expected path forward for LLD. Anyways, I'll explain in a bit more detail so we can talk about the concrete issue. > > My concrete hope is that LLD migrates toward the coding standards that are

Hello everyone, We are in the process of formalizing the governance model of the GlusterFS project. Historically, the governance of the project has been loosely structured. This is an invitation to all of you to participate in this discussion and provide your feedback and suggestions on how we should evolve a formal model. Feedback from this thread will be considered to the extent possible in

On Sun, Jan 20, 2013 at 8:35 PM, Nick Kledzik <kledzik at apple.com> wrote: > > On Jan 19, 2013, at 1:55 AM, Chandler Carruth wrote: > > We're looking more at doing some serious hacking on LLD, and I'd like to > avoid doing lots of work in the codebase only to change the style around > later. > > > > My understanding was that LLD was always intended to

Hi Everyone, Numerous people have been bringing up challenges with consensus driven decision making in the LLVM community. After considering this and seeing the frustrations it is causing many people, I think we should make a formal process change to help improve decision making going forward. Here is the outline of the draft proposal