Hi, On Fri, 11 Jul 2008, Steffen Prohaska wrote: > On Jul 11, 2008, at 9:40 PM, Johannes Schindelin wrote: > > >On Fri, 11 Jul 2008, Linus Torvalds wrote: > > > > >- It may well be good to explain to the _real_ git people (eg me) > > > what the problems in Windows land are, so that we get a first-hand > > > view into hell, and can maybe take it into account when we make > > > changes for other things. > > > >Wow. I did not think that you were a masochist. > > > > >IOW, I think that since 1.6.0 is supposed to have native support for > > >windows, we should have patches discussed on the regular git list. > > >The ghetto that is windows can be useful for _user_ discussions, > > >where a lot of the core git people simply cannot help. But having > > >development discussions there is bad, I think. > > > >We do have development discussions there that do not belong to > >git@vger. For example, when Hannes reimplemented the utterly broken > >spawn() implementation of Microsoft's "Run" time library. > > > >That is not something you need to see, want to see, or can help with. > > The separation is not always that clear. For example, the discussion > of issue 130 might benefit from "a first-hand view into hell", Maybe I am overly cautious, but you remember what drove me away from msysGit? Exactly, people, and issues, took out all the fun. Let's not inflict upon git@vger what they did not deserve to suffer. And if the separation is not always that clear, why not discuss those things on msysGit first, and then come to git@vger with our minds (and possibly our patches) made up? > Another example is the discussion about GIT_EXEC_PATH, see > > http://thread.gmane.org/gmane.comp.version-control.msysgit/2633 This is a particularly good example that does not matter for Linux, MacOSX, Solaris or the BSDs (Git's principal platforms!) at all. And once this patch hits git@vger, it is still visible to other platforms. > A last example is the crash of gitk that was observed on Windows and is > now buried in the msysGit issue tracker, although I am pretty sure that > is it not windows-specific, see > > http://code.google.com/p/msysgit/issues/detail?id=125 So? If it did not hit other platforms, it is the duty of that guy to find out what it is. And if it _does_ turn out to be a Windows-specific bug, which might very well be the case, we do not need to add to the volume of git@vger. > >Likewise, I think it has nothing to do with the git@vger list when we > >add work-arounds until some better solution is found, and then discuss > >whether the workaround is still needed. > > > >I cannot help to see the benefit, at least. > > > >Once things are sorted out, I agree, it has to be sent to the git list. > > > >Before that, however, allow us to work on another list. > > Personally, I'd find it easier to work on a single list. Sure the benefit is undisputed. Now let's look at the downsides: we take away time, and possibly fun, from many more people than one or two persons. It's like spam. Asking somebody to "just hit the delete button" stops being funny very quickly. > MinGW support is mature enough and workarounds should now be avoid. If > we tested git during the official release cycle, we would have > sufficient time to find and solve problems on Windows and prepare > patches that have sufficient quality to be discuss on git@vger. I am not so sure. Your experience should match mine, that the patches coming in through msysGit are of a substantial lower quality than what we are used to on git@vger. If you want to force those patches unfiltered onto the readers of git@vger, it would only be fair that you have to clean the readers' latest lunch out of their keyboards. Ciao, Dscho "who has a fata morgana of windmills" -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
