User testing for 0.0.1 releases

[Steve McMahon]

Several folks said today in a discussion on #plone that they would be happy to test 0.0.1 version increments for Plone if it could be made easy enough.

David Glick proposed that we could have something like a plone.recipe.plonerc recipe that would solve the chicken-and-egg problem of how to easily test a release recipe without endangering those with unpinned plone.recipe.plone recipes.

Would it be worth doing something like that a week before a planned 0.0.1 increment release?

--

______________________________________________________

Steve McMahon
Reid-McMahon, LLC
steve@...
steve@...

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Wichert Akkerman]

Previously Steve McMahon wrote:

> Several folks said today in a discussion on #plone that they would be happy
> to test 0.0.1 version increments for Plone if it could be made easy enough.
>
> David Glick proposed that we could have something like a
> plone.recipe.plonerc recipe that would solve the chicken-and-egg problem of
> how to easily test a release recipe without endangering those with unpinned
> plone.recipe.plone recipes.
>
> Would it be worth doing something like that a week before a planned 0.0.1
> increment release?

I think a much simpler and incredibly useful start would be to have
people test the current ploneout code. That is not difficult and would
be incredibly valuable.

Wichert.

--
Wichert Akkerman <wichert@...>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[David Glick-2]

On Jul 19, 2008, at 8:08 AM, Wichert Akkerman wrote:

> Previously Steve McMahon wrote:
>> Several folks said today in a discussion on #plone that they would  
>> be happy
>> to test 0.0.1 version increments for Plone if it could be made easy  
>> enough.
>>
>> David Glick proposed that we could have something like a
>> plone.recipe.plonerc recipe that would solve the chicken-and-egg  
>> problem of
>> how to easily test a release recipe without endangering those with  
>> unpinned
>> plone.recipe.plone recipes.
>>
>> Would it be worth doing something like that a week before a planned  
>> 0.0.1
>> increment release?
>
> I think a much simpler and incredibly useful start would be to have
> people test the current ploneout code. That is not difficult and would
> be incredibly valuable.

-1 if you mean plone-coredev from trunk, which is a good bit different  
from maintenance releases in the 3.1 branch.

However, I missed the fact that there is a 3.1 branch of the plone-
coredev buildout, and that does seem like a reasonable way to get  
things for testing before the release (assuming it is kept up to date).

Two caveats though:
1. The people who would make the best testers (because they actually  
use Plone more often than core developers) tend to be the people who  
are still less comfortable with buildout.
2. Some issues may not become evident until integrating with other  
products and systems, and a plonerc recipe would be easier to  
integrate with an existing buildout incorporating such things.

But I'm willing to try to get people testing using plone-coredev  
first, and try something else later if that doesn't work.

David Glick
Project Associate
ONE/Northwest

New tools and strategies for engaging people in protecting the  
environment

http://www.onenw.org
davidglick@...
[phone] x32

Subscribe to ONEList, our email newsletter!
Practical advice for effective online engagement
http://www.onenw.org/full_signup




-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Steve McMahon]

On Sat, Jul 19, 2008 at 8:08 AM, Wichert Akkerman <wichert@...> wrote:

...

I think a much simpler and incredibly useful start would be to have
people test the current ploneout code. That is not difficult and would
be incredibly valuable.

That would be valuable, but it's not going to get testing from folks who don't find svn checkouts easy -- and those were the kind of volunteers we were seeing on IRC yesterday. Even one week of RC testing might have caught the pvc problem in 3.1.3.

Previously Steve McMahon wrote:
> Several folks said today in a discussion on #plone that they would be happy
> to test 0.0.1 version increments for Plone if it could be made easy enough.
>
> David Glick proposed that we could have something like a
> plone.recipe.plonerc recipe that would solve the chicken-and-egg problem of
> how to easily test a release recipe without endangering those with unpinned
> plone.recipe.plone recipes.
>
> Would it be worth doing something like that a week before a planned 0.0.1
> increment release?

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Wichert Akkerman]

