Re: announce: my fork of alot

[Patrick Totzke <patricktotzke@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 9499 bytes --]

```
[~] 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

[-- Attachment #1.2: Type: text/html, Size: 19659 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]