Re: Should we discuss Windows-related changes on git@vger.kernel.org?

From: Steffen Prohaska <prohaska@zib.de>
Date: Jul 11, 2008, 21:10 UTC
Message-ID: <0E93411E-745C-4858-999E-F0B7487B48B1@zib.de>
In-Reply-To: <alpine.DEB.1.00.0807112037220.8950@racer>

On Jul 11, 2008, at 9:40 PM, Johannes Schindelin wrote:

Show 24 quoted lines

> 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", see

http://thread.gmane.org/gmane.comp.version-control.msysgit/2653/focus=2682

Another example is the discussion about GIT_EXEC_PATH, see

http://thread.gmane.org/gmane.comp.version-control.msysgit/2633

It might be triggered by msysGit's need to freely move a git installation in the filesystem. The resulting feature might however be interesting on other platforms, too.

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

Show 12 quoted lines

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

	Steffen