David Glick wrote:

> On Jul 19, 2008, at 8:08 AM, Wichert Akkerman wrote:
>
>> Previously Steve McMahon wrote:
>>> Several folks said today in a discussion on #plone that they would
>>> be happy
>>> to test 0.0.1 version increments for Plone if it could be made easy
>>> enough.
>>>
>>> David Glick proposed that we could have something like a
>>> plone.recipe.plonerc recipe that would solve the chicken-and-egg
>>> problem of
>>> how to easily test a release recipe without endangering those with
>>> unpinned
>>> plone.recipe.plone recipes.
>>>
>>> Would it be worth doing something like that a week before a planned
>>> 0.0.1
>>> increment release?
>>
>> I think a much simpler and incredibly useful start would be to have
>> people test the current ploneout code. That is not difficult and would
>> be incredibly valuable.
>
>
> -1 if you mean plone-coredev from trunk, which is a good bit different
> from maintenance releases in the 3.1 branch.

ploneout (I'm sticking to the name - I like it so much more than
plone-coredev) trunk is only for the very brave. Every release since 2.5
has its own ploneout branches (2.5, 3.0 and 3.1 now) which should be
just as stable as the releases made from those branches.

> However, I missed the fact that there is a 3.1 branch of the
> plone-coredev buildout, and that does seem like a reasonable way to
> get things for testing before the release (assuming it is kept up to
> date).
>
> Two caveats though:
> 1. The people who would make the best testers (because they actually
> use Plone more often than core developers) tend to be the people who
> are still less comfortable with buildout.
> 2. Some issues may not become evident until integrating with other
> products and systems, and a plonerc recipe would be easier to
> integrate with an existing buildout incorporating such things.
>
> But I'm willing to try to get people testing using plone-coredev
> first, and try something else later if that doesn't work.

I think that would be an excellent start.

Wichert.

--
Wichert Akkerman<wichert@...>    It is simple to make things.
http://www.wiggy.net/                  It is hard to make things simple.


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Andreas Zeidler]

Wichert Akkerman wrote:

> Previously Steve McMahon wrote:
>> Several folks said today in a discussion on #plone that they would be happy
>> to test 0.0.1 version increments for Plone if it could be made easy enough.
>>
>> David Glick proposed that we could have something like a
>> plone.recipe.plonerc recipe that would solve the chicken-and-egg problem of
>> how to easily test a release recipe without endangering those with unpinned
>> plone.recipe.plone recipes.
>>
>> Would it be worth doing something like that a week before a planned 0.0.1
>> increment release?
>
> I think a much simpler and incredibly useful start would be to have
> people test the current ploneout code. That is not difficult and would
> be incredibly valuable.

why the different name/egg?  couldn't we just have an rc release of
plone.recipe.plone a bit ahead of the regular one?  of course that would
mean the package release deadline needs to be adjusted by that time
span, but giving new releases a few days to be more widely tested and
settle down would be good anyway.


andi

--
zeidler it consulting - http://zitc.de/ - info@...
friedelstraße 31 - 12047 berlin - telefon [phone]
pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/
plone 3.1.3 released! -- http://plone.org/products/plone/


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Andreas Zeidler]

Andreas Zeidler wrote:
> why the different name/egg?  couldn't we just have an rc release of
> plone.recipe.plone a bit ahead of the regular one?  of course that would
> mean the package release deadline needs to be adjusted by that time
> span, but giving new releases a few days to be more widely tested and
> settle down would be good anyway.

as florian pointed out this doesn't work, of course as the recipe itself
isn't pinned (in most buildouts).

so please just ignore me :)


> andi

--
zeidler it consulting - http://zitc.de/ - info@...
friedelstraße 31 - 12047 berlin - telefon [phone]
pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/
plone 3.1.3 released! -- http://plone.org/products/plone/


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers