You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Dave Brondsema <da...@brondsema.net> on 2004/11/17 14:57:36 UTC
code vs. talk
I was in #kde-devel yesterday and saw the title was "development happens
in CVS, we discuss politics here".
We've been doing a lot of talk lately here (more than I have time to
read, personally). Our policy is "commit then review" and I think we
need to do that a lot more. Non-committers can submit patches. And
that would be great, because that's the biggest step to becoming a
committer, and we'd like to have more :-) So just go ahead and do
something; feel free to "stomp on people's toes", if there's problems
we'll fix the code and evolve the code.
Certainly talking here about big changes is good, but if nobody's
planning on following it up directly with code, what's the point?
--
Dave Brondsema : dave@brondsema.net
http://www.splike.com : programming
http://csx.calvin.edu : student org
http://www.brondsema.net : personal
Re: code vs. talk
Posted by Thorsten Scherler <th...@apache.org>.
El mié, 17-11-2004 a las 17:31, Ferdinand Soethe escribió:
> I'm still used to working the old way of concept first coding after, but
> I'll do my best to give it a try.
Do me and the community a favour, keep that up.
I mean the whole problem IMO with OS is that all of us tend to rush
things, *hacking* code without a clear concept.
The concept first, coding after will enable to follow e.g. a
architecture plan of the app, ... With that we will be able to not
*hack* but *program* an app. We need more software architect IMO. ;-)
my 2 rappen ;-)
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: code vs. talk
Posted by Antonio Gallardo <ag...@agssa.net>.
Ferdinand Soethe dijo:
I'm still used to working the old way of concept first coding after
I think this is the best approach. That way is very easy to change things
"just by one word(s)". ;-)
Best Regards,
Antonio Gallardo
Re[2]: code vs. talk
Posted by Ferdinand Soethe <sa...@soethe.net>.
Ferdinand Soethe wrote:
FS> I heard you too. ' Will probably take some time for me to get used to,
FS> as I'm still used to working the old way of concept first coding after, but
FS> I'll do my best to give it a try.
Seems I have created a misunderstanding here.
*** I was not advocating the old ways! ***
(even though I live in old Europe ;-)
I have read a good number of books that support the approach
that in Dave words are "policy of this project", so I'm in no position
to question the policy.
I was merely explaining that it was taking a bit of an effort on my
part to adjust to it.
--
Ferdinand Soethe
Re: code vs. talk
Posted by Ferdinand Soethe <sa...@soethe.net>.
Dave Brondsema wrote:
DB> Our policy is "commit then review" and I think we
DB> need to do that a lot more. Non-committers can submit patches. And
DB> that would be great, because that's the biggest step to becoming a
DB> committer, and we'd like to have more :-) So just go ahead and do
DB> something; feel free to "stomp on people's toes", if there's problems
DB> we'll fix the code and evolve the code.
I heard you too. ' Will probably take some time for me to get used to,
as I'm still used to working the old way of concept first coding after, but
I'll do my best to give it a try.
--
Ferdinand Soethe
Re: code vs. talk
Posted by Nicola Ken Barozzi <ni...@apache.org>.
David Crossley wrote:
> Dave Brondsema wrote:
>
>> I was in #kde-devel yesterday and saw the title was "development
>> happens in CVS, we discuss politics here".
>>
>> We've been doing a lot of talk lately here (more than I have time to
>> read, personally). Our policy is "commit then review"
That's the commit policy for small changes. Bigger ones should be done
knowing that we are following community consensus.
> I agree that we need to do more "commit then review".
> However, please be sure that the changes do not break
> the build system because this prevents other people
> working on the codebase. Do 'build test' first.
Yes, I definately agree. Not breaking builds makes it easier for others
to contribute. We could call it quasi-static development ;-)
>> Certainly talking here about big changes is good, but if nobody's
>> planning on following it up directly with code, what's the point?
>
> Because some issues need discussion before the developer
> can prepare the patch and this lets the rest of us
> know what the plan is.
>
> There is a trade-off.
>
> This "patch-then-review" process needs to be qualified.
> Developers need to be sure to provide a clear log message
> to accompany the patch, so that we all know the purpose
> and the consequences. Also add documentation where
> possible. Then, if it is really necessary, we can
> discuss later.
Yes.
In fact, I have started these discussions after seeing that some of my
changes on the dir structure had -correctly- created confusion and that
we are in need of synchronizing our development agenda.
The Forrest 1.0 document is the structure, not the implementation nor
the features, which will continue to be done more with CTR.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Testing (Re: code vs. talk)
Posted by Ross Gardler <rg...@apache.org>.
Ross Gardler wrote:
> Evrim ULU wrote:
>> IMO, only solution is unit testing.
...
> We do have some testing in place (do "build test", but it does need to
> be enhanced - and I, for one, have to get into the habit of using it).
> This needs extending.
It just occurred to me that as we strip stuff from core into plugins we
are also forced to strip it from fresh-site. Since fresh-site is what we
use for the basic testing we have this is not a good thing.
In the howto build a plugin document I encourage developers to make
their docs their tests by including lots of samples of the functionality
of the plugin. We need to make use of this in the "build test" target.
I think what we should do is have a "build.xml" file in each plugin,
with a target "test". By default this target will deploy the plugin
locally and build the plugin documentation.
Can someone with better Ant scripting skills than me make our
"main/build.xml" test target call all the test targets in all the
plugins located in the plugins directory.
I'll do the rest.
Ross
Testing (Re: code vs. talk)
Posted by Ross Gardler <rg...@apache.org>.
Evrim ULU wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> David Crossley wrote:
> | Dave Brondsema wrote:
> | There is a trade-off.
> |
> | This "patch-then-review" process needs to be qualified.
> | Developers need to be sure to provide a clear log message
> | to accompany the patch, so that we all know the purpose
> | and the consequences. Also add documentation where
> | possible. Then, if it is really necessary, we can
> | discuss later.
>
> I hate patch-review method. Current Linux-Netfilter project does this
> and somebody sends/apllies huge/core patches and attach a post-it like
> note like the following: "Lets see what will break?"
Well We are not advocating massive patches without discussion. Minor,
evolutionary changes are patch-then-review, major changes are discussed
and planned first.
> IMO, only solution is unit testing. After a patch is applied all unit
> tests are run to see what is broken.
I agree with the testing comment, but I would rather see testing
*before* commit.
> I have absolutely no experience
> with cocoon unit testing so any ideas are welcome. I'm sure some members
> have experience related to this topic.
Well unit testing (as in JUnit) is not totally relevant here since most
of what we do is XMAPs, XSL etc. More appropriate is that we test we can
output everthing we are supposed to and that it looks the way it should.
We do have some testing in place (do "build test", but it does need to
be enhanced - and I, for one, have to get into the habit of using it).
This needs extending.
There are two popular test frameworks for this kind of testing (that I
am familiar with):
Anteater - http://aft.sourceforge.net/manual/Introduction.html
Canoo Webtest - http://webtest.canoo.com/webtest/manual/syntax.html
> Apache has gump system for
> unit-tests of sub-projects AFAIK.
> Maybe we should try to use it since
> forrest is built on top of maven (+1).
We are part of the GUMP setup.
We are not "built on top of Maven", not sure what gives you that impression.
> As a conclusion, i will support any method that can be measured.
> Otherwise it'll be subjective and will change from person/developer to
> person/developer and i simply don't want forrest community efforts to
> degrade in time.
I can see this becoming an argument - I've seen it loads of times before
on Open Source lists. I will refrain from giving my view (as it is not
identical to your own), but would encourage you to help out with the
aspects most people agree on - testing.
Ross
Re: code vs. talk
Posted by Evrim ULU <ev...@core.gen.tr>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David Crossley wrote:
| Dave Brondsema wrote:
| There is a trade-off.
|
| This "patch-then-review" process needs to be qualified.
| Developers need to be sure to provide a clear log message
| to accompany the patch, so that we all know the purpose
| and the consequences. Also add documentation where
| possible. Then, if it is really necessary, we can
| discuss later.
I hate patch-review method. Current Linux-Netfilter project does this
and somebody sends/apllies huge/core patches and attach a post-it like
note like the following: "Lets see what will break?"
Besides, qualified developer definition is a very poor definition. Who
is qualified and who's not is always open to discussion. Besides, it's
not measurable thus not scientific plus, does not contain any
engineering aspect.
IMO, only solution is unit testing. After a patch is applied all unit
tests are run to see what is broken. I have absolutely no experience
with cocoon unit testing so any ideas are welcome. I'm sure some members
have experience related to this topic. Apache has gump system for
unit-tests of sub-projects AFAIK. Maybe we should try to use it since
forrest is built on top of maven (+1).
As a conclusion, i will support any method that can be measured.
Otherwise it'll be subjective and will change from person/developer to
person/developer and i simply don't want forrest community efforts to
degrade in time.
Tnx.
Evrim.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBnKesR2rUfDW+YFIRAljMAJ4+rIr2x7+B8umuW9hir2FVuLtitgCcDjDc
JmH9TS5Wt4iGJkRXfGLpw8I=
=NwTC
-----END PGP SIGNATURE-----
Re: code vs. talk
Posted by David Crossley <cr...@apache.org>.
Dave Brondsema wrote:
>
> I was in #kde-devel yesterday and saw the title was "development happens
> in CVS, we discuss politics here".
>
> We've been doing a lot of talk lately here (more than I have time to
> read, personally). Our policy is "commit then review" and I think we
> need to do that a lot more. Non-committers can submit patches. And
> that would be great, because that's the biggest step to becoming a
> committer, and we'd like to have more :-) So just go ahead and do
> something; feel free to "stomp on people's toes", if there's problems
> we'll fix the code and evolve the code.
I agree that we need to do more "commit then review".
However, please be sure that the changes do not break
the build system because this prevents other people
working on the codebase. Do 'build test' first.
> Certainly talking here about big changes is good, but if nobody's
> planning on following it up directly with code, what's the point?
Because some issues need discussion before the developer
can prepare the patch and this lets the rest of us
know what the plan is.
There is a trade-off.
This "patch-then-review" process needs to be qualified.
Developers need to be sure to provide a clear log message
to accompany the patch, so that we all know the purpose
and the consequences. Also add documentation where
possible. Then, if it is really necessary, we can
discuss later.
--David
Re: code vs. talk
Posted by Juan Jose Pablos <ch...@che-che.com>.
Dave Brondsema wrote:
>
> Certainly talking here about big changes is good, but if nobody's
> planning on following it up directly with code, what's the point?
>
+1 I think that was the same feeling and my approach was to put on
paper, you are talking about put on code. fine with both
Re: code vs. talk
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Dave Brondsema wrote:
>
> I was in #kde-devel yesterday and saw the title was "development happens
> in CVS, we discuss politics here".
This is the dev list, not the general list. Development happens also here.
For an example, see how the creation of Cocoon 2 was done on the mailing
lists.
...
> Certainly talking here about big changes is good, but if nobody's
> planning on following it up directly with code, what's the point?
I am. I started discussing it because I had already started coding, but
found out that I had to change too many things.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: code vs. talk
Posted by Ross Gardler <rg...@apache.org>.
Dave Brondsema wrote:
>
> I was in #kde-devel yesterday and saw the title was "development happens
> in CVS, we discuss politics here".
>
<snip/>
> Certainly talking here about big changes is good, but if nobody's
> planning on following it up directly with code, what's the point?
I hear you load and clear (not that I take this personally, just that I
*have* been talking alot latley).
Ross