Hi,
80% of problems are internal ...
Le 26 mai 07 à 08:19, Pavel Janík a écrit :
Hi,
I was not able to attend the meeting yesterday thus I want to
express my opinion about providing builds to general public.
I think we should start providing regular development snapshots
from aquavcl01.
No problem. If we follow the OpenOffice.org way, it will take some
times.
When we have steady stream of new builds, users who are interested
can test them regularly.
This is not incompatible.
And we could announce this (because I feel that Eric just wants to
announce something...)!
You are completely wrong with that. And if I remember correctly, it
was *you* who firstly announced you provided public builds ...
I don't care to announce something, and if I try to delegate since
some times (trusting Shaun, e.g.), the reason is extremely simple : I
want to slow down with the project (like I already told you some
months ago).
BTW, this is not the first personal attack against me. Last was when
I asked for money for the WWDC, where you wrote bad things about me.
And if we finaly can attend the WWDC with Sébastien and Philipp, this
is not with your help at all. If you didn't read it, see my answer
to your "statements" : http://council.openoffice.org/servlets/ReadMsg?
list=agenda&msgNo=4166 ).
Again personal attacks -> please stop it.
We should work on integration of aquafilepicker01 to the master and
then resync aquavcl01 into the milestone with it.
What is the difference, for the end user, between two assembled cws,
and the same in a milestone ?
To answer you : sure we will. would be damage to stop there ..
Another question : how long will it take to change "internal"
representation of code ?
After this step, our "regular development snapshot" automatically
contains native filepicker automatically and we can prevent doing
non-repeatable hacks like integrating several CWSes together...
My changes are only about remove the awfull grey/blue.
If we provide old Windows, grey/blue, Mac users will kill us. Can you
understand that ?
I strongly disagree with providing patched builds to general public.
I disagree again : my patches are only what will be soon added, and
they are public : http://eric.bachard.free.fr/mac/aquavcl/patches/
salframe/may07/aquavcl01_ericb.diff
My JCA is accepted, and the code is under LPGL, and I don't see any
problem with that.
Last, aquafilepicker is only what is in the cws. If bugs are here
( of course it can be), then aquafilepicker02 will complete ..etc.
We should provide what we have.
*We have* aquavcl01 + aquafilepicker01 and for the ui, we have that too.
The point is : better provide what we have *now* instead of wait a
long time to finally have the same thing, but later.
And if some (f)printf stay in the code, do you *really* think the end
user will care ?
If the patches are not inside CWS, they are not GOOD enough. We do
not want to provide something which is not GOOD enough to users!
Fix the patches, prepare them for cws! When they are there, they
will be included in the next development snapshot automatically!
Even if we wan't to provide the existing builds, a week is already
mandatory.
What you propose will add at least two weeks. OpenOffice.org is an
adminsitrative monster.
From the meeting log, I see that many people "just want to get
something out".
Yes, and I think they are finally right ( I was not hot at the
begining) : it's time to provide something
This is not how we worked in the past and I do not follow the
reasoning for this.
This is your opinion.
Please do it properly directly from the beginning!
I believe we do, and we have to be proud of what we did.
In the meantime, we should work on some documentation for our
users, like:
- README first
- list of KNOWN BUGS
- how and where to repeat new bugs
+ I'd prefer known issues.
Of course we will. We all agree with that, and that's the main reason
why I asked to prepare things before to anounce anything.
Preparing this properly will be a big benefit for us when we want
to make some development snapshot an "alpha".
The Top 10 of issues is completed, exepted the second importance for
user issue " build vcl with debug enabled leads to crashes "
We just have to go ..
Eric Bachard
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
