You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Ferdinand Soethe <fe...@apache.org> on 2005/08/26 07:28:00 UTC
[Proposal] Development process and a stable trunk
I have an uncomfortable gut feeling with the current status of our
pre-release version and I'd like your feedback on these concerns and
my suggestions to change our process.
My concerns with the current situation:
- in the last few month a number of exciting major projects
(location maps, views, i18n, change of cocoon ...)and a number of
smaller ones have been developed (which is good!)
- most of them have not been finished to the point of being releasable
and (so it seems to me) will not be for considerable time so it
seems like we won't be able to release quickly without a major clean-up
effort (which I consider bad).
- the work-in-progress-state and its (perfectly normal) unfinished
documentation make it very hard for people to understand the
development version or work with it at any point in time or
understand the implications and side effects of each new development.
What I'd like to see in the future:
1 Adjust our development process so that the current development
version (I think this is called 'trunk') is always releasable,
stable and _well documented_ (meaning complete and correct, not well
written or suitable for a dummy user).
2 Develop all major changes and new features in separate branches that
will only be merged back into trunk when they are stable
and well documented (not talking refined documentation but good enough
that a technical writer could work with it) and a good number of committers
not involved in the process have reviewed and tested them.
3 Discuss and vote one merging each branch back into trunk.
4 Create a new release whenever such a merger has taken place so that
new functionalities become quickly available to new users and can be
stress tested in a production environment without too many changes
to consider as a source for potential problems.
This would also make testing of new releases a lot more focussed.
Obviously plugins would not require a separate branch as they already
have the whiteboard and a similar process. However, I would like to
suggest an optional step 4 for important plugins (like views).
5 As a supportive measure, clearly mark threads in this list when they
deal with a particular branch so that people not working on that
issue can safely ignore it.
Only take issues to the list as a general topic when
interface issues or planned architectural changes
require input from the general community or the development
team is ready to show and explain their work and suggest a merger.
wdyt?
--
Ferdinand Soethe
Re: FOR-592 - pelt and i18n clarifications
Posted by David Crossley <cr...@apache.org>.
Gav.... wrote:
> David Crossley wrote:
>
> | We were using that i18n fix as an excercise
> | for you to understand the core processing.
> | I reckon that we should take the easy route
> | with the suggestion to add a special transformer
> | at the end to strip out <text> tags.
> |
> | I can try that if you would rather get on with
> | the CSS.
>
> Thats up to you, if you want to clear the issue out and
> get it closed.
Okay, that is done now.
> I am understanding more than I did when
> I first started investigating i18n, but as you can see I
> have not rectified it yet so I still have some way to go.
> I would have liked the satisfaction of getting this one
> licked, but I seem to be diverting on to easier tasks
> and not concentrating on this one. I am sure I will
> understand this and other harder stuff in the future.
Thanks for your help with this issue though.
We are now closer to valid html, down from 4 errors
to one.
I am glad that you learned something out of the
exercise. The sitemap processing will probably
be revised and simplified when we implement the
XHTML2 as the internal structure.
-David
Re: FOR-592 - pelt and i18n clarifications
Posted by "Gav...." <br...@brightontown.com.au>.
----- Original Message -----
From: "David Crossley" <cr...@apache.org>
To: <de...@forrest.apache.org>
Sent: Saturday, August 27, 2005 9:11 AM
Subject: Re: FOR-592 - pelt and i18n clarifications
| > Along with CSS , I am also working on some parts of i18n, mainly to get
it
| > working to ensure a site with it enabled is still valid.
|
| I would rather that you got on with the CSS.
| That seemed to be your particular itch when you joined.
Ok, no problem, getting on with that now.
|
| We were using that i18n fix as an excercise
| for you to understand the core processing.
| I reckon that we should take the easy route
| with the suggestion to add a special transformer
| at the end to strip out <text> tags.
|
| I can try that if you would rather get on with
| the CSS.
Thats up to you, if you want to clear the issue out and
get it closed. I am understanding more than I did when
I first started investigating i18n, but as you can see I
have not rectified it yet so I still have some way to go.
I would have liked the satisfaction of getting this one
licked, but I seem to be diverting on to easier tasks
and not concentrating on this one. I am sure I will
understand this and other harder stuff in the future.
Gav...
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.16/83 - Release Date: 26/08/2005
Re: FOR-592 - pelt and i18n clarifications
Posted by David Crossley <cr...@apache.org>.
Moving this from another thread:
br_gavmc wrote:
> Just to sort of answer one part of this at the moment :-
>
> > I have an uncomfortable gut feeling with the current status of our
> > pre-release version and I'd like your feedback on these concerns and
> > my suggestions to change our process.
> >
> > My concerns with the current situation:
> >
> > - in the last few month a number of exciting major projects
> > (location maps, views, i18n, change of cocoon ...)and a number of
> > smaller ones have been developed (which is good!)
> >
> > - most of them have not been finished to the point of being releasable
> > and (so it seems to me) will not be for considerable time so it
> > seems like we won't be able to release quickly without a major clean-up
> > effort (which I consider bad).
>
> Along with CSS , I am also working on some parts of i18n, mainly to get it
> working to ensure a site with it enabled is still valid.
I would rather that you got on with the CSS.
That seemed to be your particular itch when you joined.
We were using that i18n fix as an excercise
for you to understand the core processing.
I reckon that we should take the easy route
with the suggestion to add a special transformer
at the end to strip out <text> tags.
I can try that if you would rather get on with
the CSS.
> Apart from that
> AFAIK it works, only that it is not implemented for the whole site, only
> parts of it.
Hmmm, i think that i18n works everywhere. Perhaps you
are talking about the idea to have it permanently
switched on for all processing.
> David has hinted that this will be some time away before the
> rest of it gets implemented, but the base of it will be there and working
> and should not get in the way of a release.
>
> (I just need the <i18n:text>penny to drop</text> and I'll have a patch
> shortly!)
:-)
-David
Re: [Proposal] Development process and a stable trunk
Posted by br...@e-wire.net.au.
Just to sort of answer one part of this at the moment :-
>
> I have an uncomfortable gut feeling with the current status of our
> pre-release version and I'd like your feedback on these concerns and
> my suggestions to change our process.
>
> My concerns with the current situation:
>
> - in the last few month a number of exciting major projects
> (location maps, views, i18n, change of cocoon ...)and a number of
> smaller ones have been developed (which is good!)
>
> - most of them have not been finished to the point of being releasable
> and (so it seems to me) will not be for considerable time so it
> seems like we won't be able to release quickly without a major clean-up
> effort (which I consider bad).
Along with CSS , I am also working on some parts of i18n, mainly to get it
working to ensure a site with it enabled is still valid. Apart from that
AFAIK it works, only that it is not implemented for the whole site, only
parts of it. David has hinted that this will be some time away before the
rest of it gets implemented, but the base of it will be there and working
and should not get in the way of a release.
(I just need the <i18n:text>penny to drop</text> and I'll have a patch
shortly!)
Gav...
Re: [Proposal] Development process and a stable trunk
Posted by Ross Gardler <rg...@apache.org>.
Tim Williams wrote:
> On 8/26/05, Ross Gardler <rg...@apache.org> wrote:
>
>>Ferdinand Soethe wrote:
>>
>>
>>>I have an uncomfortable gut feeling with the current status of our
>>>pre-release version and I'd like your feedback on these concerns and
>>>my suggestions to change our process.
>>>
>>>
>>>My concerns with the current situation:
>>>
>>>- in the last few month a number of exciting major projects
>>> (location maps, views, i18n, change of cocoon ...)and a number of
>>> smaller ones have been developed (which is good!)
>>>
>>>- most of them have not been finished to the point of being releasable
>>> and (so it seems to me) will not be for considerable time so it
>>> seems like we won't be able to release quickly without a major clean-up
>>> effort (which I consider bad).
>>>
>>>- the work-in-progress-state and its (perfectly normal) unfinished
>>> documentation make it very hard for people to understand the
>>> development version or work with it at any point in time or
>>> understand the implications and side effects of each new development.
>>>
>>>What I'd like to see in the future:
>>>
>>>1 Adjust our development process so that the current development
>>> version (I think this is called 'trunk') is always releasable,
>>> stable and _well documented_ (meaning complete and correct, not well
>>> written or suitable for a dummy user).
>
>
> We've talked about this before and last time the only thing I had
> heartburn with was "always releasable" trunk as it implies an "Always
> Branch" system and I think that's overly rigid and runs counter to our
> community goals. A reasonably stable trunk is a good goal. Well
> documented to the extent possible - if something is still under heavy
> development then time shouldn't be wasted documenting yet (beyond that
> which would allow other devs to check it out). Heavy development in
> the trunk? Yes, if it's not causing the trunk to be unstable, then
> yes.
+1, my recollection of the previous discussion was that a branch is used
for new functionality or major refactoring. My recollection of "always
releasable" is that Forrest devs are using it in production
environments. This implies that there may be one or two hidden bugs but
in the main it is releasable.
In addition "always releasable" should mean that all tests are past
(when we have them)
>>>2 Develop all major changes and new features in separate branches that
>>> will only be merged back into trunk when they are stable
>>> and well documented (not talking refined documentation but good enough
>>> that a technical writer could work with it) and a good number of committers
>>> not involved in the process have reviewed and tested them.
>
>
> Develop all major changes and new features *that may make the trunk
> unstable* in separate branches maybe. As written, I think this would
> lead to fracturing in a couple ways. 1) devs wouldn't check-out all
> the other branches and new stuff would be sole-developed even more so
> than some things are now; 2) bleeding-edge users won't get into
> checking out multiple branches to checkout new functionality (i.e. no
> patches).
The reality of most work is that it starts of as a one person operation
until it becomes usable, occasionally someone else comes along (as you
did with Loationmaps). SVN does not force users to checkout complete
branches. They simply run a switch command and that's it. this is a very
fast operation in most cases.
Having said that, I agree with your concerns. It's difficult to decide
when not to branch, often a simple change becomes something much more major.
>>Both 1 and 2 are already agreed in principle, we just have to action it
>>by creating the infrastructure and processes, see end of this mail for
>>links.
>
>
> I think we agreed to these goals (more or less):
> 1) a stable trunk (ie. no "hoop-jumping" to build and run).
> 2) a branch for anything that would violate goal #1
> 3) each branch in #2 should be independent features (so that each can
> merge separately)
>
> My take on what's being suggested goes well-beyond this but maybe I'm
> reading too much into it.
My take, is as you define it. Who knows exactly what Ferdinand meant
(I'm sure he'll tell us if it is different). What we need to do is
document it, this thread and the others I linked to in a previous reply
go a long way to providing this documentation. We just need someone to
have the time to pull it all together.
...
>>> This would also make testing of new releases a lot more focussed.
>>>
>>>
>>
>>I would like to go a step further and say we do not merge branches until
>>we have automated tests for the new features and all existing tests pass.
>
>
> I don't think we're mature enough for that. At least, I've not seen a
> robust enough test harness around for it.
I don't understand how we can not be mature enough. In agile programming
you write the tests *before* you write the code. We are a long way from
that, but I don't see why we can't try and catch up a bit.
At the very least we should insist that the minimal testing we do have
is passed (David as set up an instance of Forrest on our zone, we need
to make use of this for testing).
In addition there are a number of testing frameworks that can be used
for this. We have discussed it in the past. There are some basic
starting points in the whiteboard.
However, I agree with both yourself and David in that the absence of
these tests should not prevent us actoning this proposal (or whatever we
agree on).
>>>5 As a supportive measure, clearly mark threads in this list when they
>>> deal with a particular branch so that people not working on that
>>> issue can safely ignore it.
>>>
>>>
>>
>>+1
>
>
> Encouraging such on the project would lead, in my opinion, to a
> fractured community. People naturally tend to prioritize email based
> on the subject line, but supporting that through branch prefixes or
> the like would lead to several "mini-projects". Heck, people might
> even set up email filters to only look at "their" branch -- not good.
> I think instead we need folks periodically reminding everyone to write
> good archive/mailbox-friendly subject lines.
Yes, David and Thorsten have made similar points, I agree.
Ross
Re: [Proposal] Development process and a stable trunk
Posted by Tim Williams <wi...@gmail.com>.
On 8/26/05, Ross Gardler <rg...@apache.org> wrote:
> Ferdinand Soethe wrote:
>
> >I have an uncomfortable gut feeling with the current status of our
> >pre-release version and I'd like your feedback on these concerns and
> >my suggestions to change our process.
> >
> >
> >My concerns with the current situation:
> >
> >- in the last few month a number of exciting major projects
> > (location maps, views, i18n, change of cocoon ...)and a number of
> > smaller ones have been developed (which is good!)
> >
> >- most of them have not been finished to the point of being releasable
> > and (so it seems to me) will not be for considerable time so it
> > seems like we won't be able to release quickly without a major clean-up
> > effort (which I consider bad).
> >
> >- the work-in-progress-state and its (perfectly normal) unfinished
> > documentation make it very hard for people to understand the
> > development version or work with it at any point in time or
> > understand the implications and side effects of each new development.
> >
> >What I'd like to see in the future:
> >
> >1 Adjust our development process so that the current development
> > version (I think this is called 'trunk') is always releasable,
> > stable and _well documented_ (meaning complete and correct, not well
> > written or suitable for a dummy user).
We've talked about this before and last time the only thing I had
heartburn with was "always releasable" trunk as it implies an "Always
Branch" system and I think that's overly rigid and runs counter to our
community goals. A reasonably stable trunk is a good goal. Well
documented to the extent possible - if something is still under heavy
development then time shouldn't be wasted documenting yet (beyond that
which would allow other devs to check it out). Heavy development in
the trunk? Yes, if it's not causing the trunk to be unstable, then
yes.
>
> >2 Develop all major changes and new features in separate branches that
> > will only be merged back into trunk when they are stable
> > and well documented (not talking refined documentation but good enough
> > that a technical writer could work with it) and a good number of committers
> > not involved in the process have reviewed and tested them.
Develop all major changes and new features *that may make the trunk
unstable* in separate branches maybe. As written, I think this would
lead to fracturing in a couple ways. 1) devs wouldn't check-out all
the other branches and new stuff would be sole-developed even more so
than some things are now; 2) bleeding-edge users won't get into
checking out multiple branches to checkout new functionality (i.e. no
patches).
> Both 1 and 2 are already agreed in principle, we just have to action it
> by creating the infrastructure and processes, see end of this mail for
> links.
I think we agreed to these goals (more or less):
1) a stable trunk (ie. no "hoop-jumping" to build and run).
2) a branch for anything that would violate goal #1
3) each branch in #2 should be independent features (so that each can
merge separately)
My take on what's being suggested goes well-beyond this but maybe I'm
reading too much into it.
> >3 Discuss and vote one merging each branch back into trunk.
> >
> >
> -1. We only need to discuss major contributions. You will see in the
> above linked thread that we are talking about using branches for *all*
> work that may break existing functionality, however votes should only be
> taken on major functionality.
>
> Instead of a vote what should happen is that someone announces they are
> going to merge into trunk unless someone objects (i.e. lazy consensus)
>
> >4 Create a new release whenever such a merger has taken place so that
> > new functionalities become quickly available to new users and can be
> > stress tested in a production environment without too many changes
> > to consider as a source for potential problems.
> >
> >
> -1 for the same reason as above, some branches will be for minor changes
> in functionality. However, we have already agreed, in principle, to do
> more frequent releases. I believe the intent of your suggestion here is
> aligned with that so I agree with the intent.
>
> > This would also make testing of new releases a lot more focussed.
> >
> >
> I would like to go a step further and say we do not merge branches until
> we have automated tests for the new features and all existing tests pass.
I don't think we're mature enough for that. At least, I've not seen a
robust enough test harness around for it.
> >5 As a supportive measure, clearly mark threads in this list when they
> > deal with a particular branch so that people not working on that
> > issue can safely ignore it.
> >
> >
> +1
Encouraging such on the project would lead, in my opinion, to a
fractured community. People naturally tend to prioritize email based
on the subject line, but supporting that through branch prefixes or
the like would lead to several "mini-projects". Heck, people might
even set up email filters to only look at "their" branch -- not good.
I think instead we need folks periodically reminding everyone to write
good archive/mailbox-friendly subject lines.
--tim
Re: [Proposal] Development process and a stable trunk
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>
>>Ferdinand Soethe wrote:
>>
>>
>>>What I'd like to see in the future:
>>>
>>>1 Adjust our development process so that the current development
>>>version (I think this is called 'trunk') is always releasable,
>>>stable and _well documented_ (meaning complete and correct, not well
>>>written or suitable for a dummy user).
>>
>>>2 Develop all major changes and new features in separate branches that
>>>will only be merged back into trunk when they are stable
>>>and well documented (not talking refined documentation but good enough
>>>that a technical writer could work with it) and a good number of
>>>committers
>>>not involved in the process have reviewed and tested them.
>>
>>Both 1 and 2 are already agreed in principle, we just have to action it
>>by creating the infrastructure and processes, see end of this mail for
>>links.
>
>
> We did discuss this earlier and seemed to be in agreement.
>
> I know that documentation is a good thing, but i don't
> see how we can measure it enough to be able to deny
> a merge. Perhaps if there is at least some docs then
> merge is okay.
+1 - not enough docs could be one reason why someone would object to a
mere (see below)
>>>3 Discuss and vote one merging each branch back into trunk.
>>
>>-1. We only need to discuss major contributions. You will see in the
>>above linked thread that we are talking about using branches for *all*
>>work that may break existing functionality, however votes should only be
>>taken on major functionality.
>>
>>Instead of a vote what should happen is that someone announces they are
>>going to merge into trunk unless someone objects (i.e. lazy consensus)
>
>
> I agree, but they also need to allow time for
> the world to turn a bit so that that we all have
> time to raise concerns.
+1 - 3 complete revolutions of the planet is the "usual" on other projects.
...
>>>This would also make testing of new releases a lot more focussed.
>>
>>I would like to go a step further and say we do not merge branches until
>>we have automated tests for the new features and all existing tests pass.
>
>
> Tests would be good, but as yet we don't have a good enough
> testing framework to be so rigorous.
True, so we need to create one. The absence of one should not prevent us
from moving forwards with Ferdinands proposal, but it should be
considered an important addition to the process.
>>>5 As a supportive measure, clearly mark threads in this list when they
>>>deal with a particular branch so that people not working on that
>>>issue can safely ignore it.
>>
>>+1
>
>
> Don't use the "ignore" word. I agree with Thorsten that
> that can be damaging to community.
+1 - I had interpreted "ignore" in the context of lazy consensu, I agree
nothing should be ignored in the sense of no notice is taken.
> Wouldn't a well-chosen subject title suffice.
+1
Ross
Re: [Proposal] Development process and a stable trunk
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> Ferdinand Soethe wrote:
>
> >What I'd like to see in the future:
> >
> >1 Adjust our development process so that the current development
> > version (I think this is called 'trunk') is always releasable,
> > stable and _well documented_ (meaning complete and correct, not well
> > written or suitable for a dummy user).
>
> >2 Develop all major changes and new features in separate branches that
> > will only be merged back into trunk when they are stable
> > and well documented (not talking refined documentation but good enough
> > that a technical writer could work with it) and a good number of
> > committers
> > not involved in the process have reviewed and tested them.
>
> Both 1 and 2 are already agreed in principle, we just have to action it
> by creating the infrastructure and processes, see end of this mail for
> links.
We did discuss this earlier and seemed to be in agreement.
I know that documentation is a good thing, but i don't
see how we can measure it enough to be able to deny
a merge. Perhaps if there is at least some docs then
merge is okay.
> >3 Discuss and vote one merging each branch back into trunk.
>
> -1. We only need to discuss major contributions. You will see in the
> above linked thread that we are talking about using branches for *all*
> work that may break existing functionality, however votes should only be
> taken on major functionality.
>
> Instead of a vote what should happen is that someone announces they are
> going to merge into trunk unless someone objects (i.e. lazy consensus)
I agree, but they also need to allow time for
the world to turn a bit so that that we all have
time to raise concerns.
> >4 Create a new release whenever such a merger has taken place so that
> > new functionalities become quickly available to new users and can be
> > stress tested in a production environment without too many changes
> > to consider as a source for potential problems.
>
> -1 for the same reason as above, some branches will be for minor changes
> in functionality. However, we have already agreed, in principle, to do
> more frequent releases. I believe the intent of your suggestion here is
> aligned with that so I agree with the intent.
> > This would also make testing of new releases a lot more focussed.
>
> I would like to go a step further and say we do not merge branches until
> we have automated tests for the new features and all existing tests pass.
Tests would be good, but as yet we don't have a good enough
testing framework to be so rigorous.
> >5 As a supportive measure, clearly mark threads in this list when they
> > deal with a particular branch so that people not working on that
> > issue can safely ignore it.
>
> +1
Don't use the "ignore" word. I agree with Thorsten that
that can be damaging to community.
Wouldn't a well-chosen subject title suffice.
-David
Re: [Proposal] Development process and a stable trunk
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
>I have an uncomfortable gut feeling with the current status of our
>pre-release version and I'd like your feedback on these concerns and
>my suggestions to change our process.
>
>My concerns with the current situation:
>
>- in the last few month a number of exciting major projects
> (location maps, views, i18n, change of cocoon ...)and a number of
> smaller ones have been developed (which is good!)
>
>- most of them have not been finished to the point of being releasable
> and (so it seems to me) will not be for considerable time so it
> seems like we won't be able to release quickly without a major clean-up
> effort (which I consider bad).
>
>- the work-in-progress-state and its (perfectly normal) unfinished
> documentation make it very hard for people to understand the
> development version or work with it at any point in time or
> understand the implications and side effects of each new development.
>
>What I'd like to see in the future:
>
>1 Adjust our development process so that the current development
> version (I think this is called 'trunk') is always releasable,
> stable and _well documented_ (meaning complete and correct, not well
> written or suitable for a dummy user).
>
>
>2 Develop all major changes and new features in separate branches that
> will only be merged back into trunk when they are stable
> and well documented (not talking refined documentation but good enough
> that a technical writer could work with it) and a good number of committers
> not involved in the process have reviewed and tested them.
>
>
Both 1 and 2 are already agreed in principle, we just have to action it
by creating the infrastructure and processes, see end of this mail for
links.
>3 Discuss and vote one merging each branch back into trunk.
>
>
-1. We only need to discuss major contributions. You will see in the
above linked thread that we are talking about using branches for *all*
work that may break existing functionality, however votes should only be
taken on major functionality.
Instead of a vote what should happen is that someone announces they are
going to merge into trunk unless someone objects (i.e. lazy consensus)
>4 Create a new release whenever such a merger has taken place so that
> new functionalities become quickly available to new users and can be
> stress tested in a production environment without too many changes
> to consider as a source for potential problems.
>
>
-1 for the same reason as above, some branches will be for minor changes
in functionality. However, we have already agreed, in principle, to do
more frequent releases. I believe the intent of your suggestion here is
aligned with that so I agree with the intent.
> This would also make testing of new releases a lot more focussed.
>
>
I would like to go a step further and say we do not merge branches until
we have automated tests for the new features and all existing tests pass.
>5 As a supportive measure, clearly mark threads in this list when they
> deal with a particular branch so that people not working on that
> issue can safely ignore it.
>
>
+1
----
A few weeks ago I started working on summarising the many discussions
like this that we have recently had. I have never found the time to
finish it, in fact I hardly got started. I'll copy what I have here, I'd
encourage someone to take this, put it in SVN and add the other details
from the threads linked to in this draft and the additional stuff
suggested above.
----------------------------------------------
--- Pre-draft of Development Process ---
----------------------------------------------
This proposal is a summary of the following recent threads
"Project participation and hackability" [1] and [2]
"Using Jira and branches for Project Management" [3]
I also used Cocoons [4] project management wiki page for inspiration.
It is intended to be the starting point not the end game, we should move
this into a document (any volunteers?) and keep it up to date as we
learn "on the job". Some of the things in here will prove to be
unworkable, some will be improved. Lets try them and see how it goes.
---
Objectives
==========
To define a project management process that will enable Forrest to
continue to grow without becoming a totally chaotic environemnt.
To create a structure to progect management that is not restricitve to
the Open Source development process
To define processes that, when followed correctly, will reduce the
effort required for Forrest developers to participate effectively, that
is, to not overly burden developers will project management tasks
To create a single point of reference for accepted best practices within
the Forrest development community
Background
==========
Forrest is growing rapidly in many directions. We have a far larger
developer base than just a few months ago, we have a code base that is
expanding in many directions and we have a user base that are applying
Forrest to an increasingly diverse range of problems.
This expansion has resulted in a great deal of new ideas from the
project and inputs to the project. Far more than can possibly be managed
by any single developer. As a result "virtual" teams are emerging within
the community, each focussing on different parts of the Forrest product.
Communication and understanding between these "teams" is excellent, but
the volume of mail passing through our Forrest mailing lists is becoming
unmanageable. As a result developers become selective of which threads
they track in detail which ultimately results in some duplication of
discussion at the overlap points between functionality.
It appears that the Forrest project has expanded to the point at which
we need to maintain an overview document about the project, the work
being carried out, the work planned and the integration of this work
into the core product.
Proposal
========
Using Branches for New Functionlaity
------------------------------------
---
[1] http://marc.theaimsgroup.com/?l=forrest-dev&m=111968323717620&w=2
[2] http://marc.theaimsgroup.com/?l=forrest-dev&m=111970514323568&w=2
[3] http://marc.theaimsgroup.com/?t=112393100500001&r=1&w=2
[4] http://wiki.apache.org/cocoon/ProjectManagement
mail lists activity (Was: [Proposal] Development process and a stable trunk)
Posted by David Crossley <cr...@apache.org>.
Gav.... wrote:
> Can I ask,
>
> How many people are subscribed to the dev list?
> How many of those are regular posters and/or contributors?
>
> The answer is for my curiosity, but also may enlighten myself
> and others as to actually how many people are working on this project,
> it might have a bearing on expected help/workload.
Ken shows some statistics:
http://people.apache.org/~coar/mlists.html#forrest.apache.org
Answering your second question is harder, but Stefano's
brilliance will keep you awake all night trying to answer that:
http://people.apache.org/~stefano/agora/
Load a few months of forrest-dev archives and then
click-and-drag some people. It will show the
interactions and who talks to who.
As you can see, we are still a small community.
-David
Re: [Proposal] Development process and a stable trunk
Posted by "Gav...." <br...@brightontown.com.au>.
Can I ask,
How many people are subscribed to the dev list?
How many of those are regular posters and/or contributors?
The answer is for my curiosity, but also may enlighten myself
and others as to actually how many people are working on this project,
it might have a bearing on expected help/workload.
Gav...
----- Original Message -----
From: "Ross Gardler" <rg...@apache.org>
To: <de...@forrest.apache.org>
Sent: Monday, August 29, 2005 7:46 PM
Subject: Re: [Proposal] Development process and a stable trunk
| Ferdinand Soethe wrote:
| > Thanks everybody for taking the time to respond and giving me a change
| > to re-think and refine my own thoughts on these issues.
| >
| > Here are some comments for a start:
| >
| > - Ignoring of threads (or developments)
| >
| > I'm sorry to say this but I'm simply not able to read everything
that's
| > on this list all the time. And even though this might have to do
| > with going kayaking too often in my case :-), I think that with
growing
| > volume of project and list this will happen to most of us sooner or
| > later.
| >
| > For me prioritizing stuff in this list is a necessity rather
| > than a choice. And at the moment I can never tell the relevance of a
| > thread to Forrest as a hole.
| >
| > I know that it would be nice if all of us could follow all the
| > threads, but honestly, is that realistic?
| >
| > Also: A lot of people might join the list without the interest or
| > the capacity to follow all our discussion from the start. Following
| > new developments from when a merger is proposed gives them a good
interface to
| > cutting-edge forrest development without the bloodloss :-).
|
|
| I agree with everything said and feel that this is what the conclusion
| of the thread has been.
|
| It is the respopnsbility of the PMC to read *all* commits, not *all*
| mails. We should not *ignore* threads though. I tend to read the first
| post in a thread, if it is a priority for me I read all subsequent posts
| otherwise I skin read the subsequent posts.
|
| I also have filters set up on my mail client that will detect if someone
| types my name. So if someone says "I wonder what Ross thinks" or "Ross,
| how would this fit into plugins" or something like that my client flags
| the message for me.
|
| In addition, as you point out well worded subjects are important. I'm
| not sure about prefixing with a branch name since a discussion about
| something in a branch is also a discussion about what will end up in
| core. So it is no less relevant just because it is in a branch.
|
| > - When to branch
| >
| > After considering your responses I realize that I need to refine the
| > criteria for branching:
| >
| > Changes should happen in a branch when they
| >
| > - change (not fix) to output
| > - require additional or different input
| > - change (not add) existing configuration option
|
| In earlier threads (linked to in my prevoius mail) we discussed criteria
| for branching. I think the conclusion was that it should be up to the
| individual dev do decide. It isn't really possible to create a set of
| rules - nothing wrong with examples like those above (and below) though.
|
| > The reason behind this demand is, that all these changes require
| > users and developers to adjust their applications or their coding
| > work in progress. So in order to do that efficiently they should
| > have well defined, finalized and properly documented changes to deal
| > with.
|
| +1, I think Tim expressed this as something like a realeasable trunk
| does not requrie users to jump through any hoops.
|
| > In addition I would suggest branching also
| >
| > - when the internal workings
| > of a module are altered in a major way.
| >
| > The reason for this being that anybody also working on, extending or
| > even debugging such a module does not get in the middle of somebody
| > else's major change or has to guesswork about the function of some
| > undocumented new piece of code.
| >
| > - Vote on merging branches
| >
| > I have no problem with the lazy consensus model her. What is more
| > important to me is that fact that at least some developers not
| > involved in the implementation should have looked at (not just 'have
| > had a chance to look at') and tried the new functionality.
|
| Since all PMC members have a responsability for reading *all* commits,
| then (in theory) all developers will ahve watched what was going on in
| the branch anyeay. There should be no need for a separate review cycle
| before merge.
|
| In my opinion the docs + tests we discussed are more important.
|
| > Now I know that this is hard because you have to get somebody to do
| > this and perhaps even wait for them to do it. But on the other hand
| > I expect this to have a couple of useful side effects:
| >
| > - Documentation and value of the new developed functionality have to
| > be properly balanced or nobody will do the testing.
| >
| > - The time waiting for a tester is often useful to rethink and
| > refine the solution and perhaps even improve on the docs.
|
| Here you are proposing a formal test process before merging. I'm not
| sure how I feel about this. Speaking personally, I don't have the time
| to test *all* of other peopls code, they could wait for me for a long
| time, this will cause problems. I prefer to trust that they have tested
| it sufficiently before commiting and merging.
|
| (longer term I would prefer a proper test suite in Forrest, but that is
| a whole different thing and should not delay progress on your proposal).
|
| Ross
|
|
| --
| No virus found in this incoming message.
| Checked by AVG Anti-Virus.
| Version: 7.0.344 / Virus Database: 267.10.16/83 - Release Date: 26/08/2005
|
|
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.16/83 - Release Date: 26/08/2005
Re: [Proposal] Development process and a stable trunk
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
> Thanks everybody for taking the time to respond and giving me a change
> to re-think and refine my own thoughts on these issues.
>
> Here are some comments for a start:
>
> - Ignoring of threads (or developments)
>
> I'm sorry to say this but I'm simply not able to read everything that's
> on this list all the time. And even though this might have to do
> with going kayaking too often in my case :-), I think that with growing
> volume of project and list this will happen to most of us sooner or
> later.
>
> For me prioritizing stuff in this list is a necessity rather
> than a choice. And at the moment I can never tell the relevance of a
> thread to Forrest as a hole.
>
> I know that it would be nice if all of us could follow all the
> threads, but honestly, is that realistic?
>
> Also: A lot of people might join the list without the interest or
> the capacity to follow all our discussion from the start. Following
> new developments from when a merger is proposed gives them a good interface to
> cutting-edge forrest development without the bloodloss :-).
I agree with everything said and feel that this is what the conclusion
of the thread has been.
It is the respopnsbility of the PMC to read *all* commits, not *all*
mails. We should not *ignore* threads though. I tend to read the first
post in a thread, if it is a priority for me I read all subsequent posts
otherwise I skin read the subsequent posts.
I also have filters set up on my mail client that will detect if someone
types my name. So if someone says "I wonder what Ross thinks" or "Ross,
how would this fit into plugins" or something like that my client flags
the message for me.
In addition, as you point out well worded subjects are important. I'm
not sure about prefixing with a branch name since a discussion about
something in a branch is also a discussion about what will end up in
core. So it is no less relevant just because it is in a branch.
> - When to branch
>
> After considering your responses I realize that I need to refine the
> criteria for branching:
>
> Changes should happen in a branch when they
>
> - change (not fix) to output
> - require additional or different input
> - change (not add) existing configuration option
In earlier threads (linked to in my prevoius mail) we discussed criteria
for branching. I think the conclusion was that it should be up to the
individual dev do decide. It isn't really possible to create a set of
rules - nothing wrong with examples like those above (and below) though.
> The reason behind this demand is, that all these changes require
> users and developers to adjust their applications or their coding
> work in progress. So in order to do that efficiently they should
> have well defined, finalized and properly documented changes to deal
> with.
+1, I think Tim expressed this as something like a realeasable trunk
does not requrie users to jump through any hoops.
> In addition I would suggest branching also
>
> - when the internal workings
> of a module are altered in a major way.
>
> The reason for this being that anybody also working on, extending or
> even debugging such a module does not get in the middle of somebody
> else's major change or has to guesswork about the function of some
> undocumented new piece of code.
>
> - Vote on merging branches
>
> I have no problem with the lazy consensus model her. What is more
> important to me is that fact that at least some developers not
> involved in the implementation should have looked at (not just 'have
> had a chance to look at') and tried the new functionality.
Since all PMC members have a responsability for reading *all* commits,
then (in theory) all developers will ahve watched what was going on in
the branch anyeay. There should be no need for a separate review cycle
before merge.
In my opinion the docs + tests we discussed are more important.
> Now I know that this is hard because you have to get somebody to do
> this and perhaps even wait for them to do it. But on the other hand
> I expect this to have a couple of useful side effects:
>
> - Documentation and value of the new developed functionality have to
> be properly balanced or nobody will do the testing.
>
> - The time waiting for a tester is often useful to rethink and
> refine the solution and perhaps even improve on the docs.
Here you are proposing a formal test process before merging. I'm not
sure how I feel about this. Speaking personally, I don't have the time
to test *all* of other peopls code, they could wait for me for a long
time, this will cause problems. I prefer to trust that they have tested
it sufficiently before commiting and merging.
(longer term I would prefer a proper test suite in Forrest, but that is
a whole different thing and should not delay progress on your proposal).
Ross
Re: [Proposal] Development process and a stable trunk
Posted by Ferdinand Soethe <fe...@apache.org>.
Thanks everybody for taking the time to respond and giving me a change
to re-think and refine my own thoughts on these issues.
Here are some comments for a start:
- Ignoring of threads (or developments)
I'm sorry to say this but I'm simply not able to read everything that's
on this list all the time. And even though this might have to do
with going kayaking too often in my case :-), I think that with growing
volume of project and list this will happen to most of us sooner or
later.
For me prioritizing stuff in this list is a necessity rather
than a choice. And at the moment I can never tell the relevance of a
thread to Forrest as a hole.
I know that it would be nice if all of us could follow all the
threads, but honestly, is that realistic?
Also: A lot of people might join the list without the interest or
the capacity to follow all our discussion from the start. Following
new developments from when a merger is proposed gives them a good interface to
cutting-edge forrest development without the bloodloss :-).
- When to branch
After considering your responses I realize that I need to refine the
criteria for branching:
Changes should happen in a branch when they
- change (not fix) to output
- require additional or different input
- change (not add) existing configuration options
The reason behind this demand is, that all these changes require
users and developers to adjust their applications or their coding
work in progress. So in order to do that efficiently they should
have well defined, finalized and properly documented changes to deal
with.
In addition I would suggest branching also
- when the internal workings
of a module are altered in a major way.
The reason for this being that anybody also working on, extending or
even debugging such a module does not get in the middle of somebody
else's major change or has to guesswork about the function of some
undocumented new piece of code.
- Vote on merging branches
I have no problem with the lazy consensus model her. What is more
important to me is that fact that at least some developers not
involved in the implementation should have looked at (not just 'have
had a chance to look at') and tried the new functionality.
Now I know that this is hard because you have to get somebody to do
this and perhaps even wait for them to do it. But on the other hand
I expect this to have a couple of useful side effects:
- Documentation and value of the new developed functionality have to
be properly balanced or nobody will do the testing.
- The time waiting for a tester is often useful to rethink and
refine the solution and perhaps even improve on the docs.
--
Ferdinand Soethe
Re: Help with general project issues
Posted by David Crossley <cr...@apache.org>.
Tim Williams wrote:
> David Crossley wrote:
> >
> > Most of my time is being taken up with general issues
> > for the Forrest project, so i don't often have the
> > time to help. I wish that other people would help more
> > with that stuff, applying the patches, guiding the
> > new developers.
>
> What's "that stuff"? I'm happy to help beyond just development work
> if I know what the "issues" are.
Lots of assorted stuff :-)
Applying patches, tidying up Jira, helping new developers
get started, helping new committers get started,
linking relevant mail threads to issues, documenting
the important decisions, restarting important mail threads
that have gone stagnant, publishing the website when people
have made doc changes (e.g. after adding new example site
requests), making sure that the ForrestTuesday initiative
happens, etc.
-David
Re: Help with general project issues [was: Re: [Proposal] Development
process and a stable trunk
Posted by Ross Gardler <rg...@apache.org>.
Tim Williams wrote:
> On 8/27/05, David Crossley <cr...@apache.org> wrote:
>
>>Most of my time is being taken up with general issues
>>for the Forrest project, so i don't often have the
>>time to help. I wish that other people would help more
>>with that stuff, applying the patches, guiding the
>>new developers.
>
>
> What's "that stuff"? I'm happy to help beyond just development work
> if I know what the "issues" are.
Basically, most of what David does is the "stuff" that the rest of us
largely ignore but is absolutely vital to the survival of the project ;-)
Here are a few thinks that I think David may be referring to (I am sure
he'll add some more to the list):
- maintenance of the published site
- configuration of a testing environment on our Zone
- maintenance of Jira
- issues linked to discussions
- links between issues
- proofing documentation
- ensuring user feedback is reflected in our documentation
- checking license files are correct and complete
- applying bug fixes
- fixing bugs (rather than creating new features)
- running "build test" before committing changes
- ...
Ross
Help with general project issues [was: Re: [Proposal] Development process and a stable trunk
Posted by Tim Williams <wi...@gmail.com>.
On 8/27/05, David Crossley <cr...@apache.org> wrote:
>
> Most of my time is being taken up with general issues
> for the Forrest project, so i don't often have the
> time to help. I wish that other people would help more
> with that stuff, applying the patches, guiding the
> new developers.
What's "that stuff"? I'm happy to help beyond just development work
if I know what the "issues" are.
--tim
Re: [Proposal] Development process and a stable trunk
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ross Gardler wrote:
...
> We need to decide how to use Jira to create this ToDo list and then
> we need to start actually using it.
I'd concentrate on the "actually doing stuff" part (not directed to you
Ross, it's a general remark).
After having been on vacation, I now see hundreds of mails with lots of
words and very little content, and even ignoring complete threads like
I'm already doing is proving to be not enough.
If the signal to noise ratio will not improve, we will have more
problems with newcomers, and I will be forced to unsubscribe for lack of
time.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [Proposal] Development process and a stable trunk
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Sun, 2005-08-28 at 14:19 +1000, David Crossley wrote:
>
>>Thorsten Scherler wrote:
>>
>>>Before you read this reply, please read again my original reply.
>>>
>>>Did you read it, ok then go ahead and please be not offended that your
>>>name may not be mentioned here or in the other thread but you actually
>>>contributed to views in any form. That is not my intention. I was
>>>focusing on code for views and the common danger of ignoring threads.
>>
>>First of all, you will need to try very hard to
>>be able to offend me. You were not.
>>
>
>
> :) Cheers for telling me this, that is a relief.
>
> I am lucky that you are know me quite well because you help me from the
> beginning.
That is true, but the point I was trying to make about offending people
is that many people do not know us quite so well. We have to be careful
not to offend newcomers. Did you see the recent thread on the infra@
list about netiquette? It asked if there is a problem here in Apache.
The only conclusion I drew from it was that too many of us have formed a
little "group" within the community who know each other well and so
cutting remarks are taken in context of that relationship. These remarks
often alienate newcomers who do not have the background of the older
community members.
I only raised the issue to keep us aware of the potential problem. I
think we all know the intention was not to discredit anyone. But even in
your response you said something about nobody else has committed code.
That is also not true, nor is it important since discussion is an
equally valued part of the community. We need to be careful about
statements that remove the recognition of the community from people who
contribute.
There's no need for you to respond, I know you well enough to see it as
an oversifght. I am raising it as a broader community issue, and I know
you have the thick skin to cope with any percieved criticism - we all
know that we write poor emails sometimes, this is a "community awareness
broadcast". Interestingly, when I wrote the original mail it wasn't
David or myself that I thought may be offended, but some other newer
members of the community who have also contributed to forrest:views -
seems my own mail was a problem in the community sense :-((
..
>>I agree whole-heartedly with your warning about ignoring
>>threads and at the same time i am saying that we need to
>>allow people to particpate in some things and not others.
>>
>
>
> Yes, I agree but we need to define core components and this core
> components should be understood and enhanceable from many active PMC
> member. I really do not want to see that we depend on individuals, we
> have do depend on the community.
>
> That is as well why I think we should rename whiteboard to incubation.
> All components that need more community support should go here. If we
> want to follow Stephano's dreamlist we have to be very clear on the
> community part of components.
I have no problem renaming the whiteboard. There is sense in your
proposal. I would recomend starting a new thread saying you are going to
do it unless someone objects.
...
>>If other people helped more with applying patches,
>>then people like me would be relieved and could help
>>more with views development. There is one patch
>>sitting there from a new developer. Who is going to
>>commit it before i get compelled to jump in?
>>
>
>
> You are right. That is really a thing that I need working on. Anyway,
> like always said, I see views different and by getting into views I
> understood that this will change the general parts of the project. That
> is why I keep on asking for getting the views integration done.
Just do it (in a branch), I proposed removal of views from whiteboard
immediately after the 0.7 release. You refused, wanting it to stay in
whitebaord, you said it wasn't ready. I had the time then, but not now.
I took that time to build a site using views. That site is now in
production - in my opinion views is stable enough, it is only
implementation details that will change.
Don't wait for me (speaking personally) since I am more keen to simplify
our sitemaps using the locationmap, I think this will make forrest:views
integration easier. However, I don't know when I will be able to do
this, other commitments are in the way right now.
> Let me give you an example. The xhtml2 change will force us to rewrite
> the same pipes that we need to change for the views core integration!
So will the locationmap work :-(
> Another point is the integration of the locationmap. Right now it is set
> up but there have to be touched a lot of pipes to really use it, again
> that are nearly the same like for views. Knowing this made me ask
> everybody to get into views.
I'm sorry, it just doesn't owrk that way. Most of us are not here as a
hobby or a play thing. Most of us use Forrest as part of our jobs. THat
means we have to focus on the parts that are important to our job
function. Get views into trunk (you have my +1 for a long time now) and
it will *force* people to "get into views". With it in whitebaord it
will only get people who have a specific need for views.
I don't have that use case yet, but I know there are a number of use
cases on the horizon that would benefit from views in the future. Get it
in core and I am more likely to move forwards.
In the meantime, any time I find to do none-essential stuff on Forrest
will be refactoring to us the locationmap. That is *my* itch and I will
scratch it now that Tim has made it possible for me to do so - if you
start a branch to integrate views, I'll do the locationmap refactoring
in their too, as you say this makes sense since they touch the same
pipelines.
(agreeing naming conventions is the hold up right now, but that can be
done in the branch before we merge)
>>I agree entirely. We were actually giving other cases
>>in support of that. It is a recognised fact that each
>>area has one or two main developers. It is important that
>>we all do broaden our focus to assist with other areas.
...
> We all have to dive into all core areas of forrest I totally agree. IMO
> if somebody start using views that will be pretty obvious to
> him/her. ;-)
Get views into core then ;-)
>>Then we need to finalise it and do the renaming actions
>>that were discussed. That is the backgound work that
>>needs to happen before the rest of the project can
>>really assist with views.
>
>
> Agreed, but just let us get over it and like Dave used to say "more
> code, less talk".
The code is there!
> I am talking about views, their background and
> concepts since last year, it is all in the archives. I am a wee bit
> tiered to constantly repeating myself.
Defining the correct name is nothing to do with talk. It is about making
future communications easier by removing as many possible
misunderstandings as we can. That prevents the need to repeat oneself
because it makes things easier to understand for those without the
background you have.
>>The naming is extremely important, well chosen names
>>are very powerful. They can instantaneously convey
>>the whole concept.
>>
>
>
> Yes, agreed. I have chosen the names because I thought they will do
> that. I failed and need help on that. ;-)
[1] http://marc.theaimsgroup.com/?t=112276643700001
Re: Defining Views Terminology
>>>Please feel free to propose new naming convention for views and assume
>>>that lazy consensus is in operation from my part. Be sure if I see a
>>>problem or an easier way of doing things that I will speak up.
>>
>>Please no, we need your input.
>
>
> Hmm, actually it is all in the archive. Anyway, I will help out where I
> can.
[1] http://marc.theaimsgroup.com/?t=112276643700001
Re: Defining Views Terminology
>>For me, one of the best things about [1] was that it
>>started to define all the separate pieces of the puzzle
>>and helped me to see more of what "views" are about.
>>However, it is still too clouded.
>>
>
>
> jeje
>
> ok, I see your point. It is dead easy if you have started once. ;-)
Cool, David, thank you for reviving this thread. I took a long time to
craft that mail to try and bring consensus, I thought it had got lost
and I had wasted my time. Your persistence has, once again, brought it
to the surface [privately wishing I had Davids organisational skills]
> Discussions (doco, xhmtl2,...) have to lead to roadmaps and code,
> otherwise they follow the motto "nice having talked about it". See
> Joachim, David et. al. they would welcome a to do list that they can
> follow. Having said this, it is hard to make such lists. ;-)
+1
This brings us right back to where this thread started. Managing the
development process. See the threads linked in my very first reply. We
need to decide how to use Jira to create this ToDo list and then we need
to start actually using it.
Ross
Re: [Proposal] Development process and a stable trunk
Posted by Thorsten Scherler <th...@apache.org>.
On Sun, 2005-08-28 at 14:19 +1000, David Crossley wrote:
> Thorsten Scherler wrote:
> > Before you read this reply, please read again my original reply.
> >
> > Did you read it, ok then go ahead and please be not offended that your
> > name may not be mentioned here or in the other thread but you actually
> > contributed to views in any form. That is not my intention. I was
> > focusing on code for views and the common danger of ignoring threads.
>
> First of all, you will need to try very hard to
> be able to offend me. You were not.
>
:) Cheers for telling me this, that is a relief.
I am lucky that you are know me quite well because you help me from the
beginning.
> I was trying to use myself as an example to show various
> things: that everyone has their own itches to scratch,
> silence does not mean disinterest, that people are actually
> reading your commits and emails but not necessarily
> contributing, people are busy doing other things, we each
> have something that we wish others would work more on,
> there are some fundamental issues that need to be cleared, etc.
>
I understand, believe me I really do.
The thread was as well only an example of myself.
> I try to use myself as an example so that there is no
> risk of other people getting offended or unnecessarily
> defensive. That backfired today :-)
>
;-)
> I agree whole-heartedly with your warning about ignoring
> threads and at the same time i am saying that we need to
> allow people to particpate in some things and not others.
>
Yes, I agree but we need to define core components and this core
components should be understood and enhanceable from many active PMC
member. I really do not want to see that we depend on individuals, we
have do depend on the community.
That is as well why I think we should rename whiteboard to incubation.
All components that need more community support should go here. If we
want to follow Stephano's dreamlist we have to be very clear on the
community part of components.
> By the way, thanks for daring to use "views" as a case
> to discuss these important issues about how this small
> yet diverse project can operate.
>
:) You are welcome.
> More below ...
>
> > Ross Gardler wrote:
> > > David Crossley wrote:
> > > > Thorsten Scherler wrote:
> > > >>
> > > >>All PMC members should feel responsible for *all* issues of forrest.
> > > >
> > > > We should do whatever we can manage and try to
> > > > not ignore anything.
> > > >
> > > >>My
> > > >>background is certainly views where I am the position of *not* ignoring
> > > >>this threads but sometimes it seems to me that the rest is doing it.
> > > >
> > > > Well i certainly am not. I try to read everything
> > > > and only respond if i think that i need to.
> > > > Even started my next project to use views, so
> > > > expect more development soon.
> > > >
> > > > I trust you to get on and do the best you can
> > > > and i will try to help when i can manage it.
> > > > Please don't take silence to mean that nobody cares.
> > > > That is not true.
> >
> > I should have written *seems*!
>
> You did already. I was trying to dispel your impression
> that nobody is interested.
>
> I should have prefaced my comments to explicitly
> say that i was supporting and exploring the issues,
> and that there was no offence.
>
Cheers.
> > I know and it was nothing against somebody en special and least against
> > you or Ross! See your response about the comments, I was not aware of it
> > myself and you pointed us in the right direction.
> >
> > Now if you would have kindly ignored the thread, then we would try to
> > find the problem in views. Thx for being an example for *not* ignoring
> > threads.
> >
> > > Yes, I think these comments are true for most devs. We all have limited
> > > time and assume that lazy consensus is in operation most of the time. To
> > > be honest, I am a little offended that my input, when it comes, is not
> > > recognised (actually I'm not, I know that is not what you meant but it
> > > supports my point, others, who do not know your style, may well be
> > > offended by comments like those above).
> >
> > I wrote:
> > > The answer is that Diwaker and Cyriaque are the only
> > > ones beside me that contributed to the code base.
> >
> > I was actually thinking about commits or patches that where made to the
> > view code base. I should have written committed.
> >
> > I always consider input as very welcome and you are right that this are
> > contributions as well.
> >
> > I am awe-fully sorry if I have offended somebody with my comments that
> > was not my intention. English is not my first language and my choice of
> > words seems to cause many confusion lately. I am sorry for that.
>
> No need. Even in one's native language these issues
> are hard to deal with. Important issues often are.
>
> Start from the point of trust. We know that you are
> not offending anyone. Feel free to say whatever you need.
>
jeje
Are you sure ;-)
thx
> > Anyway right now I wish more input with code examples and was talking
> > about that. If somebody recommend some changes to sources then this is
> > best done with code examples (aka patches) or commits. Diwaker and
> > Cyriaque provided patches that extended the views code base and enhanced
> > the implementation. For example David et. al. as well is committing to
> > the code base regularly, I did not mentioned everyone because I was
> > thinking about patches.
> >
> > > > Most of my time is being taken up with general issues
> > > > for the Forrest project, so i don't often have the
> > > > time to help. I wish that other people would help more
> > > > with that stuff, applying the patches, guiding the
> > > > new developers.
> > >
> > > +1000 (and a big thank you to David)
> >
> > Yes, you, David and Ross, are doing an awesome job. Thanks very much.
> > Sorry, if I offended you, it was not my intention.
>
> You didn't. Actually that was perhaps my fault.
> Re-read that paragraph. (Thanks to Tim for breaking
> into another important thread). I wonder if i should
> have been more explicit.
>
> I was suggesting that all of us need to slow down on
> our pet topics for a little while, help out more with
> the general parts of the project, especially the naming
> and core pipeline re-arrangement and efficiency issues
> that plague us at the moment. This will enable each of
> us to catch up and have a chance to investigate and then
> help with these new functionalities like "views".
>
> If other people helped more with applying patches,
> then people like me would be relieved and could help
> more with views development. There is one patch
> sitting there from a new developer. Who is going to
> commit it before i get compelled to jump in?
>
You are right. That is really a thing that I need working on. Anyway,
like always said, I see views different and by getting into views I
understood that this will change the general parts of the project. That
is why I keep on asking for getting the views integration done.
Let me give you an example. The xhtml2 change will force us to rewrite
the same pipes that we need to change for the views core integration!
Another point is the integration of the locationmap. Right now it is set
up but there have to be touched a lot of pipes to really use it, again
that are nearly the same like for views. Knowing this made me ask
everybody to get into views.
> > > >>That cannot keep on in the future. Let me give you an example why not.
> > > >>Imaging I have a car accident and dead (very drastic example I have to
> > > >>admit but it is possible). Now all forrest devs are kindly ignoring the
> > > >>[views] thread, what is happening then?
> > > >
> > > > We could say the same about things like the
> > > > catalog entity resolver. I wonder who else besides
> > > > me understands it or enhances it.
> > >
> > > Or plugins half way through the 0.7 dev, or the locationmap, or i18n or
> > > any one of the features within Forrest. Thorsten, you really must
> > > understand that you are only considering your own baby - it *is*
> > > important, but no more important than any of the other features being
> > > introduced.
> >
> > No, I actually did not only consider my own baby, that was only an
> > example. Replace [views] and my person with all your mentioned features
> > and they main supporter like Ross and plugins, David and catalog entity
> > resolver,...
> >
> > My point was that we cannot "kindly ignore" threads that may are not our
> > personal focus.
>
> I agree entirely. We were actually giving other cases
> in support of that. It is a recognised fact that each
> area has one or two main developers. It is important that
> we all do broaden our focus to assist with other areas.
>
Yes, that is as well a big topic over in cocoon land where many threads
contain something like "we do not need yet another one man block show".
I always tried not only to focus on views that is only the component
that I best understand in forrest. ;-) Views are historical a derivate
of skins, another area where only few forrest committer felt really
responsible.
We all have to dive into all core areas of forrest I totally agree. IMO
if somebody start using views that will be pretty obvious to
him/her. ;-)
> > > The level of input you get on views is comparable to the
> > > level of input on other peoples "babies".
> >
> > Yes, you are right. Maybe because it is replacing/extending skins.
> >
> > > As David said, silence means
> > > we trust you to do a good job, we speak up when we see a problem or an
> > > easier way of doing things, otherwise we let you get on with it (and in
> > > most cases use it with pleasure).
> >
> > Yes, again you are right. Sometimes I only wish that code example would
> > be a bigger part of the input.
> >
> > > > There other things that i want to solve with views
> > > > before diving in. Like the unfinished thread about
> > > > "Defining Views Terminology".
> > >
> > > +1000 - there was a proposal some time ago (written by someone not
> > > currently credited by you as doing any work for views). Your response to
> > > that was "I'm working on a proposal", but so far nothing has been
> > > forthcoming and we have not had your input on the second thread that
> > > David started (also not credited with doing any work on views).
> >
> > I did not add more to this threads because I did not had to add
> > anything. Everything was already said.
>
> Then we need to finalise it and do the renaming actions
> that were discussed. That is the backgound work that
> needs to happen before the rest of the project can
> really assist with views.
Agreed, but just let us get over it and like Dave used to say "more
code, less talk". I am talking about views, their background and
concepts since last year, it is all in the archives. I am a wee bit
tiered to constantly repeating myself.
>
> > Actually I have 10 different versions of this proposal in my draft dir
> > and I guess they contain all specific answers to the threads you
> > mentioned. Not one is there that I am convinced of. Actually on the end
> > I was on the one hand close to recommend to change nothing and on the
> > other to agree with all written by you and david. Further to rename e.g.
> > views into themes or structurer has as many downsides as keeping the
> > name IMO. I guess it is because I have my own point of view what views
> > are and I am obviously not able to explain myself. I guess if I could
> > explain and name it in German then that would be different.
>
> Hey that is a great idea. You take the thread [1]
> and summarise it to describe each facet of the
> "views" in German and English (the English ones
> are almost there just need summarising). Then
> because we have quite a few German speakers on
> this list, we can clarify the English definitions.
>
> [1] http://marc.theaimsgroup.com/?t=112276643700001
> Re: Defining Views Terminology
>
jeje
ok I will do that as time allows.
> > Anyway please be not offended that I have not given Ross and David
> > credits for the threads, which are really awesome. See above I had more
> > code in mind. I actually I will not keep on trying finishing the
> > proposal. I want to concentrate on coding views independent from any
> > naming rather then discussing the chosen names. It's all hollow words in
> > the end.
>
> The naming is extremely important, well chosen names
> are very powerful. They can instantaneously convey
> the whole concept.
>
Yes, agreed. I have chosen the names because I thought they will do
that. I failed and need help on that. ;-)
> > Please feel free to propose new naming convention for views and assume
> > that lazy consensus is in operation from my part. Be sure if I see a
> > problem or an easier way of doing things that I will speak up.
>
> Please no, we need your input.
Hmm, actually it is all in the archive. Anyway, I will help out where I
can.
>
> For me, one of the best things about [1] was that it
> started to define all the separate pieces of the puzzle
> and helped me to see more of what "views" are about.
> However, it is still too clouded.
>
jeje
ok, I see your point. It is dead easy if you have started once. ;-)
> The process that we started at ApacheCon was to
> carefully explain each piece and then the names
> would become apparent.
>
Perfect, anyway it was my mistake that I did not just gave a overview of
views and an example of the usage before we started this process. That
would have been better.
> > > [Note, I'm not pointing fingers with these bracketed comments, just
> > > trying to further illustrate my point of potential offense given by
> > > these statements]
> >
> > Sorry, that was not my intention.
> >
> > > > And i think that moving the core to XHTML2 is more
> > > > important at this stage, so i will put my "spare"
> > > > energy there. Don't see that as ignoring "views"
> > > > as i expect that will help.
> > >
> > > Actually, I thought forrest:views in core were going to be the first
> > > version of Forrest wusing XHTML2. So your work on XHTML2 *is* work on
> > > helping forrest:views move to core.
> >
> > Yes, but there a *million* thinks to do (coding) to move views to the
> > core. The changes of the contracts to accept xhtml2 as input I consider
> > as one of the easiest part in the process. As soon as we have a xhtml2
> > internal format we can quickly change the contracts. contracts are very
> > flexible in regards of input format. still that is only one thing.
> >
> > I agree that the move to xhtml2 is very important but IMO that should be
> > happen parallel to views integration.
>
> We need a concentrated effort from all developers
> to move the core to xhtml2. The job is too big to
> be left to one or two people - it will not happen.
> I suggest that we all need to stop scratching our
> own itches for a little while and just do it.
>
See above. Calling for community help for views has the background that
I see we need to touch the same pipes for XHTML2, LM and Views. Why
touching them 3 times when we can touch them once.
Yes, we all have to help out for the integration. First we have to have
a basic example for xhtml2 internal which we can discuss and implement.
Which leads to the other point of my thread that we need more discussion
with actual code example and less general discussion.
Discussions (doco, xhmtl2,...) have to lead to roadmaps and code,
otherwise they follow the motto "nice having talked about it". See
Joachim, David et. al. they would welcome a to do list that they can
follow. Having said this, it is hard to make such lists. ;-)
BTW talking about pets, we have to release them into the wildness
again. ;-)
> -David
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [Proposal] Development process and a stable trunk
Posted by David Crossley <cr...@apache.org>.
Thorsten Scherler wrote:
> Before you read this reply, please read again my original reply.
>
> Did you read it, ok then go ahead and please be not offended that your
> name may not be mentioned here or in the other thread but you actually
> contributed to views in any form. That is not my intention. I was
> focusing on code for views and the common danger of ignoring threads.
First of all, you will need to try very hard to
be able to offend me. You were not.
I was trying to use myself as an example to show various
things: that everyone has their own itches to scratch,
silence does not mean disinterest, that people are actually
reading your commits and emails but not necessarily
contributing, people are busy doing other things, we each
have something that we wish others would work more on,
there are some fundamental issues that need to be cleared, etc.
I try to use myself as an example so that there is no
risk of other people getting offended or unnecessarily
defensive. That backfired today :-)
I agree whole-heartedly with your warning about ignoring
threads and at the same time i am saying that we need to
allow people to particpate in some things and not others.
By the way, thanks for daring to use "views" as a case
to discuss these important issues about how this small
yet diverse project can operate.
More below ...
> Ross Gardler wrote:
> > David Crossley wrote:
> > > Thorsten Scherler wrote:
> > >>
> > >>All PMC members should feel responsible for *all* issues of forrest.
> > >
> > > We should do whatever we can manage and try to
> > > not ignore anything.
> > >
> > >>My
> > >>background is certainly views where I am the position of *not* ignoring
> > >>this threads but sometimes it seems to me that the rest is doing it.
> > >
> > > Well i certainly am not. I try to read everything
> > > and only respond if i think that i need to.
> > > Even started my next project to use views, so
> > > expect more development soon.
> > >
> > > I trust you to get on and do the best you can
> > > and i will try to help when i can manage it.
> > > Please don't take silence to mean that nobody cares.
> > > That is not true.
>
> I should have written *seems*!
You did already. I was trying to dispel your impression
that nobody is interested.
I should have prefaced my comments to explicitly
say that i was supporting and exploring the issues,
and that there was no offence.
> I know and it was nothing against somebody en special and least against
> you or Ross! See your response about the comments, I was not aware of it
> myself and you pointed us in the right direction.
>
> Now if you would have kindly ignored the thread, then we would try to
> find the problem in views. Thx for being an example for *not* ignoring
> threads.
>
> > Yes, I think these comments are true for most devs. We all have limited
> > time and assume that lazy consensus is in operation most of the time. To
> > be honest, I am a little offended that my input, when it comes, is not
> > recognised (actually I'm not, I know that is not what you meant but it
> > supports my point, others, who do not know your style, may well be
> > offended by comments like those above).
>
> I wrote:
> > The answer is that Diwaker and Cyriaque are the only
> > ones beside me that contributed to the code base.
>
> I was actually thinking about commits or patches that where made to the
> view code base. I should have written committed.
>
> I always consider input as very welcome and you are right that this are
> contributions as well.
>
> I am awe-fully sorry if I have offended somebody with my comments that
> was not my intention. English is not my first language and my choice of
> words seems to cause many confusion lately. I am sorry for that.
No need. Even in one's native language these issues
are hard to deal with. Important issues often are.
Start from the point of trust. We know that you are
not offending anyone. Feel free to say whatever you need.
> Anyway right now I wish more input with code examples and was talking
> about that. If somebody recommend some changes to sources then this is
> best done with code examples (aka patches) or commits. Diwaker and
> Cyriaque provided patches that extended the views code base and enhanced
> the implementation. For example David et. al. as well is committing to
> the code base regularly, I did not mentioned everyone because I was
> thinking about patches.
>
> > > Most of my time is being taken up with general issues
> > > for the Forrest project, so i don't often have the
> > > time to help. I wish that other people would help more
> > > with that stuff, applying the patches, guiding the
> > > new developers.
> >
> > +1000 (and a big thank you to David)
>
> Yes, you, David and Ross, are doing an awesome job. Thanks very much.
> Sorry, if I offended you, it was not my intention.
You didn't. Actually that was perhaps my fault.
Re-read that paragraph. (Thanks to Tim for breaking
into another important thread). I wonder if i should
have been more explicit.
I was suggesting that all of us need to slow down on
our pet topics for a little while, help out more with
the general parts of the project, especially the naming
and core pipeline re-arrangement and efficiency issues
that plague us at the moment. This will enable each of
us to catch up and have a chance to investigate and then
help with these new functionalities like "views".
If other people helped more with applying patches,
then people like me would be relieved and could help
more with views development. There is one patch
sitting there from a new developer. Who is going to
commit it before i get compelled to jump in?
> > >>That cannot keep on in the future. Let me give you an example why not.
> > >>Imaging I have a car accident and dead (very drastic example I have to
> > >>admit but it is possible). Now all forrest devs are kindly ignoring the
> > >>[views] thread, what is happening then?
> > >
> > > We could say the same about things like the
> > > catalog entity resolver. I wonder who else besides
> > > me understands it or enhances it.
> >
> > Or plugins half way through the 0.7 dev, or the locationmap, or i18n or
> > any one of the features within Forrest. Thorsten, you really must
> > understand that you are only considering your own baby - it *is*
> > important, but no more important than any of the other features being
> > introduced.
>
> No, I actually did not only consider my own baby, that was only an
> example. Replace [views] and my person with all your mentioned features
> and they main supporter like Ross and plugins, David and catalog entity
> resolver,...
>
> My point was that we cannot "kindly ignore" threads that may are not our
> personal focus.
I agree entirely. We were actually giving other cases
in support of that. It is a recognised fact that each
area has one or two main developers. It is important that
we all do broaden our focus to assist with other areas.
> > The level of input you get on views is comparable to the
> > level of input on other peoples "babies".
>
> Yes, you are right. Maybe because it is replacing/extending skins.
>
> > As David said, silence means
> > we trust you to do a good job, we speak up when we see a problem or an
> > easier way of doing things, otherwise we let you get on with it (and in
> > most cases use it with pleasure).
>
> Yes, again you are right. Sometimes I only wish that code example would
> be a bigger part of the input.
>
> > > There other things that i want to solve with views
> > > before diving in. Like the unfinished thread about
> > > "Defining Views Terminology".
> >
> > +1000 - there was a proposal some time ago (written by someone not
> > currently credited by you as doing any work for views). Your response to
> > that was "I'm working on a proposal", but so far nothing has been
> > forthcoming and we have not had your input on the second thread that
> > David started (also not credited with doing any work on views).
>
> I did not add more to this threads because I did not had to add
> anything. Everything was already said.
Then we need to finalise it and do the renaming actions
that were discussed. That is the backgound work that
needs to happen before the rest of the project can
really assist with views.
> Actually I have 10 different versions of this proposal in my draft dir
> and I guess they contain all specific answers to the threads you
> mentioned. Not one is there that I am convinced of. Actually on the end
> I was on the one hand close to recommend to change nothing and on the
> other to agree with all written by you and david. Further to rename e.g.
> views into themes or structurer has as many downsides as keeping the
> name IMO. I guess it is because I have my own point of view what views
> are and I am obviously not able to explain myself. I guess if I could
> explain and name it in German then that would be different.
Hey that is a great idea. You take the thread [1]
and summarise it to describe each facet of the
"views" in German and English (the English ones
are almost there just need summarising). Then
because we have quite a few German speakers on
this list, we can clarify the English definitions.
[1] http://marc.theaimsgroup.com/?t=112276643700001
Re: Defining Views Terminology
> Anyway please be not offended that I have not given Ross and David
> credits for the threads, which are really awesome. See above I had more
> code in mind. I actually I will not keep on trying finishing the
> proposal. I want to concentrate on coding views independent from any
> naming rather then discussing the chosen names. It's all hollow words in
> the end.
The naming is extremely important, well chosen names
are very powerful. They can instantaneously convey
the whole concept.
> Please feel free to propose new naming convention for views and assume
> that lazy consensus is in operation from my part. Be sure if I see a
> problem or an easier way of doing things that I will speak up.
Please no, we need your input.
For me, one of the best things about [1] was that it
started to define all the separate pieces of the puzzle
and helped me to see more of what "views" are about.
However, it is still too clouded.
The process that we started at ApacheCon was to
carefully explain each piece and then the names
would become apparent.
> > [Note, I'm not pointing fingers with these bracketed comments, just
> > trying to further illustrate my point of potential offense given by
> > these statements]
>
> Sorry, that was not my intention.
>
> > > And i think that moving the core to XHTML2 is more
> > > important at this stage, so i will put my "spare"
> > > energy there. Don't see that as ignoring "views"
> > > as i expect that will help.
> >
> > Actually, I thought forrest:views in core were going to be the first
> > version of Forrest wusing XHTML2. So your work on XHTML2 *is* work on
> > helping forrest:views move to core.
>
> Yes, but there a *million* thinks to do (coding) to move views to the
> core. The changes of the contracts to accept xhtml2 as input I consider
> as one of the easiest part in the process. As soon as we have a xhtml2
> internal format we can quickly change the contracts. contracts are very
> flexible in regards of input format. still that is only one thing.
>
> I agree that the move to xhtml2 is very important but IMO that should be
> happen parallel to views integration.
We need a concentrated effort from all developers
to move the core to xhtml2. The job is too big to
be left to one or two people - it will not happen.
I suggest that we all need to stop scratching our
own itches for a little while and just do it.
-David
Re: [Proposal] Development process and a stable trunk
Posted by Thorsten Scherler <th...@apache.org>.
Before you read this reply, please read again my original reply.
Did you read it, ok then go ahead and please be not offended that your
name may not be mentioned here or in the other thread but you actually
contributed to views in any form. That is not my intention. I was
focusing on code for views and the common danger of ignoring threads.
On Sat, 2005-08-27 at 14:51 +0100, Ross Gardler wrote:
> David Crossley wrote:
> > Thorsten Scherler wrote:
> >
> >>Ferdinand Soethe wrote:
> >>
> >>
> >>>5 As a supportive measure, clearly mark threads in this list when they
> >>> deal with a particular branch
> >>
> >>+1
> >>
> >>
> >>>so that people not working on that
> >>> issue can safely ignore it.
> >>
> >>-1
> >>
> >>All PMC members should feel responsible for *all* issues of forrest.
> >
> >
> > We should do whatever we can manage and try to
> > not ignore anything.
> >
> >
> >>My
> >>background is certainly views where I am the position of *not* ignoring
> >>this threads but sometimes it seems to me that the rest is doing it.
> >
> >
> > Well i certainly am not. I try to read everything
> > and only respond if i think that i need to.
> > Even started my next project to use views, so
> > expect more development soon.
> >
> > I trust you to get on and do the best you can
> > and i will try to help when i can manage it.
> > Please don't take silence to mean that nobody cares.
> > That is not true.
>
I should have written *seems*!
I know and it was nothing against somebody en special and least against
you or Ross! See your response about the comments, I was not aware of it
myself and you pointed us in the right direction.
Now if you would have kindly ignored the thread, then we would try to
find the problem in views. Thx for being an example for *not* ignoring
threads.
> Yes, I think these comments are true for most devs. We all have limited
> time and assume that lazy consensus is in operation most of the time. To
> be honest, I am a little offended that my input, when it comes, is not
> recognised (actually I'm not, I know that is not what you meant but it
> supports my point, others, who do not know your style, may well be
> offended by comments like those above).
>
I wrote:
> The answer is that Diwaker and Cyriaque are the only
> ones beside me that contributed to the code base.
I was actually thinking about commits or patches that where made to the
view code base. I should have written committed.
I always consider input as very welcome and you are right that this are
contributions as well.
I am awe-fully sorry if I have offended somebody with my comments that
was not my intention. English is not my first language and my choice of
words seems to cause many confusion lately. I am sorry for that.
Anyway right now I wish more input with code examples and was talking
about that. If somebody recommend some changes to sources then this is
best done with code examples (aka patches) or commits. Diwaker and
Cyriaque provided patches that extended the views code base and enhanced
the implementation. For example David et. al. as well is committing to
the code base regularly, I did not mentioned everyone because I was
thinking about patches.
> > Most of my time is being taken up with general issues
> > for the Forrest project, so i don't often have the
> > time to help. I wish that other people would help more
> > with that stuff, applying the patches, guiding the
> > new developers.
>
> +1000 (and a big thank you to David)
>
Yes, you, David and Ross, are doing an awesome job. Thanks very much.
Sorry, if I offended you, it was not my intention.
> >>That cannot keep on in the future. Let me give you an example why not.
> >>Imaging I have a car accident and dead (very drastic example I have to
> >>admit but it is possible). Now all forrest devs are kindly ignoring the
> >>[views] thread, what is happening then?
> >
> >
> > We could say the same about things like the
> > catalog entity resolver. I wonder who else besides
> > me understands it or enhances it.
>
> Or plugins half way through the 0.7 dev, or the locationmap, or i18n or
> any one of the features within Forrest. Thorsten, you really must
> understand that you are only considering your own baby - it *is*
> important, but no more important than any of the other features being
> introduced.
No, I actually did not only consider my own baby, that was only an
example. Replace [views] and my person with all your mentioned features
and they main supporter like Ross and plugins, David and catalog entity
resolver,...
My point was that we cannot "kindly ignore" threads that may are not our
personal focus.
> The level of input you get on views is comparable to the
> level of input on other peoples "babies".
Yes, you are right. Maybe because it is replacing/extending skins.
> As David said, silence means
> we trust you to do a good job, we speak up when we see a problem or an
> easier way of doing things, otherwise we let you get on with it (and in
> most cases use it with pleasure).
>
Yes, again you are right. Sometimes I only wish that code example would
be a bigger part of the input.
> > There other things that i want to solve with views
> > before diving in. Like the unfinished thread about
> > "Defining Views Terminology".
>
> +1000 - there was a proposal some time ago (written by someone not
> currently credited by you as doing any work for views). Your response to
> that was "I'm working on a proposal", but so far nothing has been
> forthcoming and we have not had your input on the second thread that
> David started (also not credited with doing any work on views).
>
I did not add more to this threads because I did not had to add
anything. Everything was already said.
Actually I have 10 different versions of this proposal in my draft dir
and I guess they contain all specific answers to the threads you
mentioned. Not one is there that I am convinced of. Actually on the end
I was on the one hand close to recommend to change nothing and on the
other to agree with all written by you and david. Further to rename e.g.
views into themes or structurer has as many downsides as keeping the
name IMO. I guess it is because I have my own point of view what views
are and I am obviously not able to explain myself. I guess if I could
explain and name it in German then that would be different.
Anyway please be not offended that I have not given Ross and David
credits for the threads, which are really awesome. See above I had more
code in mind. I actually I will not keep on trying finishing the
proposal. I want to concentrate on coding views independent from any
naming rather then discussing the chosen names. It's all hollow words in
the end.
Please feel free to propose new naming convention for views and assume
that lazy consensus is in operation from my part. Be sure if I see a
problem or an easier way of doing things that I will speak up.
> [Note, I'm not pointing fingers with these bracketed comments, just
> trying to further illustrate my point of potential offense given by
> these statements]
Sorry, that was not my intention.
>
> > And i think that moving the core to XHTML2 is more
> > important at this stage, so i will put my "spare"
> > energy there. Don't see that as ignoring "views"
> > as i expect that will help.
>
> Actually, I thought forrest:views in core were going to be the first
> version of Forrest wusing XHTML2. So your work on XHTML2 *is* work on
> helping forrest:views move to core.
>
Yes, but there a *million* thinks to do (coding) to move views to the
core. The changes of the contracts to accept xhtml2 as input I consider
as one of the easiest part in the process. As soon as we have a xhtml2
internal format we can quickly change the contracts. contracts are very
flexible in regards of input format. still that is only one thing.
I agree that the move to xhtml2 is very important but IMO that should be
happen parallel to views integration.
> Ross
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [Proposal] Development process and a stable trunk
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Thorsten Scherler wrote:
>
>>Ferdinand Soethe wrote:
>>
>>
>>>5 As a supportive measure, clearly mark threads in this list when they
>>> deal with a particular branch
>>
>>+1
>>
>>
>>>so that people not working on that
>>> issue can safely ignore it.
>>
>>-1
>>
>>All PMC members should feel responsible for *all* issues of forrest.
>
>
> We should do whatever we can manage and try to
> not ignore anything.
>
>
>>My
>>background is certainly views where I am the position of *not* ignoring
>>this threads but sometimes it seems to me that the rest is doing it.
>
>
> Well i certainly am not. I try to read everything
> and only respond if i think that i need to.
> Even started my next project to use views, so
> expect more development soon.
>
> I trust you to get on and do the best you can
> and i will try to help when i can manage it.
> Please don't take silence to mean that nobody cares.
> That is not true.
Yes, I think these comments are true for most devs. We all have limited
time and assume that lazy consensus is in operation most of the time. To
be honest, I am a little offended that my input, when it comes, is not
recognised (actually I'm not, I know that is not what you meant but it
supports my point, others, who do not know your style, may well be
offended by comments like those above).
> Most of my time is being taken up with general issues
> for the Forrest project, so i don't often have the
> time to help. I wish that other people would help more
> with that stuff, applying the patches, guiding the
> new developers.
+1000 (and a big thank you to David)
>>That cannot keep on in the future. Let me give you an example why not.
>>Imaging I have a car accident and dead (very drastic example I have to
>>admit but it is possible). Now all forrest devs are kindly ignoring the
>>[views] thread, what is happening then?
>
>
> We could say the same about things like the
> catalog entity resolver. I wonder who else besides
> me understands it or enhances it.
Or plugins half way through the 0.7 dev, or the locationmap, or i18n or
any one of the features within Forrest. Thorsten, you really must
understand that you are only considering your own baby - it *is*
important, but no more important than any of the other features being
introduced. The level of input you get on views is comparable to the
level of input on other peoples "babies". As David said, silence means
we trust you to do a good job, we speak up when we see a problem or an
easier way of doing things, otherwise we let you get on with it (and in
most cases use it with pleasure).
> There other things that i want to solve with views
> before diving in. Like the unfinished thread about
> "Defining Views Terminology".
+1000 - there was a proposal some time ago (written by someone not
currently credited by you as doing any work for views). Your response to
that was "I'm working on a proposal", but so far nothing has been
forthcoming and we have not had your input on the second thread that
David started (also not credited with doing any work on views).
[Note, I'm not pointing fingers with these bracketed comments, just
trying to further illustrate my point of potential offense given by
these statements]
> And i think that moving the core to XHTML2 is more
> important at this stage, so i will put my "spare"
> energy there. Don't see that as ignoring "views"
> as i expect that will help.
Actually, I thought forrest:views in core were going to be the first
version of Forrest wusing XHTML2. So your work on XHTML2 *is* work on
helping forrest:views move to core.
Ross
Re: [Proposal] Development process and a stable trunk
Posted by David Crossley <cr...@apache.org>.
Thorsten Scherler wrote:
> Ferdinand Soethe wrote:
>
> > 5 As a supportive measure, clearly mark threads in this list when they
> > deal with a particular branch
>
> +1
>
> > so that people not working on that
> > issue can safely ignore it.
>
> -1
>
> All PMC members should feel responsible for *all* issues of forrest.
We should do whatever we can manage and try to
not ignore anything.
> My
> background is certainly views where I am the position of *not* ignoring
> this threads but sometimes it seems to me that the rest is doing it.
Well i certainly am not. I try to read everything
and only respond if i think that i need to.
Even started my next project to use views, so
expect more development soon.
I trust you to get on and do the best you can
and i will try to help when i can manage it.
Please don't take silence to mean that nobody cares.
That is not true.
Most of my time is being taken up with general issues
for the Forrest project, so i don't often have the
time to help. I wish that other people would help more
with that stuff, applying the patches, guiding the
new developers.
> That cannot keep on in the future. Let me give you an example why not.
> Imaging I have a car accident and dead (very drastic example I have to
> admit but it is possible). Now all forrest devs are kindly ignoring the
> [views] thread, what is happening then?
We could say the same about things like the
catalog entity resolver. I wonder who else besides
me understands it or enhances it.
> Luckily there are some other devs that have started using views but
> developing them? The answer is that Diwaker and Cyriaque are the only
> ones beside me that contributed to the code base. Still I am the only
> one that is developing the views core.
That happens sometimes.
There other things that i want to solve with views
before diving in. Like the unfinished thread about
"Defining Views Terminology".
And i think that moving the core to XHTML2 is more
important at this stage, so i will put my "spare"
energy there. Don't see that as ignoring "views"
as i expect that will help.
> IMO views will be one of the major reasons for user to use forrest. We
> need more devs that are helping to develop the core and not
> "people not working on that issue can safely ignore it."
Yes, and that goes for all parts of development.
So i agree that nothing can be "safely ignored".
It sounds like Ferdinand's off-hand comment hit
a raw nerve that we know is there. I had a similar one
at Cocoon with the entity resolver and with the docs.
Please don't get dejected. At least we have two new
committers starting to help on views.
-David
Re: [Proposal] Development process and a stable trunk
Posted by Thorsten Scherler <th...@wyona.com>.
On Fri, 2005-08-26 at 07:28 +0200, Ferdinand Soethe wrote:
> 5 As a supportive measure, clearly mark threads in this list when they
> deal with a particular branch
+1
> so that people not working on that
> issue can safely ignore it.
-1
All PMC members should feel responsible for *all* issues of forrest. My
background is certainly views where I am the position of *not* ignoring
this threads but sometimes it seems to me that the rest is doing it.
That cannot keep on in the future. Let me give you an example why not.
Imaging I have a car accident and dead (very drastic example I have to
admit but it is possible). Now all forrest devs are kindly ignoring the
[views] thread, what is happening then?
Luckily there are some other devs that have started using views but
developing them? The answer is that Diwaker and Cyriaque are the only
ones beside me that contributed to the code base. Still I am the only
one that is developing the views core.
IMO views will be one of the major reasons for user to use forrest. We
need more devs that are helping to develop the core and not
"people not working on that issue can safely ignore it."
salu2
--
Thorsten Scherler
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
thorsten.scherler@wyona.com thorsten@apache.org