Re: [PATCH] Third try at documenting command integration requirements.
On 11/26/2012 10:41 PM, Eric S. Raymond wrote: The next things on my git to-do list are [...] 2. Submit a doc patch containing guidelines that (a) Python scripts should check for their floor version and error out gracefully if they won't run with the host's interpreter, and (b) Python scripts sbould be 2.6-compatible. OK, now let's discuss *which* minimum Python version that git should support in the hypothetical new world... Data point: Mercurial supports Python 2.4 - 2.7 with the following explanation [1]: We will continue to support Python 2.4 as long as it doesn't present a significant barrier to development. Given that Python 2.5 and later don't contain any features that we're dying to use, that may be a long time off. [...] We also will continue to support Python 2.x as long as there is a significant installed base in the form of Red Hat Enterprise Linux and Ubuntu LTS users. RHEL 5, which uses Python 2.4, will reach the end of the production 2 portion of its lifecycle in Q1 2014 and the end of its regular lifecycle in 2017. It would be a shame to leave RHEL 5 users behind if Python is used to implement important git functionality. Python 2.4 is missing some of Python's shiny new features, but still quite OK. What features would you miss the most if we were to target Python 2.4 instead of 2.6? Michael [1] http://mercurial.selenic.com/wiki/SupportedPythonVersions -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Third try at documenting command integration requirements.
Michael Haggerty mhag...@alum.mit.edu: OK, now let's discuss *which* minimum Python version that git should support in the hypothetical new world... By all means! It would be a shame to leave RHEL 5 users behind if Python is used to implement important git functionality. Python 2.4 is missing some of Python's shiny new features, but still quite OK. What features would you miss the most if we were to target Python 2.4 instead of 2.6? Off the top of my head...the 'with' statement, the conditional expression, and built-in JSON support. Other developers would be likely to kick about the string format() method; personally I'm cheerfully old-school about that. I agree that 2.4 is still quite OK. I'm a little concerned that dropping that far back might store up some transition problems for the day we decide to make the jump to Python 3. On the other hand, I think gating features on RHEL5 might be excessively cautious. According to [1], RHEL will red-zone within 30 days if it hasn't done so already ([1] says Q4). And RHEL6 (with Python 2.6) has been shipping for two years. Policy suggestion: we aim to stay friendly for every version of RHEL that is still in Support 1. I doubt anyone will code anything critical in Python before Dec 31st - I'm certainly not planning to! [1] http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux RHEL5 is going -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Third try at documenting command integration requirements.
Eric S. Raymond e...@thyrsus.com writes: I agree that 2.4 is still quite OK. I'm a little concerned that dropping that far back might store up some transition problems for the day we decide to make the jump to Python 3. On the other hand, I think gating features on RHEL5 might be excessively cautious. According to [1], RHEL will red-zone within 30 days if it hasn't done so already ([1] says Q4). And RHEL6 (with Python 2.6) has been shipping for two years. I won't worry about Python 3 yet; in what timeframe did Python's i18n/unicode support become usable? In 2.4, or 2.6? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Third try at documenting command integration requirements.
Junio C Hamano gits...@pobox.com: I won't worry about Python 3 yet; in what timeframe did Python's i18n/unicode support become usable? In 2.4, or 2.6? Er, it depends on what you consider usable. Unicode integration turned out to have a lot messier edge cases than anyone understood going in. First-cut support was in 1.6, but I'd say it still has some pretty sharp edges *today*. Which is why 3.0 has gone all-Unicode-all-the-time. The problems mostly come from having two different notions of string that don't really mix well. Me, I still avoid the hell out of Unicode in Python. And occasionally fund myself cursing a library maintainer who didn't. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Third try at documenting command integration requirements.
Junio C Hamano gits...@pobox.com: I'll reword the title (readers of git log output 6 months down the road will not care if this is the third try or the first one) and tweak things here and there before queuing. Result looks good from here. The next things on my git to-do list are 1. Audit the in-tree Python for version dependencies. Add floor-version checks. 2. Submit a doc patch containing guidelines that (a) Python scripts should check for their floor version and error out gracefully if they won't run with the host's interpreter, and (b) Python scripts sbould be 2.6-compatible. 3. Submit the git-weave integration patch. I could do that now, but while my regression test speaks TAP it doesn't presently use the test library. I plan to re-work it to do that. Do you have any other pending tasks for which you think my expertise would be useful? I refer specifically to the facts that (a) I find writing and editing documentation easy and can do it rapidly, (b) I'm a Python expert, and (c) I am very interested in, and know a lot about, tools for repository surgery and import/export. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Third try at documenting command integration requirements.
e...@thyrsus.com (Eric S. Raymond) writes:
@@ -0,0 +1,91 @@
+= Integrating new subcommands =
+
+This is how-to documentation for people who want to add extension
+commands to git. It should be read alongside api-builtin.txt.
+
+== Runtime environment ==
+
+git subcommands are standalone executables that live in the git
Even though ={n} title ={n} is a valid AsciiDoc heading, all other
files use (older) underscored titles; please refrain from being
original.
Especially, this interferes with the way the api-index.txt file in
the same directory is autogenerated.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Third try at documenting command integration requirements.
Junio C Hamano gits...@pobox.com:
Even though ={n} title ={n} is a valid AsciiDoc heading, all other
files use (older) underscored titles; please refrain from being
original.
Especially, this interferes with the way the api-index.txt file in
the same directory is autogenerated.
Noted for the future, thank you.
--
a href=http://www.catb.org/~esr/;Eric S. Raymond/a
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
