Towards a 0.11 release

Hello,

As more and more people start to ask when 0.11 will be
released, I 
wanted to discuss the topic here.

I think that we can now start to schedule /new/ enhancements
tickets to 
0.12, directly.
The same for things that look like being either long
standing issues or 
non important bugs. Bug reports against defects directly
related to or 
introduced by 0.11 should of course still be scheduled for
the 0.11 
milestone.

We should also start to move some of the existing opened
0.11 tickets to 
either 0.12 or a new 0.10.1, for things we don't absolutely
wish to have 
for a 0.11.

I'll do that triage for my own 74 tickets, which leaves 90
tickets for 
the other owners.
If you don't feel like doing this for your own tickets,
please at least 
say so, so that others (not necessarily me) could do this
triaging for you.

I think this month will still see some heavy changes, like
the ticket 
preview changes and hopefully other outcomes from Pycon
(workflow, 
security, ...?), as well as my wiki refactoring, if I manage
to find 
enough time to get it in shape, so that we could think about
a 0.11beta1 
release early next month.

I have the feeling that we're just /starting/ to see 0.10.3
widely 
deployed, with 0.9 becoming now an exception rather than the
rule, so I 
think there's also no big reason to rush for a 0.11 release
before we 
feel we're ready with it, so that we can safely finish what
has already 
been started.

-- Christian



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

On Tue, Mar 06, 2007 at 12:39:15PM +0100, Christian Boos
wrote:
> I think this month will still see some heavy changes,
like the ticket 
> preview changes and hopefully other outcomes from Pycon
(workflow, 

Ticket preview is phase 1 of workflow, so it's already
beginning .

Eli and I discussed this, and thought that the actual
"ticket action
controller" logic would be the next change for
Workflow. This would
probably be the biggest win as far as end users are
concerned. Behind
the scenes cleanup such as merging the logic of
newticket/viewticket can
be done after this with little/zero impact.

> 
> I have the feeling that we're just /starting/ to see
0.10.3 widely 
> deployed, with 0.9 becoming now an exception rather
than the rule, so I 
> think there's also no big reason to rush for a 0.11
release before we 
> feel we're ready with it, so that we can safely finish
what has already 
> been started.

I'm not particularly sold on releasing early just
"because", so yeah,
I'd rather wait until at least WorkFlow is integrated. I'm
pretty sure
that's the big change most people are waiting for in 0.11.
That and
security, although security is a smaller and less intrusive
change.

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

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 
"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.

Once the workflow is in, I think there are a few very
popular feature 
requests that it would be nice to fulfill: #454 and #4100.

I'll try to find some time to give some more details on the
other topics 
I'm currently working on, and which I'd like to finish or at
least put 
in "good enough" shape for 0.11, but here's a
quick overview:
 - the simplification/clarification of the WikiContext API,
emphasizing 
more its resource descriptor aspect, and the update of the
security branch
 - the vc-refactoring, started with Peter, which only
simplifies the 
versioncontrol/web_ui modules (no change of functionality).
This 
reintroduces some of the ideas of the controller branch from

Christopher. Further developments to come soon.
 - ... then the wiki refactoring, which truly exists
somewhere on my 
hard disk, believe me 

-- Christian


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

> 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,
Manu

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

On 4/2/07, Christian Boos <cboosneuf.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-devgooglegroups.com
To unsubscribe from this group, send email to
trac-dev-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

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
> 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. 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 --  
instead of the current situation, which is frankly obnoxious
(relying  
on a version of a dependency that's neither release *nor*
trunk).

> 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". 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.

Huh? That's not a beta. You can't postpone major changes
like the  
addition of workflow to after a beta release. Either such
changes are  
postponed to the next release, or the beta needs to wait
until  
they're in. Anything else is not sane release management in
my book.

So,
  * -1 on releasing a beta without the genshi-related
changes.
  * -1 also on releasing a beta without major scheduled
enhancements  
such as the security or workflow, assuming they're scheduled
for the  
final release.

We'll need to stay honest here. Looking at your list of
things you'd  
like to see in 0.11, it seems like a 0.11 release is still
rather far  
way at this point. Putting out a beta version that's nowhere
close to  
what "beta" traditionally means isn't going to
help anyone.

Cheers,
Chris
--
Christopher Lenz
   cmlenz at gmx.de
   http://www.cmlenz.net/


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

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.

> instead of the current situation, which is frankly
obnoxious (relying  
> on a version of a dependency that's neither release
*nor* trunk).
>   

True. That's also why I wanted that we stick to 0.3.6 until
0.4 would 
get released.

>> 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". 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.
>>     
>
> Huh? That's not a beta. You can't postpone major
changes like the  
> addition of workflow to after a beta release. Either
such changes are  
> postponed to the next release, or the beta needs to
wait until  
> they're in. Anything else is not sane release
management in my book.
>   

Well, good points. So what do we do now? Put in bold letters
that trunk 
will get a bit unstable in the coming days?

-- Christian

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

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
>>> to try out 0.11dev, because the trunk will
become temporarily quite
>>> "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.
>>
>> Huh? That's not a beta. You can't postpone major
changes like the
>> addition of workflow to after a beta release.
Either such changes are
>> postponed to the next release, or the beta needs to
wait until
>> they're in. Anything else is not sane release
management in my book.
>
> Well, good points. So what do we do now? Put in bold
letters that  
> trunk
> will get a bit unstable in the coming days?

See above.

Cheers,
Chris
--
Christopher Lenz
   cmlenz at gmx.de
   http://www.cmlenz.net/


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

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

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

On Sunday 01 April 2007, Christian Boos wrote:
> 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

pycon/workflow has settled down pretty well; I'm just doing
bugfixes at this 
point.  Review is, as always, welcome.
There are a number of enhancements I want to make, but they
don't change the 
design, and I'd like to see workflow in trunk before I get
into those.
(Hmm... minor merge conflict with a whitespace change in
[5164].  Guess I'd 
better look at that.)

> So what I'd like to do instead is to release a
0.11beta1,

What you're proposing would actually be a pre-alpha.... it's
not feature 
complete for what we want to release.

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-devgooglegroups.com
To unsubscribe from this group, send email to
trac-dev-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---