headers
Christian Boos | 1 Apr 22:23
Picon

[Trac-dev] Re: Towards a 0.11 release


Hi,

I'd like to propose a few steps to get us moving forward on the 0.11 
topic, as we're gradually getting to the feature set we wanted to have. 
A lot has already been done in the past 8 months, but there's definitely 
some work ahead of us. There are currently a few working branches that 
could be integrated:
 - genshi510
 - pycon/workflow
 - security
 - vc-refactoring
 - pycon/render-filter

In particular, there's genshi510 that could probably benefit a lot to be 
on the trunk, so that we can fix the remaining issues as we see them. 
That was probably the initial intent of cmlenz when he did the changes 
directly on trunk. The problem I had with this approach was that it 
broke the usability status of trunk for an unspecified amount of time, 
while there were a lot of people  trying out trunk on the assumption 
that it was stable enough for their needs. I didn't want to break this 
assumption in people's mind, as I think it's actually a very good thing 
that we have people trying out trunk and willing to report the few 
occasional issues they might stumble upon. So I moved those changes on a 
stabilization branch, and as a result the trunk was indeed usable again 
but the branch has stalled...

So what I'd like to do instead is to release a 0.11beta1, as trunk 
stands now, and let people know that they should use this if they want 
to try out 0.11dev, because the trunk will become temporarily quite
(Continue reading)

Permalink | Reply | 12 comments |
headers
Emmanuel Blot | 2 Apr 00:06
Picon
Gravatar

[Trac-dev] Re: Towards a 0.11 release


> So what I'd like to do instead is to release a 0.11beta1, as trunk
> stands now, and let people know that they should use this if they want
> to try out 0.11dev, because the trunk will become temporarily quite
> "unstable".

Why not upgrading the genshi-510 branch instead, rather than breaking the trunk?

As a user, I would have prefered to keep the trunk usable.
I think it is better for new comers too, as it seems 'natural' to
check out the main development branch when one wants to give a try to
Trac - and expect it to work - rather than seeking document pages to
finally found the piece of info that says that "sorry guys, the trunk
cannot be used for now" ;-)

Installing Trac is already a bit frustrating for new comers, I don't
think breaking down the trunk will help improving this common
feeling...

Maybe it would be cleaner to decide that no one should commit to the
trunk - except for fixing critical/blocker issues - till the
genshi-510 branch is ready and finally merged. This would avoid
breaking down the trunk, and ensure that the genshi branch is kept
active.

OTOH, I hope the security branch and the workflow branch to be merged
soon, in order to create the new "notification" branch (as already
discussed in a previous thread) ;-)

Cheers,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeffrey Hulten | 2 Apr 03:04
Gravatar

[Trac-dev] Re: Towards a 0.11 release


In my job as release manager for a internet marketing company this is  
exactly what we do.  I would say make a fresh branch from trunk,  
merge the changes in the existing branch over and then you can  
resolve conflicts and bug in that area with less concern of bit rot.   
When it is ready merge it into trunk...

On Apr 1, 2007, at 3:06 PM, Emmanuel Blot wrote:

>
>> So what I'd like to do instead is to release a 0.11beta1, as trunk
>> stands now, and let people know that they should use this if they  
>> want
>> to try out 0.11dev, because the trunk will become temporarily quite
>> "unstable".
>
> Why not upgrading the genshi-510 branch instead, rather than  
> breaking the trunk?
>
> As a user, I would have prefered to keep the trunk usable.
> I think it is better for new comers too, as it seems 'natural' to
> check out the main development branch when one wants to give a try to
> Trac - and expect it to work - rather than seeking document pages to
> finally found the piece of info that says that "sorry guys, the trunk
> cannot be used for now" ;-)
>
> Installing Trac is already a bit frustrating for new comers, I don't
> think breaking down the trunk will help improving this common
> feeling...
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alec Thomas | 2 Apr 03:15

[Trac-dev] Re: Towards a 0.11 release


On 4/2/07, Christian Boos <cboos <at> neuf.fr> wrote:
>  - security

I'm going to finish off the changes I did at PyCon, get feedback and
get this merged soon. I think the sandbox/security branch is too
intrusive, but the sandbox/pycon/security branch is nice and small,
while still offering the same flexibility.

>  - pycon/render-filter

Noah can comment more about this, but I think cmlenz in particular
should definitely take a look. I expect this API to get heavy use
after it's released.

> "unstable". We'll then merge genshi510, then the workflow branch. One,
> two, three weeks later at most, things will have settled down again and
> trunk will recover its "usable" status.

Has everybody had time to review workflow? I know I haven't looked at
it for a couple of weeks. Even though the change itself is not that
large, I think the fact SO many people will use it once it goes live
warrants extra scrutiny to make sure we have a nice solid API.

--

-- 
Evolution: Taking care of those too stupid to take care of themselves.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeroen Ruigrok van der Werven | 2 Apr 10:00
Gravatar

[Trac-dev] Re: Towards a 0.11 release


-On [20070401 22:23], Christian Boos (cboos <at> neuf.fr) wrote:
>In particular, there's genshi510 that could probably benefit a lot to be 
>on the trunk, so that we can fix the remaining issues as we see them. 

Right now trying to install trunk fails on:

Installed /usr/local/lib/python2.5/site-packages/Trac-0.11dev_r5162-py2.5.egg
Processing dependencies for Trac==0.11dev-r5162
Searching for Genshi>=0.4dev-r493,<0.4dev-r510
Reading http://cheeseshop.python.org/pypi/Genshi/
Reading http://genshi.edgewall.org/
Reading http://genshi.edgewall.org/wiki/Download
Reading http://cheeseshop.python.org/pypi/Genshi/0.3.6
No local packages or download links found for Genshi>=0.4dev-r493,<0.4dev-r510
error: Could not find suitable distribution for
Requirement.parse('Genshi>=0.4dev-r493,<0.4dev-r510')

