patrickjdempsey wrote:Also, just a bit of a casual recommendation (which I need to follow myself): some of us really need to start testing pre-release builds of SM. SeaMonkey has a very small testing base, which directly impacts the discovery of new bugs. When a bug like the print failure is immediately noticeable, that's generally due to a lack of testing. I'm not saying that the people testing SeaMonkey aren't doing a good job, I'm saying that everyone has different habits and different areas they focus on. Especially for Linux and OSX which not only have smaller user bases, but are different enough from Windows that bugs often occur in only one OS. Even if a bug cannot be fixed before a release, at least that bug can be listed on the Known Issues section of the release notes, and here in release announcements.
In addition to testing and filing bugs, SeaMonkey needs help in triaging (sorting) bugs that are already filed. After all, Unconfirmed bugs don't get fixed! This is something that SM devs are well aware of and has been a topic of the StatusMeetings for some time now:
"IanN thinks it would be useful to remind people on the newsgroups / forums that they can contribute by triaging. Tonymec will post a reminder to newsgroups / forums. See bug 1092632 (Sm_tri_HowTo) Document how to triage SeaMonkey bugs."
IMO SeaMonkey devs have made great strides in the last few years and the product is stable and competitive. They've done a pretty remarkable job in not only keeping up with changes that Mozilla is making to the Core, but in improving native features! They just need more help from us in the community to keep things running smooth. And the same thing applies for all of those extensions that busted this go around. A wider testing base might have discovered those bustages earlier and workarounds could have been available by the time of the release.
I used to test Nightlies but ever since the inclusion of EME and lack of enough information for SeaMonkey devs to decide whether not to build EME in official releases, I've felt obligated to self build (well, hey, that does have the benefit of another tester of the build system). Sadly, for personal reasons lately that would be too much effort. Sorry guys
However, I should probably ask: what portions of EME/DRM are in core and what's unique to Firefox? Official SeaMonkey does have some EME code - if you go to about:config and set media.eme.enabled to true, html5test.com will detect EME support. However, I've noticed that official Firefox will create a folder in the profile called "gmp-clearkey" (and try to download something into it in the background?), but I don't think I've seen official SeaMonkey do that...
So my question is: in relatively plain English, what part of EME/DRM code is in the shared backend and thus ends up in official SeaMonkey in its current state, and what part of it is Firefox-specific?
(If the answer is that official SeaMonkey only has EME capabilities, but it does *not* support *DRM* OOB, I'm very willing to consider testing official Nightlies on Linux i686 regularly again.)