Distribute 0.6.7 this week

[Tarek Ziadé]

Hello

We are going to release 0.6.7 this week. Among some new bugs fixes, we
want to provide a specific change that will
allow virtualenv to be released with an option to use Distribute
instead of Setuptools, like zc.buildout.

$ virtualenv --distribute ENV

If you want to see another bug fixed in this release,  speak up !
(http://bitbucket.org/tarek/distribute/issues)

Regards
Tarek

--
Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[ssteiner]

On Oct 27, 2009, at 4:53 AM, Tarek Ziadé wrote:

> Hello
>
> We are going to release 0.6.7 this week. Among some new bugs fixes, we
> want to provide a specific change that will
> allow virtualenv to be released with an option to use Distribute
> instead of Setuptools, like zc.buildout.
>
> $ virtualenv --distribute ENV
>
> If you want to see another bug fixed in this release,  speak up !
> (http://bitbucket.org/tarek/distribute/issues)

I don't necessarily have a request bug-wise, but maybe this would be a  
good time to coordinate the upgrading of the test suite with the  
release.

Maybe something like a TEST_README documenting the tests that prove  
the that the closed ticket's bugs have a test that proves that the  
former bad behaviour was fixed.

S

_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Tarek Ziadé]

On Tue, Oct 27, 2009 at 3:12 PM, ssteinerX@...
<ssteinerx@...> wrote:

>
> On Oct 27, 2009, at 4:53 AM, Tarek Ziadé wrote:
>
>> Hello
>>
>> We are going to release 0.6.7 this week. Among some new bugs fixes, we
>> want to provide a specific change that will
>> allow virtualenv to be released with an option to use Distribute
>> instead of Setuptools, like zc.buildout.
>>
>> $ virtualenv --distribute ENV
>>
>> If you want to see another bug fixed in this release,  speak up !
>> (http://bitbucket.org/tarek/distribute/issues)
>
> I don't necessarily have a request bug-wise, but maybe this would be a good
> time to coordinate the upgrading of the test suite with the release.
>
> Maybe something like a TEST_README documenting the tests that prove the that
> the closed ticket's bugs have a test that proves that the former bad
> behaviour was fixed.

Maybe a simpler way would be to use Bitbucket issue tracker features ?

For the last two bugs I've fixed, they have a corresponding test in the commit.
And if you go to the issue, you have a link to the commit with a diff,
so you can see it.

That's done with the special "fixes #N" bit in the commit messages,
where N is the issue number.
Bitbuckets links the tyicket with the commits when its pushed there.

So we could maybe add the link to the issue in CHANGES ?

Although some parts are cleary undertested yet, so even if it's
unpleasant to add tests
in an undertested code base, I am +1 in making the tests mandatory
when the code is not yet covered
for now on

Tarek
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[ssteiner]

On Oct 27, 2009, at 10:21 AM, Tarek Ziadé wrote:

>> Maybe something like a TEST_README documenting the tests that prove  
>> the that
>> the closed ticket's bugs have a test that proves that the former bad
>> behaviour was fixed.
>
> Maybe a simpler way would be to use Bitbucket issue tracker features ?

Are you suggesting maybe getting at that through the (undocumented)  
API, or something else?

> For the last two bugs I've fixed, they have a corresponding test in  
> the commit.
> And if you go to the issue, you have a link to the commit with a diff,
> so you can see it.
>
> That's done with the special "fixes #N" bit in the commit messages,
> where N is the issue number.  Bitbuckets links the tyicket with the  
> commits when its pushed there.  So we could maybe add the link to  
> the issue in CHANGES ?

I'm not sure what mechanisms we have for this, do you know?

> Although some parts are cleary undertested yet, so even if it's
> unpleasant to add tests in an undertested code base, I am +1 in  
> making the tests mandatory when the code is not yet covered for now on

That was what we discussed at the sprint and I'm doing what I feel is  
my job as QA PITA (pain in the ass) by insisting that A> we have tests  
for anything fixed and especially not covered and B> that we document  
the test related to the fix so that whomever reported the bug can  
verify that the test does indeed cover the use-case they reported.

What is the next step?

S

_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Tarek Ziadé]

On Tue, Oct 27, 2009 at 3:26 PM, ssteinerX@...
<ssteinerx@...> wrote:
>> That's done with the special "fixes #N" bit in the commit messages,
>> where N is the issue number.  Bitbuckets links the tyicket with the
>> commits when its pushed there.  So we could maybe add the link to the issue
>> in CHANGES ?
>
> I'm not sure what mechanisms we have for this, do you know?

Yes, I use it. I have added this feature in the admin panel, provided
by Bitbucket:

$ hg ci -m "blablablba fixes #12"   -> add a link to the diff in the
issue #12 and close it

$ hg ci -m "blablablba refs #12"   -> add a link to the diff in the
issue #12, but don't close it.

>
>> Although some parts are cleary undertested yet, so even if it's
>> unpleasant to add tests in an undertested code base, I am +1 in making the
>> tests mandatory when the code is not yet covered for now on
>
> That was what we discussed at the sprint and I'm doing what I feel is my job
> as QA PITA (pain in the ass) by insisting that A> we have tests for anything
> fixed and especially not covered and B> that we document the test related to
> the fix so that whomever reported the bug can verify that the test does
> indeed cover the use-case they reported.
>
> What is the next step?

That sounds very cool ! As the QA master I guess your next steps would be:

- to set up a bbot for distribute (you can PV me so we can work on the
details with Titus that has offered some slave hosting too)

-  to watch all commits going on and blame people that don't do tests,
or make comments on the quality of the commited code. An extra pair of
eyes is great for that. Granted that we could all do that, but QA
needs a lead or it slowly dies imho.

I think we would all very appreciate it if you could help on this!

Tarek
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig