headers
Jesse Noller | 2 Oct 15:05

Doc nits question

So, we just released and there are a few doc typo bugs being filed -
my question is if all doc-fixes have to wait for 2.6.1/2.7 or if we
can hotfix the 2.6 docs?

-jesse
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |
headers
Georg Brandl | 2 Oct 15:21
Gravatar

Re: Doc nits question

Jesse Noller schrieb:
> So, we just released and there are a few doc typo bugs being filed -
> my question is if all doc-fixes have to wait for 2.6.1/2.7 or if we
> can hotfix the 2.6 docs?

I intend to set things up so that the docs at docs.python.org are continually
rebuilt, just like the /dev docs were until now.

Georg

--

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |
headers
Jesse Noller | 2 Oct 15:26

Re: Doc nits question

On Thu, Oct 2, 2008 at 9:21 AM, Georg Brandl <g.brandl <at> gmx.net> wrote:
> Jesse Noller schrieb:
>> So, we just released and there are a few doc typo bugs being filed -
>> my question is if all doc-fixes have to wait for 2.6.1/2.7 or if we
>> can hotfix the 2.6 docs?
>
> I intend to set things up so that the docs at docs.python.org are continually
> rebuilt, just like the /dev docs were until now.
>
> Georg

Fantastic, so the doc updates should go to the 2.6 branch, correct?
(Not that I'm suggesting checking in all willy nilly)
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |
headers
Georg Brandl | 2 Oct 15:36
Gravatar

Re: Doc nits question

Jesse Noller schrieb:
> On Thu, Oct 2, 2008 at 9:21 AM, Georg Brandl <g.brandl <at> gmx.net> wrote:
>> Jesse Noller schrieb:
>>> So, we just released and there are a few doc typo bugs being filed -
>>> my question is if all doc-fixes have to wait for 2.6.1/2.7 or if we
>>> can hotfix the 2.6 docs?
>>
>> I intend to set things up so that the docs at docs.python.org are continually
>> rebuilt, just like the /dev docs were until now.
>>
>> Georg
> 
> Fantastic, so the doc updates should go to the 2.6 branch, correct?
> (Not that I'm suggesting checking in all willy nilly)

This is another thing that needs to be discussed: how to handle backports
between 2.6 and 2.7. Up to now, we backported changes from trunk to maint
manually, but after the experience we've had with svnmerge, I see several
possibilities:

1. Do bugfixes in maint, merge them to trunk via svnmerge. This has the
   drawback that you have to work in two different repos for fixes vs.
   new features. The advantage however is that normally all fixes that
   go into maint apply to trunk as well, so almost no blocks need to be done.
   However, since Py3k merges are done from trunk, the 3k merge will see
   merges as single commits, so they aren't easy to block if not applicable.
   This will mean more conflicts.

2. Do bugfixes in trunk, and merge them to maint via svnmerge.
   Arguments as for 1, but reversed: many blocks, but less problems with 3k.
(Continue reading)

Permalink | Reply |
headers
Georg Brandl | 2 Oct 21:16
Gravatar

Bugfix porting policy (was Re: Doc nits question)

Just now, Christian decided for option 2...

Georg

> This is another thing that needs to be discussed: how to handle backports
> between 2.6 and 2.7. Up to now, we backported changes from trunk to maint
> manually, but after the experience we've had with svnmerge, I see several
> possibilities:
> 
> 1. Do bugfixes in maint, merge them to trunk via svnmerge. This has the
>    drawback that you have to work in two different repos for fixes vs.
>    new features. The advantage however is that normally all fixes that
>    go into maint apply to trunk as well, so almost no blocks need to be done.
>    However, since Py3k merges are done from trunk, the 3k merge will see
>    merges as single commits, so they aren't easy to block if not applicable.
>    This will mean more conflicts.
> 
> 2. Do bugfixes in trunk, and merge them to maint via svnmerge.
>    Arguments as for 1, but reversed: many blocks, but less problems with 3k.
> 
> 3. Backport bugfixes manually, like for the previous maintenance branches.

--

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

_______________________________________________
Python-Dev mailing list
(Continue reading)

Permalink | Reply |
headers
"Martin v. =?iso-8859-1?q?L=F6wis=22?= | 2 Oct 22:18

Re: Bugfix porting policy (was Re: Doc nits question)

>> 2. Do bugfixes in trunk, and merge them to maint via svnmerge.
>>    Arguments as for 1, but reversed: many blocks, but less problems with 3k.

I'm not so sure that we need to block all the changes that we don't
want, though: it would be sufficient to just not merge them, right?

(of course, somebody could go over it from time to time and block
everything older than a month that was still available, just to prevent
accidental merging)

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |
headers
Benjamin Peterson | 2 Oct 22:26
Gravatar

Re: Bugfix porting policy (was Re: Doc nits question)

On Thu, Oct 2, 2008 at 3:18 PM, "Martin v. Löwis" <martin <at> v.loewis.de> wrote:
>>> 2. Do bugfixes in trunk, and merge them to maint via svnmerge.
>>>    Arguments as for 1, but reversed: many blocks, but less problems with 3k.
>
> I'm not so sure that we need to block all the changes that we don't
> want, though: it would be sufficient to just not merge them, right?

A large merge queue would accumulate making hard for someone to pick
out the bugfixes. Of course, people could just merge fixes right after
they apply it to the trunk, though.

>
> (of course, somebody could go over it from time to time and block
> everything older than a month that was still available, just to prevent
> accidental merging)
>
> Regards,
> Martin
> _______________________________________________
> Python-Dev mailing list
> Python-Dev <at> python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com
>

--

-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."
_______________________________________________
(Continue reading)

Permalink | Reply |
headers
"Martin v. =?iso-8859-1?q?L=F6wis=22?= | 2 Oct 22:31

Re: Bugfix porting policy (was Re: Doc nits question)

> A large merge queue would accumulate making hard for someone to pick
> out the bugfixes. Of course, people could just merge fixes right after
> they apply it to the trunk, though.

I think they should. To my knowledge, nobody goes through the changelog
anymore trying to find out what needs backporting. Tracking what still
needs merging should happen in the bug tracker, by leaving the report
open until merging has been done. Every change that isn't immediately
merged and doesn't have an open issue just won't get merged at all.

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |
headers
Georg Brandl | 2 Oct 22:33
Gravatar

Re: Bugfix porting policy (was Re: Doc nits question)

Martin v. Löwis schrieb:
>> A large merge queue would accumulate making hard for someone to pick
>> out the bugfixes. Of course, people could just merge fixes right after
>> they apply it to the trunk, though.
> 
> I think they should. To my knowledge, nobody goes through the changelog
> anymore trying to find out what needs backporting. Tracking what still
> needs merging should happen in the bug tracker, by leaving the report
> open until merging has been done. Every change that isn't immediately
> merged and doesn't have an open issue just won't get merged at all.

This is why it's good to track what was merged and what not via svnmerge,
because it cannot miss commits. It also is easy for someone to select
which stuff to merge if the commit message on the trunk indicates
backportable fixes.

Georg

--

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
(Continue reading)

Permalink | Reply |
headers
Fred Drake | 2 Oct 15:56
Favicon
Gravatar

Re: Doc nits question

On Oct 2, 2008, at 9:21 AM, Georg Brandl wrote:
> I intend to set things up so that the docs at docs.python.org are  
> continually
> rebuilt, just like the /dev docs were until now.

Wonderful!  This should help avoid repeat reports of simple typos.

At one point, we started to separate the documentation releases so  
that update releases could be easily pushed at times when there wasn't  
a corresponding Python release.  There are a couple of examples of  
these in the specific-versions list, IIRC.  These have version numbers  
ending with "p1" (for patch 1; no more than one patched version was  
ever released for any particular Python version).

It may be worth trying this or something like it again as well, if  
there's enough volunteer time available.  Such versions would need to  
be clearly marked on every page as to when they were updated, so that  
readers can tell if they have the latest update.

   -Fred

--

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
(Continue reading)

Permalink | Reply |
headers
Georg Brandl | 2 Oct 19:17
Gravatar

Re: Doc nits question

Fred Drake schrieb:
> On Oct 2, 2008, at 9:21 AM, Georg Brandl wrote:
>> I intend to set things up so that the docs at docs.python.org are  
>> continually
>> rebuilt, just like the /dev docs were until now.
> 
> Wonderful!  This should help avoid repeat reports of simple typos.
> 
> At one point, we started to separate the documentation releases so  
> that update releases could be easily pushed at times when there wasn't  
> a corresponding Python release.  There are a couple of examples of  
> these in the specific-versions list, IIRC.  These have version numbers  
> ending with "p1" (for patch 1; no more than one patched version was  
> ever released for any particular Python version).
> 
> It may be worth trying this or something like it again as well, if  
> there's enough volunteer time available.  Such versions would need to  
> be clearly marked on every page as to when they were updated, so that  
> readers can tell if they have the latest update.

All Sphinx-generated pages currently have a "last update on:" in the footer.
Do you think that suffices for this purpose?

Georg

--

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.
(Continue reading)

Permalink | Reply |
headers
Fred Drake | 2 Oct 19:22
Favicon
Gravatar

Re: Doc nits question

On Oct 2, 2008, at 1:17 PM, Georg Brandl wrote:
> All Sphinx-generated pages currently have a "last update on:" in the  
> footer.
> Do you think that suffices for this purpose?

Yes, I do.

   -Fred

--

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |
headers
Terry Reedy | 3 Oct 02:54

Re: Doc nits question

Georg Brandl wrote:
> Fred Drake schrieb:
>> On Oct 2, 2008, at 9:21 AM, Georg Brandl wrote:
>>> I intend to set things up so that the docs at docs.python.org are  
>>> continually
>>> rebuilt, just like the /dev docs were until now.

Will you do the same for the 3.0 version?
http://docs.python.org/dev/3.0/

The following page has no reference to the 3.0 version
http://www.python.org/doc/versions/
The 'unreleased' link at the top goes to a link that only referenced the 
SVN version and not the built version above.  Adding a link to the build 
version would have made it easier to find ;-).

> All Sphinx-generated pages currently have a "last update on:" in the footer.
> Do you think that suffices for this purpose?

It certainly would limit a search for closed issues not incorporated in 
the update (to avoiding duplication).

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |
headers
Georg Brandl | 4 Oct 09:47
Gravatar

Re: Doc nits question

Terry Reedy schrieb:
> Georg Brandl wrote:
>> Fred Drake schrieb:
>>> On Oct 2, 2008, at 9:21 AM, Georg Brandl wrote:
>>>> I intend to set things up so that the docs at docs.python.org are  
>>>> continually
>>>> rebuilt, just like the /dev docs were until now.
> 
> Will you do the same for the 3.0 version?
> http://docs.python.org/dev/3.0/

Yes. Nothing has changed there.

> The following page has no reference to the 3.0 version
> http://www.python.org/doc/versions/
> The 'unreleased' link at the top goes to a link that only referenced the 
> SVN version and not the built version above.  Adding a link to the build 
> version would have made it easier to find ;-).