Of course I have Genshi-0.4dev_r527-py2.5.egg installed. ;) I think it would
be better to cut a Genshi release and use that for Trac 0.11. Most
installations will not be tracking SVN (nor do a lot of hosting companies
allow such shared installations) and need released versions.

--

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
About all you can do in life is be who you are. Some people will love you
for you. Most will love you for what you can do for them, and some won't like
you at all.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christopher Lenz | 2 Apr 13:06
Picon
Picon
Gravatar

[Trac-dev] Re: Towards a 0.11 release


Am 01.04.2007 um 22:23 schrieb Christian Boos:
> I'd like to propose a few steps to get us moving forward on the 0.11
> topic, as we're gradually getting to the feature set we wanted to  
> have.
> A lot has already been done in the past 8 months, but there's  
> definitely
> some work ahead of us. There are currently a few working branches that
> could be integrated:
>  - genshi510
>  - pycon/workflow
>  - security
>  - vc-refactoring
>  - pycon/render-filter
>
> In particular, there's genshi510 that could probably benefit a lot  
> to be
> on the trunk, so that we can fix the remaining issues as we see them.
> That was probably the initial intent of cmlenz when he did the changes
> directly on trunk. The problem I had with this approach was that it
> broke the usability status of trunk for an unspecified amount of time,
> while there were a lot of people  trying out trunk on the assumption
> that it was stable enough for their needs. I didn't want to break this
> assumption in people's mind, as I think it's actually a very good  
> thing
> that we have people trying out trunk and willing to report the few
> occasional issues they might stumble upon. So I moved those changes  
> on a
> stabilization branch, and as a result the trunk was indeed usable  
> again
(Continue reading)

Permalink | Reply | 3 comments |
headers
Christian Boos | 2 Apr 13:32
Picon

[Trac-dev] Re: Towards a 0.11 release


Christopher Lenz wrote:
> Am 01.04.2007 um 22:23 schrieb Christian Boos:
>   
>> ... So I moved those changes  
>> on a
>> stabilization branch, and as a result the trunk was indeed usable  
>> again
>> but the branch has stalled...
>>     
>
> FYI, I consider it bad style to move someone else's changes to a  
> "stabilization branch" without any kind of notice or dicussion on  
> this list. 

One can consider equally bad style to break the relative stability of 
trunk without any kind of notice or discussion on the list as well.

> I've put a lot of work into those changes, and while I may  
> have missed some places, it would've been better to just fix those --  
>   

Like in "after me the deluge?" ... Well, frankly I had no idea of the 
extent of the changes required, and I didn't want to take the burden to 
clean up the mess after everything went loose. It's true that normally I 
tend to take care of such details, but at that time I was quite busy 
with other things (resync fixes), and didn't want to get distracted. If 
you had brought up the issue on the list in the first place, I would 
have got the chance to raise this timing issue.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christopher Lenz | 2 Apr 14:37
Picon
Picon
Gravatar

[Trac-dev] Re: Towards a 0.11 release


Am 02.04.2007 um 13:32 schrieb Christian Boos:
> Christopher Lenz wrote:
>> Am 01.04.2007 um 22:23 schrieb Christian Boos:
>>
>>> ... So I moved those changes
>>> on a
>>> stabilization branch, and as a result the trunk was indeed usable
>>> again
>>> but the branch has stalled...
>>>
>>
>> FYI, I consider it bad style to move someone else's changes to a
>> "stabilization branch" without any kind of notice or dicussion on
>> this list.
>
> One can consider equally bad style to break the relative stability of
> trunk without any kind of notice or discussion on the list as well.

Yeah, I should've announced those changes. Sorry about that.

I'm working on making the necessary changes again *right now*... This  
time, I'm trying to do that without relying on the new defined() and  
value_of() functions, so that Trac will continue to work with  
previous 0.4dev versions, so that people can keep using pre r510  
Genshi versions, and not see any breakage during the transition.

>>> So what I'd like to do instead is to release a 0.11beta1, as trunk
>>> stands now, and let people know that they should use this if they  
>>> want
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christian Boos | 2 Apr 14:56
Picon

[Trac-dev] Re: Towards a 0.11 release


Christopher Lenz wrote:
> ...
> Yeah, I should've announced those changes. Sorry about that.
>   

Well, the only harm was that this prompted me to take some actions that 
you later considered to be harmful, and I'm sorry about that as well :-) 
All I wanted is that we avoided to get flooded by lots of minor bug 
reports, during that week-end.

So hopefully we're now all in a good and productive mood again!

> I'm working on making the necessary changes again *right now*... This  
> time, I'm trying to do that without relying on the new defined() and  
> value_of() functions, so that Trac will continue to work with  
> previous 0.4dev versions, so that people can keep using pre r510  
> Genshi versions, and not see any breakage during the transition.
>   

Great! That's indeed the best solution.

Still, I think that we should consider merging the workflow branch just 
after that.
One of the idea of the "let's merge everything" proposal was that we 
could have done the genshi 510 related fixes for the ticket template 
directly on the workflow ticket.html, instead of having to do them twice 
(with probably some merge hassle in between).

-- Christian
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eli Carter | 2 Apr 16:36

[Trac-dev] Re: WorkFlow: customizable state transitions


On Saturday 31 March 2007, Pavel Kourochka wrote:
> 
> Hi Eli,
> Workflow code needs to be corrected in order to resolve the problem
> with multiple selected options. See
> http://genshi.edgewall.org/ticket/109#comment:1 for details.

Great, thank you.  I applied the patch to the workflow branch.

Eli

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 0 comments |

Gmane