Дилян Палаузов writes: > > We should support netcat as a browser > > Can you provide more information for this browser, as I could not > find any references for it.
"man 1 nc". It's literally cat(1) for network connections. I'm old, my jokes smell of dust and mold. > As long as the currently proposed changes, which reduce dependency > on jQuery, are not integrated, I personally see no point to look at > further places to reduce the dependency on jQuery. jQuery is still a dependency for all three modules (Postorius, HyperKitty, and django_mailman3), is it not? The dependency reduction that interests me is when users see pages load more quickly. Integration is not going to happen for your convenience, because it imposes burdens on other developers. If you or others continue to substitute plain JS for jQuery code, we will be happy to occasionally request testing from beta testers and do our own at significant points (eg, when you remove "import jquery" from one or more files, definitely when Postorius or HyperKitty becomes jQuery-free). > The opposite is not true: if the currently proposed changes are > integrated in the master branch, it does not mean that I will > propose further changes. Yes, that's a problem. You've already made it clear that we can't be sure you will complete jQuery removal, so we might get left with a bunch of legacy code we don't want. > This project (mailman-core and web interfaces) has anyway > the very unusual practice, for proposed changed as merge request, > to wait (years) until somebody (e.g. by accident) fills a > separate issue, which describes the problem, even if the problem is > described in the merge request. That is not the practice. It is true that we frequently do request an issue *as documentation* that will show up in searches in the issue database. Speaking of trivial effort: you copy the title of the merge request and description of the merge request and add a link to the MR. > So may be, or maybe not, the reason why the proposed by me merge > requests are not considered is, because I have not filled for each > of them a gitlab issue. The reason why merge requests sit there for long periods is because we have very few active committers, and fewer non-committer reviewers. We spend *most* of our time on issues, because they are frequently filed by users who cannot do the work needed. MRs are often filed by people scratching itches that we don't feel at all, or are low quality hacks, so visting the MR page is necessarily lower priority unless our attention is drawn to it by an issue or mailing list post. I've recently offered to review one MR for two careful reviews of third party MRs. That applies to you, too. Note that by "I will review" I mean to continue the conversation until I make a decision or the contributor abandons it. If I decide to reject, the contributor is welcome to appeal to Mark or Abhilash. Quite often I will recommend that, because my objection is a matter of style or personal taste, and I'm happy to leave final decision to another committer. > One of my considerations is that even if a complete jQuery removal > is proposed, it does not mean that the proposal will ever be > reviewed. Having one big change - or many small changes which > together look big - means that the change is hard to review, while > smaller changes now and then are easier to review. Smaller changes now and then are impossible to review, if you would rather that none of the changes be made unless all of them are. And the principle fails in general. Backing out a long series of small changes when you realize that the main project is the wrong thing to do can be very painful. In my experience, over 25 years as a reviewer now, reviewing small changes may be necessary in many cases but that does not make reviewing much easier, because you still have to review the final product. > Splitting the whole in smaller steps also implies that many people > can contribute somehow to the removal of jQuery - now and then - > putting limited time. Nonsense. This is one role for filing an issue -- it's a place to coordinate. I guess you can do that on a merge request, too. But I (personally, this is not project policy) actually like the division of responsibility where "I'm working on foo.py, expect to request review today + 1 week" is in the issue, while "I'm seeing divergent behavior in bar.py after applying the MR, I think your boilerplate for replacing jquery.baz needs '...'" goes in the MRs. Also, in a case like this where the work is very much split up by file, it's likely that people will just file their own MRs, and now you need a place to coordinate those -- an issue is better for that. My preferences aside, you're doing the work, so you get to choose how to coordinate any joint work (until you designate someone else or abandon the project). You just don't get to coordinate it on the master branch. > I do not buy the argument that using no-jQuery-JavaScript and > jQuery (at the same time) prevents development, That's not the argument. The argument is that it's an unnecessary cognitive burden which is imposed on every developer who reads those files. You say "make it convenient for me or I won't do the work". I say "make it inconvenient for other developers and they won't do their work." I'm going to back the other developers every time. You can get the convenience of choosing when your contributions get committed, you know. Do enough work and support other developers well enough to earn a commit bit. Steve -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan _______________________________________________ Mailman-Developers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
