``` [~] git clone https://git.khirnov.net/alot.git Cloning into 'alot'... fatal: unable to access 'https://git.khirnov.net/alot.git/': server certificate verification failed. CAfile: none CRLfile: none [~] git clone git://git.khirnov.net/alot.git Cloning into 'alot'... (times out) ``` Quoting Patrick Totzke (2021-05-16 19:23:58) > Quoting Anton Khirnov (2021-05-16 18:47:24) > > > Quoting Patrick Totzke (2021-05-16 17:41:49) > > > Hi everyone, > > > > > > All this sounds very exciting and I'd be very happy to see these features in > > > (mainline) alot! > > > > > > I agree that some of alot's underlying code is ready for refactoring > > > and urwid in particular has been a big drag on quickly implementing things. > > > Also, I'd be interested in hearing your thoughts on deprecating some "unworthy" > > > features in order to reduce the maintenance effort! > > > > That is largely a matter of perspective and personal preference. E.g. > > among the things gone in my tree are: > > - removing messages - I dropped that because I considered that code > > potentially dangerous, had no use for it myself, and just didn't want > > to tiptoe around it; someone actually using RemoveCommand in their > > workflow would have a different opinion > > Yep, same here. I never used that. > > > - switching to split-window layout for thread view made it simpler to > > implement quote folding, but also made sense to me since I never want > > to see more than one message at once; > > again, someone who prefers collapsing messages would see this as loss > > of functionality > > > > https://xkcd.com/1172/ is very much in effect > > This could have been easily introduced as a separate type of buffer to keep both variants > without breaking things. > > > > > > > Why did I not submit all this as PRs to upstream alot? The main reasons > > > > > were my lack of time and disagreement with the upstream about project > > > > > status. From what I can tell, alot maintainers consider the project to > > > > > be mature, so they prioritize stability and small incremental changes. > > > > > From my perspective, alot is lacking some critical features -- some > > > > > implemented in my fork already, some planned -- which makes it > > > > > borderline-unusable for me. As implementing those features required > > > > > large-scale architectural changes and my free time was quite limited, I > > > > > prioritized quickly implementing the things I cared about over > > > > > progressing in small incremental stable easily-reviewable steps. > > > > > > > > I have a similar impression about the project status. I'm curious: What > > > > are the architectural changes that you made? > > > > > > > > > Yes, the speed at which alot progresses is borderline problematic. This is of > > > course down to the small number of core contributors and the fact that for all > > > of us life goes on an priorities change. > > > > > > One problem is that the project attracts many users interested in pushing what > > > I'd call "hotfixes" to address missing features: Often people would present > > > a (nicely working) proof-of concept that is not well documented, tested, and > > > doesn't adhere to common code conventions, only not to follow up on their > > > promises to "clean things up", for all too understandable reasons. > > > Still, I believe that just merging everything will quickly kill the project as > > > a) this leads to code that is very difficult and time-consuming to maintain and > > > b) broken features are very damaging to user's perception of the software, much > > > more so than missing ones. > > > > > > I am not accusing you of anything here, Anton. I just wish to point out > > > potential long term difficulties and clarify that I tried to err on the side of > > > cautiousness to keep alot afloat in a usable state for most (potential) users. > > > > You would be very correct to accuse me of taking various shortcuts. I > > would not call my changes "hotfixes", as I tried to keep continuous > > future improvements in mind > > I understand. The question is just how long do you plan to stick around > to add improvements and provide support? If your answer is: "not at all, I'm > only sharing my code here", then don't be surprised if your efforts die the > same death and quickly disappear as so many other notmuch projects before. > If you are fine with that: great. But I suppose you wouldn't have shared your > code here unless you'd want people to join in and use it (for longer than > a day). > > > (and in fact see many of my changes as > > cleanup and simplification). > > I'm more than happy to push some of them. > > > But I did make an explicit decision to > > prioritise rapidly adding new functionality, at the cost of potential > > regressions and loss of some features I did not need. > > > > And again, this is a matter of perspective. If alot does what you want > > it to do then of course you will value stability and consistency. But if > > the lack of certain features makes it barely usable, then it makes sense > > to be more radical. > > Yes, I agree. There are many features that I'm personally missing but > either don't yet know how to implement, or already have thought about them > and can see how much extra work it'd be. > I welcome disruption. However, it'd be constructive to introduce changes one at > a time, discuss, then implement them with all bells and whistles (read: document). > > > > > > At this point my tree has over 200 new commits and some ~4k changed > > > > > lines, so it's looking increasingly unlikely that I'll ever find the > > > > > free time and motivation to upstream it -- especially given alot's > > > > > glacial pace of development recently. If people are interested in using > > > > > this, I'll probably fork it "properly" under a new name. > > > > > > > > > > Any comments or questions are very much welcome. I can also be reached > > > > > on IRC as elenril. > > > > > > > > Have you tried raising these concerns with upstream before your fork? > > > > Have you tried gathering a team around an idea and starting something > > > > new together? > > > > > > > > Frankly, upstream is borderline small already, and the way you started > > > > your fork probably will not attract a team of people who want to make > > > > that new fork their (common) own or are looking for a stronger team. > > > > > > I share Michael's concerns about further splintering the small group of > > > developers and believe that this would be to the detriment of both projects. > > > > > > It's no secret that I am ready to give the helm to others. I have been > > > maintaining this project for a while now, mainly for personal usage and as > > > a fun distraction. I have tried to squeeze in time to review pull requests when > > > possible and am grateful for the many code contributions over the years, most > > > notably the big steps towards pgp/mime, python3 and notmuch2, all of which I'd > > > have never found the time to implement myself. > > > > > > It has so far been a successful, albeit slow, strategy to try and coordinate > > > efforts and I would very much like to see this going on, but without > > > sacrificing the quality of the code or the relative mature user experience. > > > > And here is precisely the crux of the problem. My changes are pretty > > drastic and 1) there WILL be bugs 2) someone WILL find them to degrade > > their user experience. You cannot always satisfy everyone. > > I am actually fine with breaking things. > But it has to be justified and changes need to at least be documented somewhere. > Users will adjust or move on. But it is difficult to "re-sort" code once it > becomes inconsistent or unpredictable in my opinion. > > > > Combined with the fact that I also have a lot on my plate and don't see > > myself reshaping my tree into nicely packaged atomic changes with a > > ribbon on top (at least not any time soon). > > That's too bad. Even small PR's would be welcome. > > > > > To be clear: I still do not consider alot "mature" in the sense that I'd oppose > > > radical refactoring. This is reflected in its version number :) > > > > If you can find the time for it, maybe try to look at the individual > > changes in my tree. Try it out, see what makes sense to you, what > > doesn't, etc. I would be happy to see it all merged into alot, just > > don't see how it can practically be done through the normal channels. > > Look, if you can't be bothered to go via "the normal channels", > then it's unlikely that anyone wants to spend the time to dig though your code > to find (upstream) usable nuggets. If someone does, and re-packages into a PR > then cool. I don't see myself spending much time on that I'm afraid. > > > > E.g. one thing I expect to be contentious is the removal of urwidtrees > > use. I understand you are its author, so it may be unpleasant to hear, > > but I found it to be a major obstacle to implementing quote folding. > > No: I authored urwidtrees out of necessity. Urwid simply did not have > a widget for trees at the time and I wanted to replicate the sup/gmail > type of buffer. It is not particularly great code and I'd be happy to see it go. > > Best wishes, > P