Re: Nested db-objects

Dr. Christian Böttger a écrit :
>
> Well, it *has* to be "ready when ready" just like Debian. No body pays 
> us - it's all voluntary work. So how can anyone really impose any 
> deadline? Noone has a handle on the  time people are able to commit to 
> the project.
>
> Having said that: yes, we can agree on a date when we all agree to 
> plan to realese .18. But still, that's just a vague plan and nothing 
> to be enforced.

/me will reapeat endlessly "Release early... Release Often...."

>>
>> Of course there are stupid things (you might even call it crap) - but 
>> we cant really rewrite the whole code all the time.
> But we can and should fix stupid things on the way as we see them.

yes and quality team can help keeping the fire lit up under the cauldron :)

>
>> The code is working - and we need one foot on the ground.
>
> This is a somewhat dangerous proposition, regardless of the truth it 
> holds.

Well as far as i am concerned the code is NOT working... but we 
obviously need to move on... that's why an alpha release and a heavy 
debug phase is welcome.

>
> We cannot afford to refrain from imposing rules e.g. the separation 
> between business logic and storage - otherwise we will have a heap of 
> crap in the near future. We have to be strict in some of these things.

I (very respectfully but very strongly) disagree... i explained already 
twice why

Of course we need to improve quality and work hard to solve design 
weaknesses... but please be careful : sometimes being strict brings more 
harm than good !

quality improvement is a long run deal... phpgw will have the time to 
die before...

The release early/release often need is something we completely forgot 
and we will have to remember it quickly if we want the project to survive

> In my opinion, the main reason (besides the trival one of lack of 
> developers) for .18 taking so long is that we aloowed for much too 
> long that such "crap" and "it's working for me, let's ship it" found 
> it's way into the code and stayed there forever.
>
> Regards
>
> Christian aka bofh42
> Release Coordinator phpGW
The first reason above all is psychological... understandable loss of 
motivation after egw fork. Every community suffers when such splits 
occur... and in our case it was very painful... Many difficulties we had 
in near past are fringe effects of that main reason.

For the reason you give i must express a late disagreement : accepting 
(temporarily) poor designs as proof of concept in trunk or even branches 
then cleaning things for tagged versions is the way nearly every 
opensource project works...

And releasing often even with features declared "immature" is also a 
standard for most opensource projects (included kde and kernel and 
openoffice and subversion and many others)

Working with stable and testing and developpement versions is currently 
difficult because our subversion tree does not allow apps to use their 
own trunk/tags/branches so that quality and release team can choose, for 
each elected app, a specific tag for inclusion in a specific 
phpgroupware version.

Regrads,

Maât