There was a problem recently, where IPC was turned on by default in the build, but, non of the port maintainers, that I know of, where contacted or even briefed about the changes, until we found out by having our builds broken. The following is from a post I made to the netscape.public.mozilla.general newsgroup: <quote> The following comment was made on Bug#204177: > BeOS, VMS, and OS2 are not officially supported by mozilla.org (they > are ports). we try not to bust the ports, but we try even harder not to bust > the primary platforms. it simply can't be the job of every developer to > maintain the ports. we can all try, but it can't be our first priority. > blocker status seems misused if only the ports are busted. moreover, your > development is not hindered... you can add --disable-profilesharing to your > mozconfig. so, why don't you help out with the patch (since you are capable of > testing on BeOS) instead of fussing over the status of this bug? I understand that BeOS is not officially supported, but, a little concideration would be nice. The IPC bug is not the first time, that certain parts of mozilla that are new features, have just been "turned on", which breaks the ports. I am the primary developer of the BeOS port, and, was never informed about the fact that this change was going to be implemented. This is a volunteer project, we do not have paid developers to work on the port. But, people do somewhat depend on myself and a couple others, to make sure that the beos port is maintained, and, improved. I don't mind having to do the work to fix the BeOS port, even though timeless beat me to it for this one. But I had started working on it, without knowing of timeless's work. The thing is, that I had to drop the other work I was doing, to fix this. If I would have known ahead of time, I could have set time aside, and started looking into the issue, before it became a problem. Now, there may be a mailing list or forum that might have announced it, but, with the amount of junk mail I get everyday, I don't need more email. Most of the mailing lists/newsgroups where I would expect this information to be posted, if it was, though I can't find it, are used to the point, that I just don't have the time to monitor them. Might I suggest a low-volume developer-announce mailing list, that is read-only, to keep the volume low. This way, when major changes are going to be made, the people that care to be informed, can be? At least something, because the current management of the tree, as far as working with outside developers, is really rather poor, to the point where I could see it discouraging further ports, if it hasn't already. </quote> And was replied to with the following: <quote> I know how you feel, Paul. I am the primary OpenVMS developer and I didn't find out about this until I discovered last week that I needed --disable-profilesharing to build (http://bugzilla.mozilla.org/show_bug.cgi?id=178806#c18). Now I have to come up with an IPC solution for OpenVMS pdq. Agreed. We need some mechanism by which us "second tier" developers can be kept informed of what's happening. Finding out some new feature has been added (which will require some porting effort) only when your build breaks is not real developer-friendly. </quote> Then I responded a final time with: <quote> Yes, but how do we get it implemented. I mean, if Netscape/mozilla.org doesn't care about the developers who work on the ports, then it will never happen. I'm not asking for any major or drastic changes, just a little courtesy. And, being added to a bugzilla CC list, and saying, please look into this, won't cut it, as, I get a LOT of those types of emails already, mostly specific to BeOS, and, I may miss the email. Which, is why after thinking about it, a read only mailing list, is probably not the best solution either. Email is just not reliable any more. Problem is, I don't know what else could be done. I don't want to see this issue die again, as this is not the first time I have brought this up either. I had been told in the past that Netscape/mozilla.org was looking into the issue, but never heard anything after that. And, I know you and I are not the only ones who feel this way. </quote> I am not sure if this is the proper place to deal with this issue, but, as I do not know of any other place, and, it seems the only person who responded to my newgroup post was another port lead, I fealt this was my only option.

OK, I think my comment has been taken a bit out of context here. My comment was directed specifically at timeless in response to his specific change to raise the "ports are broken" bug to blocker status as well as his comment that this bug was blocking _his_ development work. That can't be true given that he knows how to add the configure option to workaround the problem. As I said to timeless over IRC, I am profoundly sorry for the bustage caused by this. I take responsibility for this because I reviewed the patch, and I also told timeless long ago that this IPC stuff would not kill the ports because we intended for it to be disabled on all platforms except the platforms for which an implementation exists. My humblest appologies to everyone of the ports maintainers for not ensuring that those intentions were carried through. And, I am sorry for the apparent lack of communication in all of this. My plan was to inform the ports maintainers of the IPC module and ask each of you to help me plan out the porting of this code to each respective platform. I am definitely willing to help out with the code given that someone can test patches and provide feedback. I never meant for this to be dumped on anyone. My assumption was that profile sharing would simply not be a feature available on the ports until sometime later. Anyways, it will not be used by Mozilla until some distant milestone. As is, it is just a feature of the GRE that may find a home in some embedding applications in the future. Please understand that I will do my best to avoid problems like this in the future. I know that doesn't necessarily mean much given that I already made that exact promise to timeless and didn't carry through on it :-(

