Actual Roadmap (0.10 and 0.11)
Ilias Lazaridis
http://trac.edgewall.org/milestone/0.11
Wouldn't it be preferable to split this work into a few more
milestones?
This could be of benefit (in order to avoid similar delays as with the
actual 0.10 version).
0.11 - Focusing on Genshi Migration
0.12 - Focusing on SQLAlchemy
0.13 - Focusing on Workflow and Permission
(the order could change of course, I've have quickly guessed the
dependencies)
.
Noah Kantrowitz
still very early on in its life cycle (hence the pre-1.0 status), and
I agree that there should be a push towards large improvements over
quick releases.
--Noah
Ilias Lazaridis
> On Sep 15, 2006, at 8:44 PM, Ilias Lazaridis wrote:
> >
> > I've notices that the milestone 0.11 contains many tasks:
> >
> > http://trac.edgewall.org/milestone/0.11
> >
> > Wouldn't it be preferable to split this work into a few more
> > milestones?
> >
> > This could be of benefit (in order to avoid similar delays as with the
> > actual 0.10 version).
> >
> > 0.11 - Focusing on Genshi Migration
> >
> > 0.12 - Focusing on SQLAlchemy
> >
> > 0.13 - Focusing on Workflow and Permission
> >
> > (the order could change of course, I've have quickly guessed the
> > dependencies)
>
> still very early on in its life cycle (hence the pre-1.0 status), and
> I agree that there should be a push towards large improvements over
> quick releases.
Thank you.
I'll await the comments of the development team.
.
Matt Good
Those are the current goals, though since the major features are
developed in the sandbox before merging into the trunk we can delay
some features if we decide they're not ready for 0.11. We'll have to
wait until 0.11 is coming along to see how we feel about the
scheduling.
-- Matt Good
ML Philip Instadia
point that is by far the most important improvement.
I too have techno-fascination and want the product based on the most
capable foundation. But seriously: finish the workflow and trac is
THE killer-app.
Sincerely,
Philip Bergen
Noah Kantrowitz
--Noah
Manuzhai
> Please tell me workflow gets higher priority. From a user's stand
> point that is by far the most important improvement.
I do agree that workflow should not be moved back to 0.13. Not only
because it is an actual functional enhancement, but also because it is
sitting there in its branch pretty much finished, waiting to be
merged. Why not merge it for 0.11 and continue the Genshi work for
0.12, SQLAlchemy for 0.13? It doesn't make much sense to do Genshi and
SQLAlchemy first and then ALSO have to change the workflow stuff, it
seems more logical to include workflow in the Genshi/SQLAlchemy work
while people are at it anyway.
Regards,
Manuzhai
Matt Good
> On 9/18/06, ML Philip Instadia <pb...@instadia.net> wrote:
> > Please tell me workflow gets higher priority. From a user's stand
> > point that is by far the most important improvement.
>
> I do agree that workflow should not be moved back to 0.13. Not only
> because it is an actual functional enhancement, but also because it is
> sitting there in its branch pretty much finished, waiting to be
> merged.
I believe Ilias's division of the roadmap was just meant to be an
example of splitting up the current work. It does not reflect the
priorities of the development team. The workflow branch probably will
be one of the first features merged in following the 0.10 release since
it is the most mature.
-- Matt Good
Ilias Lazaridis
Matt Good wrote:
> Manuzhai wrote:
> > On 9/18/06, ML Philip Instadia <pb...@instadia.net> wrote:
> > > Please tell me workflow gets higher priority. From a user's stand
> > > point that is by far the most important improvement.
> >
> > I do agree that workflow should not be moved back to 0.13. Not only
> > because it is an actual functional enhancement, but also because it is
> > sitting there in its branch pretty much finished, waiting to be
> > merged.
>
> I believe Ilias's division of the roadmap was just meant to be an
> example of splitting up the current work.
Of course
> It does not reflect the
> priorities of the development team. The workflow branch probably will
> be one of the first features merged in following the 0.10 release since
> it is the most mature.
>
> -- Matt Good
What I meant essentially was: Those are major changes, and should be
splitted into more milestones, in order to avoid similar delays as with
the 0.10 version.
Personally, I get demotivated by seeing the workload listed within the
0.11 release.
.
Noah Kantrowitz
personally. Having to push a release more often is just more work for
everyone involved.
--Noah
On Sep 18, 2006, at 11:31 PM, Ilias Lazaridis wrote:
[snip]
Ilias Lazaridis
> On Sep 18, 2006, at 11:31 PM, Ilias Lazaridis wrote:
> >
> > What I meant essentially was: Those are major changes, and should be
> > splitted into more milestones, in order to avoid similar delays as
> > with
> > the 0.10 version.
> >
> > Personally, I get demotivated by seeing the workload listed within the
> > 0.11 release.
>
> personally. Having to push a release more often is just more work for
> everyone involved.
Hope the trac-team has learned from the delayed 0.10 release and does
not share your thoughts.
May I ask you what your role is within this project / or your activity
related to trac?
.
Noah Kantrowitz
WikiRename), I do a lot of support on #trac, I help Alec with trac-
hacks.org. Probably a few other things that I'm not thinking of right
now too.
--Noah
Ilias Lazaridis
> On Sep 18, 2006, at 11:59 PM, Ilias Lazaridis wrote:
> > May I ask you what your role is within this project / or your activity
> > related to trac?
>
> WikiRename), I do a lot of support on #trac, I help Alec with trac-
> hacks.org. Probably a few other things that I'm not thinking of right
> now too.
I understand.
Possibly the trac team should add a list "active contributors" to the
document, where people will be listed after e.g. 1 month of continuous
contribution:
http://trac.edgewall.org/wiki/TracTeam
-
I appriciate your efforts and your technical feedback.
Note that several topics tha I open address the decision taking trac
development team. It does not always make sense to reply to those
topics (although you are of course free to do so).
As are a major contributor to this list, It would be of benefit if you
could write below the content of a message, which seems to be standard
within this project.
This way the threads are easier to read, especially within archives.
Again, you are of course free to keep your personal style.
.
Jeroen Ruigrok/asmodai
>Personally, I get demotivated by seeing the workload listed within the
>0.11 release.
As long as the major coders can live with it, it's not a problem.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/
See with your eyes, hear with your ears. Nothing is hidden.
Ilias Lazaridis
> -On [20060919 05:32], Ilias Lazaridis (il...@lazaridis.com) wrote:
> >Personally, I get demotivated by seeing the workload listed within the
> >0.11 release.
>
> As long as the major coders can live with it, it's not a problem.
first of all: they can't, as the 0.10 release has showed.
and of course users should be motivated to become contributors on
code-level.
To achieve this, the tasks should be splitted into smaller chunks (from
the major coders, or better from the architects).
Just suggestions.
.
Ilias Lazaridis
> I've notices that the milestone 0.11 contains many tasks:
>
> http://trac.edgewall.org/milestone/0.11
>
> Wouldn't it be preferable to split this work into a few more
> milestones?
>
> This could be of benefit (in order to avoid similar delays as with the
> actual 0.10 version).
>
> 0.11 - Focusing on Genshi Migration
within this thread...
CONTRIBUTION - Would like to do some work on the Genshi Migration
http://groups.google.com/group/trac-dev/browse_frm/thread/a0932139d50ad20a
... the teem seems to agree to a 'Genshi Centric' 0.11 milestone
the milestone entries have changed, too:
http://trac.edgewall.org/milestone/0.11
The roadmap should show more concise information, thus interested
contributors get immediately an overview.
* the section "Likely to be post-poned even more:", should be moved to
0.12 (including related tickets).
* the entries within the milestone should start with (wiki)pointers to
working-plans which contain actual 'help-needed' sections (thus
contributors can immediately get an overview of how to assist for a
functionality of their interest)
* the milestone 0.11 should get a date (e.g. 2006-12-29)
It is of course still possible to move solved 0.12 tickets back(!) to
the milestone 0.11 -this would btw. have an motivating effect (not
like the negative feeling of having to post-pone something)
.
Christian Boos
> Ilias Lazaridis wrote:
>> I've notices that the milestone 0.11 contains many tasks:
>>
>> http://trac.edgewall.org/milestone/0.11
>>
>> Wouldn't it be preferable to split this work into a few more
>> milestones?
>>
>> This could be of benefit (in order to avoid similar delays as with the
>> actual 0.10 version).
>>
>> 0.11 - Focusing on Genshi Migration
> ...
>
> within this thread...
>
> CONTRIBUTION - Would like to do some work on the Genshi Migration
> http://groups.google.com/group/trac-dev/browse_frm/thread/a0932139d50ad20a
>
> ... the teem seems to agree to a 'Genshi Centric' 0.11 milestone
>
> the milestone entries have changed, too:
>
> http://trac.edgewall.org/milestone/0.11
>
> The roadmap should show more concise information, thus interested
> contributors get immediately an overview.
>
> * the section "Likely to be post-poned even more:", should be moved to
> 0.12 (including related tickets).
Eh, for now it's quite adequate, as actually we (at least I) don't know
if they will be part of 0.12 or not, in the end. If development speed
remains, the first items in the list would be completed quite soon, and
there will still be time to do more, like the WorkFlow merge, especially
given the fact that this can be started in parallel anytime now (Alec?)...
> * the entries within the milestone should start with (wiki)pointers to
> working-plans which contain actual 'help-needed' sections (thus
> contributors can immediately get an overview of how to assist for a
> functionality of their interest)
Well, sure, this can always be improved. But feel free to discuss this
here first.
> * the milestone 0.11 should get a date (e.g. 2006-12-29)
>
> It is of course still possible to move solved 0.12 tickets back(!) to
> the milestone 0.11 -this would btw. have an motivating effect (not
> like the negative feeling of having to post-pone something)
Moving a bunch of ticket back and forth is still inconvenient at this
point (see #525), so we avoid doing it without a good reason.
-- Christian (trying to post through GMane ;) )
Manuzhai
> Eh, for now it's quite adequate, as actually we (at least I) don't know
> if they will be part of 0.12 or not, in the end. If development speed
> remains, the first items in the list would be completed quite soon, and
> there will still be time to do more, like the WorkFlow merge, especially
> given the fact that this can be started in parallel anytime now (Alec?)...
I think that if development speed remains, we should just get 0.11 out
quicker, rather than piling on new features. The 0.10 release cycle
was endless...
Regards,
Manuzhai
Ilias Lazaridis
You've stated this points:
"
* Ditch ClearSilver in favor of Genshi for templating
* Timezone support and internal use of `datetime`
* Use setuptools for setup
* Integration of WebAdmin into core
"
Development of Trac 0.11dev has started
http://groups.google.com/group/trac-dev/browse_thread/thread/27d028d385620a0a
Those points should be stabelized in release(!!!) quality, _before_
including major changes to the core like those introduced by workflow.
Seeing development going on nice should not make you forget the 0.10
delays.
> > * the entries within the milestone should start with (wiki)pointers to
> > working-plans which contain actual 'help-needed' sections (thus
> > contributors can immediately get an overview of how to assist for a
> > functionality of their interest)
>
> Well, sure, this can always be improved. But feel free to discuss this
> here first.
I think I've made a rational suggestion, which the team can choose to
apply or not. (I've no access rights to modify the Milestones).
> > * the milestone 0.11 should get a date (e.g. 2006-12-29)
> >
> > It is of course still possible to move solved 0.12 tickets back(!) to
> > the milestone 0.11 -this would btw. have an motivating effect (not
> > like the negative feeling of having to post-pone something)
>
> Moving a bunch of ticket back and forth is still inconvenient at this
> point (see #525), so we avoid doing it without a good reason.
ok, I understand.
This seems to be a major weakness of trac, which should not hinder the
team to provide concise mileston-information.
Possibly applying a keyword to the relevant tickets and moving them
manually with an sql-query could help.
-
Like always: those are thoughts and suggestions to engourage discussion
and to move trac forward.
.