On Fri, Oct 3, 2008 at 7:06 AM, Nicholas Bastin <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, Oct 2, 2008 at 4:25 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
> wrote:
>>
>> > You always create a branch for the release (subversion doesn't make any
>> > distinction between a tag and a branch anyhow, so you
On Oct 2, 2008, at 6:26 PM, Benjamin Peterson wrote:
On Thu, Oct 2, 2008 at 4:51 PM, Jeff Senn <[EMAIL PROTECTED]> wrote:
Is whoever does the OS-X build on this list? I have problems
building the
Mac OS-X installer build using the build script in the tarball...
(Could there be uncommitte
> creating a branch for the release is no option?
It might be, but that's for the release manager to decide, and
he has chosen the alternative option of freezing the repository.
> that's odd, because I
> do that all the time. i.e.
>
>1 - create trunk snapshot by branching
>2 - build re
On Thu, Oct 2, 2008 at 4:51 PM, Jeff Senn <[EMAIL PROTECTED]> wrote:
>
> Is whoever does the OS-X build on this list? I have problems building the
> Mac OS-X installer build using the build script in the tarball...
>
> (Could there be uncommitted changes to Mac/BuildScript/build-installer.py?)
I
> I guess my question is, is there a normal use case where the code needs
> to be changed for a release after the 'tag' is made? If all the changes
> are getting committed before the release tag is made, then what is the
> problem?
The changes that need to be made are committed to the trunk (or th
Is whoever does the OS-X build on this list? I have problems building
the
Mac OS-X installer build using the build script in the tarball...
(Could there be uncommitted changes to Mac/BuildScript/build-
installer.py?)
-Jas
On Oct 2, 2008, at 2:39 PM, Barry Warsaw wrote:
-BEGIN PGP S
Fred Drake wrote:
> On Oct 2, 2008, at 9:39 AM, Nick Coghlan wrote:
>> If you don't make a habit of borking your own filesystems with dodgy
>> filenames, it runs fine.
>
> I really hope the individuals making this argument are being facetious.
> I don't think this is the source of the problem at
On Thu, Oct 2, 2008 at 5:08 PM, Fredrik Lundh <[EMAIL PROTECTED]>wrote:
> > How do you create the release tag so that it contains change
> > sets A and A+2, but not A+1? (and no, creating a branch just for
> > the release is no option, because that means you have to copy all
> > the changes you ma
> How do you create the release tag so that it contains change
> sets A and A+2, but not A+1? (and no, creating a branch just for
> the release is no option, because that means you have to copy all
> the changes you made on the branch back to the trunk)
creating a branch for the release is no opti
On Thu, Oct 2, 2008 at 4:25 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>wrote:
> > You always create a branch for the release (subversion doesn't make any
> > distinction between a tag and a branch anyhow, so you might as well just
> > make a branch).
>
> I don't think the tag should be edited (there
> You always create a branch for the release (subversion doesn't make any
> distinction between a tag and a branch anyhow, so you might as well just
> make a branch).
I don't think the tag should be edited (there are a few that were, and
that's unfortunate already). For example, conversion to bzr
On Thu, Oct 2, 2008 at 3:55 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>wrote:
>
> Suppose you have three subsequent revisions in the trunk:
>
> A contains what you originally wanted to tag
> A+1 contains a change by somebody else, not to be released
> A+2 is the change that you made to fix a bug you
On 2008-10-02 19:08, Fred Drake wrote:
> On Oct 2, 2008, at 9:39 AM, Nick Coghlan wrote:
>> If you don't make a habit of borking your own filesystems with dodgy
>> filenames, it runs fine.
>
> I really hope the individuals making this argument are being facetious.
> I don't think this is the sour
>> If there's a screwup, and you need to recut the branch, you want to be
>> sure someone else hasn't been helpful and added something else to the
>> repo.
>
> But you can put the tag/create the branch in any revision you want...
Suppose you have three subsequent revisions in the trunk:
A contai
On Oct 2, 2008, at 3:08 PM, Martin v. Löwis wrote:
I'm still in favor of a solution that doesn't divide the APIs into
"character file names" and "byte file names"; I want the "character
file names" to work always. However, I find it completely unrealistic
to make this work in Python 3.0.
Ok, t
On Thu, Oct 2, 2008 at 12:08 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I'm still in favor of a solution that doesn't divide the APIs into
> "character file names" and "byte file names"; I want the "character
> file names" to work always.
I wish we could do that too, but I don't see how to
> At about the same time, Martin said:
>> I agree. I disagree that you should be able to do so with Python 3.0
>> (although it looks like you might).
>
> Why do you disagree that I should be able to do this with Python 3.0?
> (I can guess, but that just increases the likelihood that I'll be wrong
> That doesn't mean it's not scary when thinking about writing portable
> code in this environment. That's not entirely new, but the fact that so
> much of these details are being addressed so late in the release cycle
> *should* give cause for concern, especially to those of use who are
> still a
On Oct 2, 2008, at 2:46 PM, Guido van Rossum wrote:
It's really not very invasive, and not much changes -- the changes are
mostly in our minds, as we now have all learned about the issues and
the differences between platforms, and know what to tell people to do
about them. *That* is the major cha
> If someone hands me a USB flash drive with filenames encoded in whatever
> is reasonable for them, I should be able to use Python tools on the
> files without having to use non-Python tools to copy or rename the file
> first.
I agree. I disagree that you should be able to do so with Python 3.0
(
On Thu, Oct 2, 2008 at 11:11 AM, Fred Drake <[EMAIL PROTECTED]> wrote:
> That doesn't mean it's not scary when thinking about writing portable code
> in this environment. That's not entirely new, but the fact that so much of
> these details are being addressed so late in the release cycle *should*
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It was pointed out that the source tarballs I uploaded had some cruft
in them that they shouldn't have, such as svn turds and whatnot.
I've generated new tarballs with that stuff deleted. I do /not/ want
to bump the Python version number for th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 2, 2008, at 2:20 AM, Ronald Oussoren wrote:
On 2 Oct, 2008, at 8:08, Martin v. Löwis wrote:
You're absolutely right and that sounds good. I will update the PEP
accordingly. Martin, Ronald, Sean, what timezones are you in? I am
US/Easter
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 2, 2008, at 2:08 AM, Martin v. Löwis wrote:
You're absolutely right and that sounds good. I will update the PEP
accordingly. Martin, Ronald, Sean, what timezones are you in? I am
US/Eastern.
I'm in CET (Central European), that GMT+2 in D
On Oct 2, 2008, at 1:53 PM, Guido van Rossum wrote:
we have no choice of coming up with a way of encoding all possible
byte sequences into Unicode strings, using a reversible encoding. This
has been shown to be hard no matter what encoding you favor -- as soon
as those "Unicode" strings are passe
I forgot one thing. In the *long* run I expect the problem to go away
-- UTF-8 is going to win out. But this is years off, and that's why we
need to support non-UTF-8-encoded filenames in the short and medium
term. And this can be many years.
--
--Guido van Rossum (home page: http://www.python.or
On Thu, Oct 2, 2008 at 10:08 AM, Fred Drake <[EMAIL PROTECTED]> wrote:
> On Oct 2, 2008, at 9:39 AM, Nick Coghlan wrote:
>>
>> If you don't make a habit of borking your own filesystems with dodgy
>> filenames, it runs fine.
>
> I really hope the individuals making this argument are being facetious.
On Oct 2, 2008, at 9:39 AM, Nick Coghlan wrote:
If you don't make a habit of borking your own filesystems with dodgy
filenames, it runs fine.
I really hope the individuals making this argument are being
facetious. I don't think this is the source of the problem at all.
The expect the most
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Anthony Baxter wrote:
> If there's a screwup, and you need to recut the branch, you want to be
> sure someone else hasn't been helpful and added something else to the
> repo.
But you can put the tag/create the branch in any revision you want...
In fa
2008/10/2 Guido van Rossum <[EMAIL PROTECTED]>:
> No need to be sneaky about it, go right ahead. I don't think we should
> retroactively rename rc1 to beta4, but we can certainly label the next
> release as beta5, with an explanation, and the first real release
> candidate should be called rc2 to
On Thu, Oct 2, 2008 at 9:36 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Oct 2, 2008, at 12:31 PM, Raymond Hettinger wrote:
>
>>> IMHO if there's still big scary stuff out there, calling this a
>>> release candidate does us no good PR-wise, and does no good for our
>>> users. 3.0 is going to be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 2, 2008, at 12:31 PM, Raymond Hettinger wrote:
IMHO if there's still big scary stuff out there, calling this a
release candidate does us no good PR-wise, and does no good for our
users. 3.0 is going to be scary enough for them as it is - cutt
IMHO if there's still big scary stuff out there, calling this a
release candidate does us no good PR-wise, and does no good for our
users. 3.0 is going to be scary enough for them as it is - cutting a
release candidate that we either know is broken, or else has
significant changes, is a very bad i
IMHO if there's still big scary stuff out there, calling this a
release candidate does us no good PR-wise, and does no good for our
users. 3.0 is going to be scary enough for them as it is - cutting a
release candidate that we either know is broken, or else has
significant changes, is a very bad id
Fred Drake wrote:
> On Oct 2, 2008, at 8:59 AM, Nick Coghlan wrote:
>> A big +1 from me for declaring it still in beta until all the 3.0
>> release blockers are fixed.
>
> +1 from me as well. From what I've read about the pathname issues, I'm
> pretty worried about the usability of 3.0.
If you d
On Oct 2, 2008, at 8:59 AM, Nick Coghlan wrote:
A big +1 from me for declaring it still in beta until all the 3.0
release blockers are fixed.
+1 from me as well. From what I've read about the pathname issues,
I'm pretty worried about the usability of 3.0.
-Fred
--
Fred L. Drake, Jr.
Barry Warsaw wrote:
> We should reconsider whether 3.0 is ready for release candidates.
> Perhaps it makes more sense to rename rc1 to beta4 and fix some of these
> blockers. Now that 2.6 is (mostly) out of the way, we can concentrate
> on getting 3.0 right.
Yes, with Victor's filesystem decodin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 2, 2008, at 2:47 AM, Martin v. Löwis wrote:
I propose that the release of 3.0rc2 is deferred until all release
blockers have been resolved (either by actually fixing them, or by
carefully considering that they shouldn't actually block the rel
Le mercredi 01 octobre 2008 à 23:24 -0400, Barry Warsaw a écrit :
> P.S. The release26-maint branch is now open for 2.6.1.
I have created a Mercurial mirror (actually, two) for it.
http://code.python.org/hg/
Half OT, but Mercurial users can also help review the Mercurial support
patch for Rietvel
Martin> I propose that the release of 3.0rc2 is deferred until all
Martin> release blockers have been resolved (either by actually fixing
Martin> them, or by carefully considering that they shouldn't actually
Martin> block the release).
+1. Even though it's not 3.0-specific, I th
On 2 Oct, 2008, at 8:08, Martin v. Löwis wrote:
You're absolutely right and that sounds good. I will update the PEP
accordingly. Martin, Ronald, Sean, what timezones are you in? I am
US/Eastern.
I'm in CET (Central European), that GMT+2 in DST, and GMT+1 otherwise.
I'm in CET as wel.
Ro
On Thu, Oct 2, 2008 at 4:47 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I propose that the release of 3.0rc2 is deferred until all release
> blockers have been resolved (either by actually fixing them, or by
> carefully considering that they shouldn't actually block the release).
>
> What el
42 matches
Mail list logo