Darin, I am not trying to point fingers here. The reason I openned this Bug report is that this is not the first time this has happenned, but, I would like to see some steps taken, to help ensure it is one of the last. Information for this project is spread out all over the place. Between newsgroups, mailing lists, forums, web content, bugzilla, tinderbox, etc, etc. From my point of view, there are some serious management issues here. I'm sorry that the IPC problem is the one that caused me to finally speak up about these issues, but please, don't take personal offense at my writings here. That is why I never included you name in any of my original posts.

I think it would be helpful to add a link to SeaMonkey-Ports which points to a list of owners and peers for each of the ports. It could have a format similar to http://www.mozilla.org/owners.html. Between an owner and several peers, somebody should be reachable by email.

There currently is not a "BeOS" owner listed on that page. Though, other ports have there owners listed there. I had asked to have myself listed for BeOS, but, nothing ever came of it. So, if we are to use either that page, or something similar, who would maintain it, and could we be sure that it would be updated regularly?

We already have an n.p.m.ports newsgroup, don't we? Perhaps the sane thing would be to add a link to its mail alias to the Ports page and main Tinderbox page, marked "mail these people if your change might break ports." Gerv

> We already have an n.p.m.ports newsgroup, don't we? No, we do not. Btw, this lack of communication problem isn't specific to port maintainers. They are just the ones who are hit hardest when the problems occur. In the past, we seem to have relied upon the branch landings page and word of mouth to give notice about major changes. Neither of these approaches seems to work well enough to avoid the problems that occurred with the IPC landing. I've mentioned to both a driver and a staff member about the need to have a (semi-)closed mailing list to discuss (or at least announce) major upcoming changes. This setup would be similar to the "core" team list that other open source projects have (xfree86 core, gcc devel list, mingw devel list, etc). It would allow topics to be discussed among developers without senseless interjection from people who aren't interested in coding. IMO, this list would contain just the module owners and peers but it has been mentioned that it should be extended to include anyone with cvs checkin access. The list archives would still be publically available (via news.m.o if desired) but only list members would be able to post to the list. Btw, I opened bug 189994 about creating a despot partition so that the beos owner would show up on the owner's page. Anyone interested in taking that from endico?

> No, we do not. You are right - apologies. So is this bug now more concretely about having an all-cvs mailing list? The topic still talks, in a handwavy fashion, about "better cooperation." Obviously, mozilla.org infrastructure is in a state of flux right now, but hopefully when the migration is complete, we'll have much better control over all our services, and can make stuff like this Just Happen. Gerv

A month later, and its still no better from here. Maybe I'm not looking in the right places, but its real difficult to get ANY kind of status update about 1.5b. The only place I've seen anything is someone's personal blog. Am I really supposed to scour the 'net to find this information?

Colin: I know that they try to get a 1.5b build today or tomorrow. I know that because I'm in the cc list of many open bugs ...

Thanks for the info, but... Why can't they post this info into n.p.m.general or whichever newsgroup is most appropriate. It would take someone less than 60 seconds a day to give us a daily update, and they can't even do that. That's what hacks me off....

--> Governance

zak: Please only change the assignee and not the QAContact when you are taking a bug. Many of us watch the QAContact for changes with Governance bugs, and by changing it, it causes bugmail to be lost and never seen. Thanks!

Can anyone involved in this bug give a quick update. A lot (or nothing) can change in ~ three years.

Can anyone involved in this bug give a quick update? A lot (or nothing) can change in ~ three years.

Second ping - anyone want to give a quick update on Mozilla/port maintainer relations?