http://www.python.org/dev/doc/, where the link leads to, references both
trunk and 3.0 here.

Georg

--

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.
(Continue reading)

Permalink | Reply |
headers
Neal Norwitz | 3 Oct 06:04

Re: Doc nits question

On Thu, Oct 2, 2008 at 6:21 AM, Georg Brandl <g.brandl <at> gmx.net> wrote:
> Jesse Noller schrieb:
>> So, we just released and there are a few doc typo bugs being filed -
>> my question is if all doc-fixes have to wait for 2.6.1/2.7 or if we
>> can hotfix the 2.6 docs?
>
> I intend to set things up so that the docs at docs.python.org are continually
> rebuilt, just like the /dev docs were until now.

The 2.6 docs are now updated similar to how 2.5 was (hourly).  2.5
docs are no longer updated. In case you can't guess the url, it's:

http://docs.python.org/dev/2.6/

3.0 should continue to work.  Let me know if you have any problems.

n

>
> Georg
>
> --
> Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
> Four shall be the number of spaces thou shalt indent, and the number of thy
> indenting shall be four. Eight shalt thou not indent, nor either indent thou
> two, excepting that thou then proceed to four. Tabs are right out.
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev <at> python.org
(Continue reading)

Permalink | Reply |
headers
Nick Coghlan | 2 Oct 15:35

Re: Doc nits question

Jesse Noller wrote:
> So, we just released and there are a few doc typo bugs being filed -
> my question is if all doc-fixes have to wait for 2.6.1/2.7 or if we
> can hotfix the 2.6 docs?

Well the fixes can definitely all go in to SVN on both the trunk and the
maintenance branch.

As to when we update docs.python.org from the maintenance branch... I
believe historically it has only been done at each new maintenance
release, but I don't see any fundamental problems with the idea of
updating it more frequently.

Cheers,
Nick.

--

-- 
Nick Coghlan   |   ncoghlan <at> gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
            http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply |

Gmane