Hi Eric, *, Disclaimer: This is a post about the facts/about the situation, not about persons. It doesn't matter whether Maho does the builds or some other person. It doesn't matter who demands that no/not all milestone builds are provided. So always take this into account. Don't take this personally.
On Mon, Jun 30, 2008 at 8:43 AM, eric b <[EMAIL PROTECTED]> wrote: > 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 :-/ OK, so we all agree on this /fact/. >> That is what the QA testing team is here for. > > Then something must be improved, because there is obviously a problem. So no disagreement here either: QA for Mac could be improved. Wrong conclusion: Maho must do QA. >> 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. You blame Maho for not following the list, but why don't you follow the list (more on that at the end of the post)? > So ? Right: That doesn't really matter. > [...] > Yet another reason to select good milestones, and not provide all. Again you're basing all your argumentation on a wrong starting point. Your idea is that Maho's build are "releases" for the public. This is just not the case. Maho's builds are milestone builds for interested users/developers/QA-folks. He did never announce them to "users", he announces availability of the builds on developer lists. So everyone who downloads the builds should know that those are only snapshots, not "releases". > [...] > Here is development mailing list. So agreement that this is is a development list. And I'm pretty sure there's no doubt that [EMAIL PROTECTED] is a development list as well. > 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. Correct fact. > Result: unusable milestone have repeatably being provided. Correct fact (albeit "unusable" differs in perception, unusable regarding a specific functionality, well, doesn't matter - there definietely were "not-perfect" builds) Wrong conclusion: It is Maho's fault and Maho should not provide milestone builds. > So, I ask to find a solution, to prevent such issues in the future. What issue? That stupid users download non-released software? Then yes: Do something about it. Wrong conclusion: "forbid" Maho to publish milestone builds. (correct: Educate the users about the fact, write big letters that those are un-QA'd builds or something) > 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. But how does that conflict with providing milestone builds? Those offer build including new code for some testers, to have faster feedback. With the additional point that those code is already integrated. Bugs found there are already in the code and needs to be fixed. In "hacky" builds noone can be sure what really ends up in the product, so the results may or may not be useful in the end. Wrong conclusion of the above statement: You are not allowed to provide cws builds. >> Otherwise, Maho is doing what he said he would do and I, for one, would >> not want him to stop. Me neither. So to sum up: Maho just builds every milestone and uploads every milestone (if time permits). (Sun would do the same if they could do it by a snap of their fingers/if they had the ressources, so any argument telling "Sun skips build as well" is plain wrong. Since if the reason for skipping would be "the master has problems", then the integration process of the cws would have been seriously flawed. The rule for a milestone is: No known additional issues. There might be *rare* exceptions to this rule though) It is true that some builds have problems. These faults are a problem with QA. (of the cws that are about to be integrated, or just because the milestones/the combination of the cws is not tested as well as it should). This is not Maho's fault as QA is not his job. He is a provider of builds. He spends his time and ressources on doing builds, not development, not QA. It is true that users use development builds (the milestones or beta) and find bugs. See above: This is a problem with QA. Those problems should not have been introduced in the milestone in the first place. (but this is only theory, you cannot test each and every feature in all environments to catch all bugs). That's why it is even more important that people do find those bugs. It shows that they care, it shows that there is a problem with the code. If the problem is already known: The better, shows that the developers did work quickly for a fix. If the problem is known for a long time, for a couple of milestones, then the situation is another one. It shows that developers did judge the issues wrong, thought that integration can wait longer instead on working on getting the fix into the main code as fast as possible. It also shows that communication of the Mac port could be better: Why didn't the users downloading those build knew about those issues already? This is not Maho's fault as he doesn't do any of it. He doesn't act as a developer working on the code, he is not involved in cws process, does not do QA, doesn't do marketing/advertise his builds to endusers. It is true, that Maho doesn't do plain vanilla builds, but applies workarounds to his builds for known problems (i.e. rebuilding i18npool because it breaks randomly and stuff). But it is also true that for those problems issues are filed that nobody could solve yet. It is also true that Maho mentions those issues/problems in all of his announces. Of course those modifications are naturally for build-issues, since those are the ones he encounters himself. It is also true that he did a respin of 2.4.1. This was a request, and for a end-user build. This shows that Maho /does/ care. He wants to provide builds that work for the end-user. But he also wrote before: He doesn't follow development and doesn't want to go through the mail-archives himself. So when you got a patch for a known problem that is severe enough so that you consider a build without it useless: File an issue, add Maho to cc, add the patch and ask for inclusion of the patch in Maho's builds. I'm pretty sure he will add the patch to his builds if the problem is severe enough. (and regarding the severance thing: The issue probably is not severe enough if there is no cws already that fixes the bug... You cannot tell a builder that a fix is a must-have, if the developers didn't think it was worth fixing it in a cws as fast as possible) ciao Christian --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