Didn't know about this bug before but as nobody else commented you get a few sentences from me (I do much of the work on the OS/2 port): - AFAIK there are no official rules or any real Mozilla/port maintainer relations. - People who want to know stuff about OS/2 have learned to CC me and/or Mike Kaply on bugs. - Sometimes, but unfortunately not always, developers who want to land larger scale patches that are likely to break ports, post a warning in the mozilla.dev.ports.os2 newsgroup and/or mozilla.dev.builds. Overall I am quite happy with the relations, even though we couldn't keep up with the Thebes change and are still trying to recover from that on OS/2.

Hi Peter, Thanks for the note! I'll do some thinking and some research, and then post suggestions. --zak

I think the best we can hope for is a "rule" (suggestion at the top of tinderbox) that a particular email address or mailing list get notified if there's a nasty change on the way. The question is, do we need a new NG/list for this, or is mozilla.dev.build appropriate? I suggest bsmedberg be consulted to find the answer to that. Once we know, we can create the group if necessary, update the tinderbox and hacking guide (and maybe post somewhere visible to tell people) and close the bug. Gerv

When I made breaking changes to xptcall, I sent announcement mail to mozilla.dev.platform: http://groups.google.com/group/mozilla.dev.platform/browse_frm/thread/7d9f68aa05f44807/58d38faec37f1ddf?lnk=gst&q=xptcall&rnum=1#58d38faec37f1ddf

I think I can give a sum up in a bit 'bitter' remark: Bugs is the only communication we have. As to finding out changes beforehand, it never happens. I wasn't aware of the google-group, or is it just the-usenet group that finally has had some spam-protection. The usenet-group got abandonded due to the only info there was how to get cheap Viagra. Communication goes both ways though and we have no better communication that way. We do have a blog http://community.livejournal.com/bezilla/ which we use, but I don't think anyone except biesi ever sees it on the other end. Mozilla IRC is impossible to talk on, as soon as you mention BeOS you get either two responses 'Not officially suppported' or 'Wow, is BeOS is still used!' often with profanities thrown in. Using the Mozilla wiki tends to get your pages deleted or watered down to become unusable for us porters so instead I prefer to have them elsewhere. Here is one for getting Cairo to build: http://wiki.bebits.com/page/BuildingCairo There is no port maintainer for BeOS, it still says Paul but he quit probably around when this bug was created. That along with forcing a lot of dependencies makes it almost impossible to port, I know I've given up, but I have a question are there any other ports that has had success or even managed to get off the ground? Sorry for the tone of this, but that's the only feedback I have.

A few people indeed take care to announce changes that affect non-tier-1 platforms. But since I posted the rather positive note (comment 16) in May, the OS/2 build was broken about 12 times. A few times it was some contrived problem that could not have been apparent before some change, a few times the work was announced and we could quickly remedy the situation. But at least half the time we were broken due to some pretty bad changes or because OS/2 was just completely forgotten. That should have been apparent to the person who created the patch and reviewers didn't catch it, either. And nobody thought about CCing somebody from the OS/2 team. Worst examples: - bug 386978: forgot to remove some methods in files for "other" platforms (and not only broke OS/2 but also some Mac build environments). - bug 388701: completely forgot the changes to the os2 subdir. - bug 385065: just moved some code from one file to another without noticing that this code used private methods from the other class. Because of such things it becomes a full time job to just fix build breaks and I am somewhat pessimistic that we can even get a properly working Firefox 3 on OS/2.

All of those are probably broken on BeOS still as well as SQLLite and no working Cairo, and guessing a few gcc2.95.3 related bugs. The switch to Cairo also means that we will have to work with not only Mozilla organisation but also two or three more organisations (Cairo and dependencies) which have the same cooperation and support problems. I don't think anyone believes that Firefox 3 ever will see the light on BeOS. It's simply not worth putting in the effort. Cairo is just the deathblow to a strained relationship.

Joyfully, Firefox 3 has made it to OS/2 <http://www.os2bbs.com/OS2News/Warpzilla.html> but BeOS is indeed still on Firefox 2 :-(. But I'm afraid we're not going to drop Cairo to support BeOS. I'm sorry that comment #18 never happened. Does this bug have any further value? Gerv

Yes, FF3 is there on OS/2 and even 3.5 might happen. 3.6 or whatever comes next is another chapter, but that is limited by manpower for the OS/2 port not by cooperation of other developers. We still get quite a few build breaks which keep us busy more than necessary. I am not sure what can be done about that. Apparently Solaris has a similar problem. In my mind this bug can be closed.