Hi James,
Le 30 juin 08 à 03:13, James McKenzie a écrit :
eric.bachard wrote:
Eric, Maho has NEVER tested his builds to my knowledge.
I know :-/
That is what the QA testing team is here for.
Then something must be improved, because there is obviously a problem.
Maho fixes problems he encounters with the build process.
That's not true: there are PowerPC builds provided by Maho, and
including jvmfwk fix. afaik, this fix is in aquavcl08, not yet
integrated.
So ?
That's even the reason why I decided to provide my own unofficial
and hacky builds including fixes on http://oooaqua.laurentbuisson.fr
Wonderful that you do this. Once your builds work, then it is time
to build a CWS and get your fixes into the Master build process.
Once everything will be integrated, I will continue to provide, to a
limited number of testers, builds with new code not yet integrated, yes.
IMHO, you should limit the number of builds you provide, to the
builds for to-be-QA'ed-releases or, from time to time technical
preview, on mac developers requests, because they really know the
existing problems, and can say if an official milestone has to be
public or not.
Maho should only limit builds if good-day.net is running out of
space or builds are released very close to each other, which
indicates there was a problem with a release. This has happened
several times.
Yet another reason to select good milestones, and not provide all.
or, you can post a message as well.
To be constructive, my proposal is :
- you provide firstly the to-be-QA-ed-builds: even if they are
buggy, any important bug/issue is P1 or P2
- you provide some developer snapshots, *on Mac porters requests*,
for the visibility of the progress
Why should we wait on 'Mac porters request'?
Here is development mailing list. When the milestones are unusable,
no need to provide them, and better wait for the integration of the fix.
That's all.
What happens here: developers said "hey, there is a
problem ..." .. and nobody did care. Result: unusable milestone
have repeatably being provided.
So, I ask to find a solution, to prevent such issues in the future.
It takes at least a day for all of the builds to finish. Also, SUN
is providing builds of the DEV300 milestones for each release.
Ah, yes. Another issue: the issues concerned Tiger, while the builds
were mainly tested under Leopard.
Apple does not help here ..
- the devs do provide developers builds, unofficial and hacky, for
their testers because they know what they do
No. Developers build to fix bugs.
And add new features (from time to time ..) ? :-)
Once the bug is fixed, they create a CWS to put the fix into for
QA. QA acknowledges the release and retrieves the build and tests
it for both the fix and any regressions. If the CWS meets BOTH
requirements, the CWS is released to be placed into the Master
build line. No 'hacky builds' that have MY code. Unless you want
to support your own builds or if you are requested to do a build,
as I have on several occassions asked you to do so.
I don't want to support my own builds. I'm only interested with code
understanding, and provide builds including new code for some
testers, to have the faster feedback.
http://ooopackages.good-day.net/pub/OpenOffice.org/MacOSX/
Dev_DEV300_m21/
I'd suggest you to remove them. Please ask and wait for the "ok"
from mac porters before to provide a new one (probably DEV300_m24)
Why?
We do have weekly meetings: the logs are available, and it could be
easy to confirm here : ok or wait until this milestone to be
integrated ... and so on ?
Ok, people must read the IRC meetings logs ... :-)
Is there a P1 issue that exists solely for the Mac OS X port?
The crashes have not been declared as P1, perhaps P2, but I'm not sure.
Then identify it, fix it and get a CWS together so that the fix may
be incorporated before 3.0 is released.
Again: this is done already, excepted the integration, to come soon.
Otherwise, Maho is doing what he said he would do and I, for one,
would not want him to stop.
BTW, have we NOT been down this road before?
I don't think so: this is the first native release ;-)
Regards,
Eric Bachard
--
qɔᴉɹə
