inducer
[WIP] Towards using webpack, stop using django-bower
cc @dzhuang
Lots left to do:
- [ ] Fix Django templates to refer to this
- [ ] Get a basic page load to work
- [ ] Get calendar to work
- [ ] Deal with Mathjax (likely outside of webpack)
- [ ] Update CIs
- [ ] Update install documentation
This was long overdue. Bower is showing its age, plus django-bower is showing issues like https://github.com/inducer/relate/commit/c57e4a90831e1b5ddbde4f95750efd50333cef6e#commitcomment-26845580. I imagine it'll help quite a bit with our page load times, too.
FWIW, this looks quite promising to me, but I'm not sure I'll have the time to finish this. If you have some time to look into this, I'd be much obliged.
Codecov Report
Merging #412 into master will decrease coverage by
<.01%. The diff coverage is100%.
@@ Coverage Diff @@
## master #412 +/- ##
==========================================
- Coverage 66.79% 66.78% -0.01%
==========================================
Files 46 46
Lines 10912 10909 -3
Branches 2038 2038
==========================================
- Hits 7289 7286 -3
Misses 2974 2974
Partials 649 649
| Impacted Files | Coverage Δ | |
|---|---|---|
| relate/settings.py | 80.26% <100%> (-0.75%) |
:arrow_down: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing dataPowered by Codecov. Last update 42abc66...11cf0db. Read the comment docs.
Looks like Mathjax will need some handholding: https://github.com/mathjax/MathJax/issues/1629
I see in the issue of mathjax you metioned above that mathjax 3.0 will integrate webpack, so we need to wait for that?
Mathjax 3, to me, is one of those "may never happen" projects. I've hacked the downloading bit in 5cf08457, so that now just needs to be wired up.
I felt currently for cooperation on PRs like this one is too slow: I submit PR with this as target, and wait for your response to merge (into this one), and then another round. Days were passing by very fast, especially when you are busy..., and the time I'm allowed on it is also decreasing.
I found about-protected-branches and repository-permission-levels. You can set master branch as a protected one for security reason, and allow cooperators like me to work with more freedom and effectiveness on branches like this.
I felt currently for cooperation on PRs like this one is too slow: I submit PR with this as target, and wait for your response to merge (into this one), and then another round. Days were passing by very fast, especially when you are busy..., and the time I'm allowed on it is also decreasing.
I agree with your assessment, and I agree that we should do something to improve the situation. In terms of review bandwidth, I am doing what I can, but I am also at capacity given everything else on my plate.
I would be more than happy to let you be a co-maintainer. This would allow you to be faster in getting changes into the code base. Especially for changes that are easy to fix later, I would be happy to have you apply your own good judgment (This PR is a good example of that type of change) and get your changes directly into master. For changes to the data model or semantics (which are hard to change once they're in--#423 comes to mind as an example), I think it's still sensible to build consensus before proceeding. (The same goes for me--I wouldn't proceed with a change like that without getting your OK.)
Let me know if you'd be interested in a co-maintainer role for Relate.
Let me know if you'd be interested in a co-maintainer role for Relate.
I'm glad to. But I'm not confident enough if that will reduce your work. For example, I don't know whether PR like #431 and #419 can be merged. For me, they LGTM, but I don't know if they did for you.
For changes to the data model or semantics (which are hard to change once they're in--#423 comes to mind as an example), I think it's still sensible to build consensus before proceeding.
I agree.
BTW, I think it will help if you release the reviewing status (by some comments (tag)) of a patch, like "need tests", "need improvements", "pending for review", "denied" or even close. Or contributors will not know what's happening: whether it was denied or should I do more improvement, or should I try to prove myself right, or just the reviewer have no time though the patch is good. It helps for saving contributors time. (I know that's hard, and it seems that's common for open source projects, but for me, I sometimes just felt some kind of frustrated for some patches, like Event CRUD, and Ipython notebook patches, and the above metioned #431, I didn't know why they are not merged.)
I'm glad to.
Great, you're in. (or invited at least)
For me, they LGTM, but I don't know if they did for you.
The point (to me) is that I just have to give up some control in order to keep both of us efficient and happy. I've seen enough of your work that I trust you. If it's a change that we can back out and you think it's ready, just go with that and stick it in, and we'll see what happens.
Or contributors will not know what's happening: whether it was denied or should I do more improvement, or should I try to prove myself right, or just the reviewer have no time though the patch is good
That's a fair point. I'm sorry for having caused you grief. Honestly, what leads to this most of the time is that I get unsure whether I like a patch or not, I postpone the decision, and it sinks away to the bottom of my inbox, and then there's always something more urgent to take care of. Not a great way of coping (sorry!), but that's how it was. So let's do this differently: Merge it in, and if I seriously hate it, I'll complain.
I've seen enough of your work that I trust you.
Thanks for your trust. And I'll try to do it well.
Also granted you access to the Gitlab repo, as pushing there is what updates the doc site.