Shouldn't be too bad - we already build the zip and would just need to upload it, too!
https://github.com/servo/servo/issues/16437
3,475 karma · joined May 27, 2009
TBH, it's been hard to prioritize work to fix OpenSSL issues when we all knew it was going away from the dependency list. However, I don't think anybody anticipated the scope of work required to get there :-)
Sorry for the inconvenience!
It has been pointed out more than once to me that I could instead of purchased many other .com names that were available at that time and be semi-retired :-)
I can't wait to dig in and finally learn more than I could at after-conference drinks :-)
Members of that community could probably comment better than I, but it doesn't hurt that Microsoft Research supported two core Haskell team members and Inria has supported core OCaml work for most of the lifetimes of the projects. Their better corporate focus has also meant that as some fabulously enlightented BigCos took dependencies on them (most notably Standard Chartered for Haskell & Jane Street for OCaml), they've both hired core developers and supported the communities. I should add that these have been fantastic for the PL community in general and specifically ICFP funding & attendance!
For as much as the members of any one community might have differences of opinion with the choices of the others, success of any benefit us all. Even if we do grumble occasionally with the "can't get into ICFP this year unless you're in language {X}!" comments, where X was Scheme, then ML, then Haskell... :-)
> people are not really prototyping the new ideas
Yeah, John's group plus Matthew Fluet and a little bit of myself are trying to clean up Manticore enough to do a "final" release and journal paper, and that is kinda taking up a lot of our extra cycles. Several other folks have either retired or moved on to new areas (security, compiler verification, etc.).
I think that if we could find some places where the new ideas intersected with interesting novel (read: fundable) research topics, there'd be some additional energy into implementation work around them. Right now, certainly, stuff exists, at best, in private forks of (typically) MLton.
I would definitely agree with the opinion above that the SML language designers fall in the camp of deliberating extensively and fully formalizing all new language features before considering them for inclusion.
Today, there are two challenges right now in the Successor ML space:
- There's some broad agreement on a few things that should obviously be improved, but today many of the implementation owners don't have a huge amount of time, so getting them to also agree to the new features is complicated. Life is way easier when you only have one implementation.
- There's a bunch of fantastic ideas (largely driven by Bob Harper) to integrate stuff like parallelism, cost model, etc. that will be fantastic for a next version of the language and specification. It's just a lot of work, and not really publishable, so it's mainly tenured faculty and "alumni" (like myself and probably the people you work with) driving it forward in our free time.
That said, I still love working on SML and its implementations (I mainly contribute to SML/NJ and Manticore) and it's a wonderful escape from the grim reality of quarterly goals and "get it out the door" release deadlines :-)
1) Making the "cargo vendor" story work better. rust-url has a bunch of dependencies, and you have to get them all in-tree.
2) More security review & planning. URL parsing is scary! And we'd want to ship & run it alongside the C++ one to check for places where rust-url is not fully web compatible, but there are major privacy issues in reporting back anything more than "1 failure," even for users who have explicitly opt'd in to reporting back data.
But the team is definitely working on both of these pieces and I'd hope to see it in the near future. No timeline / release number promises, though, right now :-)
1) There are seem to still be regressions in pretty fundamental stuff when new features are added. Usually caught before things reach "release" trains, but I see it in bug trackers all the time.
2) Other layout engine managers I've talked with who want to do a layout system rewrite are terrified of anything that doesn't look like a large-scale refactoring because of this issue. I've had the "how are you testing and measuring progress / how do you know you're done with layout?" conversation with most of our engine peers at this point :-)
Don't forget the amazing work being done at http://testthewebforward.org/ with the Web Platform Tests and your own work on the CSSWG tests! Beyond the specs, having a cross-browser set of tests that have especially good coverage on newer specs has been a huge leg-up for Servo!
It not only helps us ensure interop for those features that are tested, but (puts on former dev manager hat) it really helps quantify how many work items are left until a feature is closer to completion. I especially notice it when there are areas like CSS 2.1 where the tests are less comprehensive and it's harder to quantify what our progress/status is.
If you're using the GitHub code review UI today, reviewable is pretty much an immediate upgrade. We've found that we use it for anything non-trivial. So, if it's more than a few lines or would take more than a couple of comments, we use Reviewable instead.
Pretty much the only things we have issues with are:
- The UI is a little fancy. Sometimes figuring out how to get back to the PR itself so that I can tell our autolander service (http://homu.io/) to land the PR is hard because the dancing CSS butterflies get in the way :-)
- We're a Mozilla project, so we disproportionately use Firefox. Let's just say it's not the browser of primary testing (though it's ahead of some others!), given the demographic of developers who access GitHub.
- Every once in a while really long-lived PRs get rebased, squashed, and reordered so many times that all of the introduced pseudo-commits are bigger than the actual thing to review itself. I'm really not sure what could be done to help here, though.
Apart from the UI, Reviewable also handles many of the really ugly "they did an over-under rebase, force-pushed, did another, then flipped back" cases that come up with longer-lived PRs and manages to keep the review state reasonable better than any other tool I've seen. And we've tried quite a few of them :-)
http://servo.github.io/servo-starters/
One of the biggest challenges we have is keeping some around and available! The good ones almost always have an opened PR within 24 hours:
https://twitter.com/ServoDev/status/665930502503723008
There are a bunch of other benefits to these bugs, including:
- There's a lively stream of people setting up the dev environment for the first time, both keeping our instructions up to date and making sure we handle scenarios like slow internet connections, really old versions of Ubuntu or Linux graphics drivers, etc.
- Reviewing these bugs is also a good way to help grow contributors from committers into reviewers/maintainers.
Most of our challenges with these kinds of bugs are related to GitHub. e.g., you can't "assign" an issue to somebody outside of the project organization, so somebody has to manually label it "Assigned" for our filters to work. Also, you don't get notifications when somebody pushes a new commit to their work branch or rebases, so there's a lot of manual watching of these PRs during the review cycle that sometimes gets dropped (though our myriad GH bots could probably fix this!).
Even with the challenges, we love having this kind of bug as a way to bring in more contributors and keep development on the project accessible, and like the author, I'd highly recommend it to other projects.
https://drive.google.com/file/d/0B9-EBhw4XiWEOWFfc0NiUkk5Tjg...
Servo has polyrepo style (many separate source repositories), as opposed to the monorepo style of other browsers. So, it's not just the `components` directory, but many of the ~140 other Cargo crates (https://crates.io/) and raw GitHub packages that come together to form Servo. I have a "deliverable" for Q4 to improve our documentation situation and explain how it all is put together, though this gist is an awesome start!
This is a pain point for us, too, on Servo. There's fantastic active work going on for incremental builds, which will solve our most pressing needs (long turn-around on debug changes).
Also, if you're on linux, make sure you're using gold instead of system ld. That change made a huge difference for Servo.
If (when!) Servo continues to execute well, plans for integrating more risky pieces will require more top-down planning than the bottom-up, grassroots work that is going on today. As much as I love Servo, even I wouldn't argue we should stop the world and move 200 developers off of Firefox onto working on it full-time for the next year. Such initiatives rarely go as planned.
1) Probably won't have done the full sort of inspection of our SSL cert checking to really ensure you aren't being MITM'd.
2) We won't have a chemspill / 0-day security fix infrastructure in place, so we won't have a way to push down fixes to 0-day exploits in OpenSSL, the JS engine, etc.
I'd love to be at a better point on those features by the end of this year, but it's not likely with our current roadmap & resourcing plan.
On the correctness of unsafe code, we have very few instances where Servo will actually crash (as opposed to panic and unwind "gracefully"), but they've overwhelmingly been in unsafe code blocks when we weren't properly respecting lifetimes and caused a use after free.
For interactive applications, the ability to incrementally reflow the page (say, after an element's value for the display property is changed) is crucial. Modern browser engines have a ton of code that tries to minimize the amount of reflow performed (and sometimes loses correctness!), because it's really easy to accidentally reflow too much and fail to maintain 60fps. We of course hope that throwing parallelism at layout will solve some of this in Servo, but having a more principled approach to the problem of recomputation is interesting, too.
That said, if Trident/Edge, Webkit/Blink, and Gecko don't all agree on the implementation of an older feature, we know that it will be a challenge to find middle ground and get things changed and the spec updated to anything more than softer statements using, "MAY."
So, it's definitely no longer "just a research project," but the challenges of finding initial product targets and building out the rest of the Web Platform are definitely large ones!