Summon comment box
It's "Braden", not "Branden".
I believe issues like that should be addressed to credits@mozilla.org with the subject "Mozilla Credits"
Passing this to endico, she handles that...
and what's the last name?
fixed
Um, I'm looking at build 2000100509 and the problem is still there.
The real credits list is the one on the web site and the web site is correct. Ben, this is exactly why i'm against having the credits file checked into the source tree. What a mess this is to clean up. There's no way I"m going to check this into 4 places each time I update the credits file. The new credits file needs to be checked into the trunk and each major branch. You really must add something to the build system that pulls the credits page from the web site's cvs (and edits the text if you like). You can make this optional for people like yourself who can't pull from the web site.
Brendan, can I do this stuff without r=/a=? PDT, what about the branch? > You really must add something to the build system File a bug about this problem. (But I don't like the solution you propose.)
Ben, I don't like the solution you've imposed, and neither does endico. Why do you want to spend more of your life hand-copying edits from one file to another? Attach a patch. endico and I can review and approve, pdt will probably approve. /be
> Why do you want to spend more of your life hand-copying edits from one file > to another? I don't want to, and I don't like the current solution. Poosible solution I'd prefer: - Make the copy inthe source tree the main copy, and make the website script fetch it from there (i.e. the other way around) - Even better: As endico (and shaver, I think) said, the webpage is also generated from some internal database. Make that generator generate two versions: one for the website and one for the source code tree.
Created attachment 16393 [details] [diff] [review] Fix for source tree, version 1
a=brendan@mozilla.org. Presumably, r=endico@mozilla.org. Adding rtm keyword and [rtm+] (_in loco_ mitchell@mozilla.org, mozilla.org manager). Let's not repeat this little exercise, eh? /be
> File a bug about this problem Bug 55584.
Hang on while i gather up the latest credits requests and check them in.
endico, can we postpone this until the last moment? I don't want to do this 2 more times.
I personally don't mind postponing, but the closer to rtm, the harder it should be to get approval so make sure that brendan doesn't mind this getting pushed off. Try and figure out what the latest date for the checkin should be.
PDT, what is the last possible day for checkins to credits.html on the N6 branch?
This looks like it's approved for the trunk. Are you actually trying to get this on the RTM branch?
selmer, I think so. Please also answer my last question - there were more requests and still more to come.
Ben, why are you asking foolish questions like "what's the last day for checkins on the N6 branch?" Couldn't this firedrill have been avoided by hyperlinking to the credits page on mozilla.org? /be
> Ben, why are you asking foolish questions like "what's the last day for > checkins on the N6 branch?" What's foolish about this question? OK, I don't need the *really* last day. I just need a "cut" time. > Couldn't this firedrill have been avoided by hyperlinking to the credits page > on mozilla.org? Yes, but not without creating larger problems. <quote src="http://bugzilla.mozilla.org/show_bug.cgi?id=55584"> - some users have no or intermittend access to the internet (but use Mozilla locally, e.g. Mailnews). - there is a semantical difference between the contributors to a particular version and the current Mozilla contributors - <http://www.mozilla.org/credits/> is not garantted to persist, as <about:authors> in 4.x demonstrates </quote>
The PDT may not bother giving you a cut time. If I were them, I might say "last week". Who cares if credits are invisible when off the web? I don't. People who care about credits in all cases and embeddings need to find more important things to care about, in my opinion. There's no problem with hosting a version-specific credits file on mozilla.org, for as long as there are hits from that version. /be
Created attachment 16962 [details] source for http://mozilla.org/credits/index.html as of Oct 12, 2000
Created attachment 16965 [details] [diff] [review] Fix, version 2. Also contains names added recently. Corresponds to the html files endico just attached.
r=endico@mozilla.org This patch fixes spelling mistakes for two names and adds a couple dozen new people.
sr=scc
rtm-. Leave it as is on the N6 branch and fix it right (hosted on mozilla.org) on the trunk. We're looking for fixes for crash/data loss/must fix bugs on the branch, and this is so not even close.
Reconsider. This *is* a data loss bug, as far as I'm concerned. And it's no risk. Phil: Either spell my name correctly or take it out of your product.
Sorry, rtm-minus (please do not land on N 6 branch). This should have been in long ago (before the branch!). I don't know who is responsible for maintaining this, but sitting on these changes is bad, and now we're creating Netscape candidate builds, and don't want folks hacking the repository unless it is critical. We're now at the point where we're trying to consider bugs that would force us to pull the build from the wire. We've had to say "rtm-minus" to a pile of more critical items. :-( :-( In days of old, the folks with the cvs checkin permission would land their own names as needed. I don't know why this got funneled through a meta-bug. (Side comment: This *really* saddens me. The only good news is that the link atop the page points back to mozilla, where the improved content can reside... if this would just get checked into the trunk RSN!).
> I don't know who is responsible for maintaining > this, but sitting on these changes is bad It *has* been updated shortly before the branch, this are only the changes since then. > In days of old, the folks with the cvs checkin permission would land their own > names as needed. Yes, this is the scheme I'd like to see as well, see bug 55584.
Jim: Your comments fly in the face of reason. The patch is ZERO RISK. If my name *does* appear misspelled in your product, I will take whatever petty retaliatory action I (legally) have at my disposal. That probably won't be much; but who knows, word just might get around about how Mozilla developers can expect to be treated by Netscape.
Braden, this is not a big deal at all. The majority of Netscape users won't even know that credits.html exists in their hard drive unless they have the hidden "show about as modal dialog" pref on, because the normal Help | About just opens about:, which in turn links to mozilla.org/credits.
> about:, which in turn links to mozilla.org/credits. Wrong. We use the local version.
Umm, bug 54751 STILL has a "blank check" rtm++. I can't see how that general non-crashing bug still has a rtm++ while important personal bugs such as this get a rtm-.(Yes, I know, it's a MARKETING thing. The managers will keep it rtm++ until the day NS6 ships...well, this should then be considered a LEGAL thing.) It's not NICE to misspell and not fix the name of someone who spent his or her OWN personal time to try to make Netscape 6 a success. It's the LEAST that you can do. And this bug has been filed since *9/20*. It's NOT like he did it at the last moment. To be blunt, Netscape management, and the ultra conservative tactics of the PDT have turned off many outside contributors. Many outside contributors (myself included) are waiting for Netscape 6 to ship before continuing to aid with Mozilla development, so we can deal with more reasonable Mozilla management when getting our patches approved. I know that reasonable statements can be made the other way about the PDT, about how draconian change control was needed to get the product out the door, etc. However, there is NO excuse in not fixing this. Given that "recognition" is the currency that contributors are paid with in Open Source projects, refusing to fix a misspelled name is a SEVERE slap in the face to any contributor. If this was a trademark issue, you'd be all over it.
> this bug has been filed since *9/20*. It's NOT like he did it at the > last moment. For the record: The local credits file (the one that will ship with Netscape 6.0, if this bug doesn't get RTM++) was last updated 9/15. This spelling error is in the credits (both web and local) since day one (1999-08-26). Also note that the "no risk" in the status whiteboard was inserted by scc. I also consider the risk as neglectible.
Oh god jce, now you've taken to yelling rants for other people? 54751 was reopened which is why it still has a "blank check" ++, and you can probably expect it to be minused on Monday. It was ++'d 10/3, when most things with patches were being ++'d. Selmer's 10/13 comment clearly shows PDT isn't willing to leave it ++'d "until the day NS6 ships", as you exaggerate. In any case, I fail to understand how fixing the default skin for the product is comparable to someone's name being misspelled in a local copy of the credits. You can rant and yell at Netscape management all you want (do you have a fetish with capitalized words or something?) but this isn't their fault, as much as you're eager for it to be. If a Mozilla contributor (names withheld here) hadn't decided to check a copy of the credits into the build, this never would have happened. In any case, this is a Mozilla.org-hosted page. This is a list of Mozilla contributors. In other words, this has nothing to do with Netscape management. Get over it. If you think PDT's "tactics" (e.g. wanting to ship a product..gasp!) are "ultra conservative", you've obviously never needed to ship a product. Your argument about waiting for NS6 to ship before getting patches approved is nonsensical, because PDT doesn't need to approve mozilla trunk patches. Oh, and um yeah, if it was a trademark of course they'd be all over it. Since they could, you know, get sued? Haven't you ever worked for a corporation before, or is this a new idea? Yes, this fix could go in without any risk, and yes, it'd be great if it did. But the arguments you present for doing so aren't valid.
My logic is such: 1) PDT seems willing to rtm++ bug 54751, a purely cosmetic bug, which does introduce some risk into the product (Those "black bars" in Mail/news are still not fixed). So why aren't they willing to fix another cosmetic but important bug dealing with a person's name being misspelled? 2) A local version of credits does need to get checked into the tree, because the list of contributors who contributed to Netscape 6.0 and Netscape 6.2 will probably be different. This difference can be best captured by adding it to each release. The way that we're currently doing it is inefficent, which is why a bug has been filed on that process. 3) The PDT doesn't seem to understand how important contributor lists really are to open source projects. Recognition is the currency of payment to contributors. If they understood this, then they wouldn't hesitate in checking this in. I am giving them a warning that this is one of the quickest ways to anger the outside contributors to Mozilla. 4) I won't go into detail about all of the questionable decisions made by the PDT in the past week (or month) that have had to be violently appealed. Note that I did give them the concession that this might be what they have to do to get it shipped. 5) Although in theory, people don't have to do much with the PDT in order to get things landed in the trunk, in practice, people are being pretty much as conservative as they can with checking things into the trunk because the PDT is using it as a test bed for landing patches that are longer then one to two lines of code. No major steps forward are going to be made on the trunk (Like checking in all those patches that the PDT deemed to be "too risky" for NS6) until after NS6 ships. Yes, I have worked for (several) corporations. No, I have never dealt with a change control team that was this conservative, yet somehow, we managed to ship on time most of the time. The PDT is taking an arbritrary approach here, and they know it. If they had a consistant logical basis to make their decisions, then they wouldn't say "We've denied checkins for more important items", they'd say exactly why they think that checking this into the branch would hurt the product. You don't ship with Trademark violations because you'll get sued because you've pissed off a corporation. You shouldn't ship with misspelled contributor names because that pisses off individuals who have helped with the product, and leads to very bad rapport. I'd be much more understanding of the PDT's decision if we had gone gold with NS6, as in the master cd had already been burnt. However, there would be absolutely no harm done to the product if this was checked in today, and not checking this in will lead to a great amount of anger and suspicion from the outside contributors.
FIXED on trunk.
Thanks, Ben. Blake: The problem here is that not only quality but *basic decency* has taken a back seat to *process*. Maybe that doesn't bother you. It bothers me.
Braden, yes, I don't disagree with you -- the issue sucks. But I find it ironic that you're thanking the very person who caused you this trouble to begin with. /me leaves this issue...
What? Can we please stop the finger-pointing? FYI: I did not add the local credits file. It is used by the about /dialog/ for a long time already. And that is for a reason: One of them is that the webpage has a banner all kind of other stuff, which does't really work in the about dialog. More details see bug 40024. And we want to use the about dialog eventually, not? All I practically did was *changing the link* in the about page to point to the local version. This was to make the about dialog eventually work (because the about dialog displays the about page, see above) and for reasons discussed in bug 55584. Again: The local version has been updated (by me) shortly before the branching. If somebody missed this, it is unfortunate, but certainly not my fault.
> If somebody missed this, it is unfortunate Don't midunderstand me: IMHO, it should be checked into the branch.
If module owners are holding the trunk hostage to the central-planning commisars of the branch (note that I'm not saying the branch *shouldn't* be under central planning right now), jce2 and others need to make a stink in a more public place, and with specific evidence, than in this bug. I and other staff will do whatever it takes to get good, well-reviewed and tested patches into the trunk, whether or not they're relevant to the branch. Yes, the PDT is arbitrary. What do you expect from a group of more than two or three people with different judgments working on a set of bugs for which no one can write unambiguous approval criteria? But suppose the PDT does simplify its rules brutally: only crash fixes and data loss repairs ("small, safe, and tested patches") will be accepted. To some arbitrary extent, the PDT is doing this. What I object to is not so much "arbitrary" decision making in a product's end-game. It's the artlessness. Netscape 6 will ship with crash and data loss bugs in spite of the restriction to take (and presumably "focus" people on developing) fixes only for such severe bugs. But it will also have other, sometimes cosmetic, often embarrassingly bad bugs, whose easy fixes were left out *with no significant reduction of risk, and with no improvement to the crash and data-loss find/fix rate.* (And of course, there will be more than a few cosmetic fixes that are sanctioned, arbitrarily.) The inconsistent attempt to restrict bugfixes to only the most severe bugs is just artless process, in my view. It does not make the product better. It does not make the necessarily arbitrary decision-making more winning, but less. The problem is not the arbitrariness; it's the quality of the non-crash/data-loss decisions being made. Great end-game product management requires some artful combination of more rigid, group-thinking process and more flexible, individual good judgment. The PDT should say why this bug is not important enough to let someone with CVS access update the branch (at no cost to netscape.com staff), instead of falsely claiming that only "pull-it-from-the-wire" bugs are being fixed. Everyone can see that other severity-level bugs are still being fixed, although soon (after the 16th?) it may be that only truly-pull-it-from-the-wire bugs will be fixed. /be
For the case we do get rtm++: Could anybody (preferably not @netscape.com) with a N6 branch or however this is done then move my checkin to the branch, please? I didn't do this before, and I don't want to screw things up due to my unexperienceness with CVS / Bonsai.
I can check it in if this gets ++.
Checkins like these are low risk, and high reward. The reward here for developers to be listed in the credits is priceless. Netscape couldn't give away large enough big screen tv's to match the amount of good will and payment represented by a checkin such as this. And with a zero risk factor it amazes me that something like this could ever be rejected.
Still waiting for the PDT to either let this in TODAY (RTM++), or explain EXACTLY how checking in this virtually NO risk patch (NO code) would hurt the branch in any way, and justify alienating virtually all current (and future) outside contributors to Netscape in the process (since it shows us exactly how much you think of us). If you wait until tomorrow and then say "Well, now we aren't going to allow ANY bug fixes in except for pull-off-the-wire because we're baking.", then we AREN'T going to be amused.
http://www.amazon.com/exec/obidos/ASIN/0140157352/o/qid=971748658/sr=8-1/ref=aps_sr_b_1_3/102-4530759-4718528
Created attachment 17315 [details] [diff] [review] proposed fix
r=brendan@mozilla.org. Endico and I will work on the CGI idea (to serve the right CVS version from gila.mozilla.org). BenB, if you want to get this file when disconnected, please work on offline support, cache file pinning, etc. /be
waterson, brendan, scc, this is what bug 55584 is about, not this one.
BenB: you solution has proven to be unmaintainable. Changed nsAboutCredits.cpp to refer to www.mozilla.org
> you solution has proven to be unmaintainable. No way. Some people who go creasy are not the base for measurement. > Changed nsAboutCredits.cpp to refer to www.mozilla.org Please back the change out for Mozilla. Thanks.
> Some people who go creasy are not the base for measurement. > Please back the change out for Mozilla. Thanks. Please disregard this. I still don't see this bug as being *any* prove for unmainability. For further discussion, let's go to the other bug or a newsgroup.
As far as I can tell, this change was only landed on the branch. The trunk still has the (fixed) static list of credits. Given how the PDT has decided to maintain the netscape branch, keeping a static list of contributors is unmaintainable in Netscape's case, <dry sarcasm> Otherwise, the list of contributors would be at least 3 months out of date </dry sarcasm>. So let's just leave this fix on the branch.
Ok, I spoke too soon. This change also landed on the trunk. And I will take my discussion about that to the newsgroups as well.
The branch pointing to the webpage is fine with me, largely because I don't mind not having my name on N6.0. I do disagree with the change on the trunk. I posted <news://news.mozilla.org/39EBEA46.F5BC3975@bucksch.org> to .license.
mid-air collision ? / bugzilla cleanup Reopening (current State: resolved and no resolution
resolved fixed
or
