On 6/08/2009 12:28 AM, Stephen J. Turnbull wrote: > Mark Hammond writes: > > > I'm not sure what point you are trying to make, but I believe it *is* > > possible for a solution to be found here which will keep Windows users > > happy. I'm guessing you haven't had much practical experience with this > > problem, so probably don't see this is clearly as Windows users do. > > Mercurial is not only open source, it's written in Python. The > problem is known to be hard in a practical sense, the existing > solutions (written by non-Windows developers, of course) are judged to > be insufficient by Windows users, and the non-Windows developers > "probably don't see this is clearly as Windows users do." > > I think the implication is obvious. There will be no good solution > until Windows users develop it. I don't see a good reason to wait for > that. My conclusion is different. I'm not sure of the history of win32text, but it most certainly is now squarely in the hands of Windows users. Patches to win32text, or even general discussion is usually met with silence, and when prodded, the response is "sorry - we don't use that - it is a Windows problem." As a result, we end up in the position we are in now - win32text is great in theory but doesn't work in practice, attempts to make it work are met with indifference, and the "problem" stays squarely with Windows users. Non Windows users remain oblivious to the pain, Windows users stop bothering with the extension, and the repository post-commit hooks then cause different pain. Hence my conclusion that the answer is for any such support to be developed in conjunction with Windows users, but also in such a way that the solution works, almost identically, for non Windows users. By insisting all platforms eat the same dog-food, there is much more chance the glaringly obvious (to Windows users) issues are addressed. > I do see good reason for non-Windows users to put up with some > inconvenience during the "beta" phase of implementing that solution; > it's important enough to be fast-tracked, and doesn't need to be > perfect for everybody to be tried (though it should not be allowed to > endanger repo content, which seems unlikely but needs care since it's > a potential disaster). And on the flip-side, I accept we may migrate without the agreed solution fully implemented - I'm happy to accept commitments about what *will* be done even if it isn't a reality for a short while... Cheers, Mark
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4