From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 4L03IFFjoWDfJAAAgWs5BA (envelope-from ) for ; Sun, 16 May 2021 20:24:17 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id sGT3G1FjoWDvcgAA1q6Kng (envelope-from ) for ; Sun, 16 May 2021 18:24:17 +0000 Received: from mail.notmuchmail.org (nmbug.tethera.net [144.217.243.247]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 3036013D1F for ; Sun, 16 May 2021 20:24:15 +0200 (CEST) Received: from nmbug.tethera.net (localhost [127.0.0.1]) by mail.notmuchmail.org (Postfix) with ESMTP id DF8C929032; Sun, 16 May 2021 14:24:08 -0400 (EDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) by mail.notmuchmail.org (Postfix) with ESMTPS id E0AF627DF2 for ; Sun, 16 May 2021 14:24:06 -0400 (EDT) Received: by mail-wr1-x432.google.com with SMTP id d11so4116961wrw.8 for ; Sun, 16 May 2021 11:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:content-transfer-encoding:subject:from:to:in-reply-to :references:date:message-id:user-agent; bh=U6VfagK8cpxws6fWrhtXq6/1j7j/01rrEoiCJAZGFA4=; b=G+GqzR2qHqylbbu6BckxZmdjGvNjg3Anwo6Uebd2zD1AGX37k/hcFTUK2k90mZKYOl PFvUPrCHl99gC9K2Z9tFFviD5SnMIoEUlh62ptm7p6LXpf3q1JVWbs+lxKyLHv+TSSUf 46Wjl721d5NvHjbux13uCYKprIdZR5RWHYgoYj9WbbNOrgzlm+5V3lqc37zen9BtbWFY ZSbHJZ88DRXHjX6bcRO/EjnfET8l3v09iqkoy6lqytGjXFXGmzQOqhnoZS/Z/YLG3UFx OawMdGQj2sSlCtPXG+QrGIggmjgQR1e2oQAHJnGT3/xPRF+XP3xL36QTqLtkua67FdfQ Lfkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding:subject :from:to:in-reply-to:references:date:message-id:user-agent; bh=U6VfagK8cpxws6fWrhtXq6/1j7j/01rrEoiCJAZGFA4=; b=ArkpXDmZnjP5xy+TmiZkjQVLOnlSrlHNkUfYfpymu70CeI5+gsksH4Ui7oLvHici21 p7DguGWxZ8O/t3L2yRcbs7eOKhnV0DyBjv5Z6ZCwVpFNZ/4ToU1IJNKyOZYCRXFBTaV8 /dT2MgyaVrhMClW5sACQJurVv3iGC+2Fv4cx+5PgSBGStl2knijZ47+YDjdRUmwVF3eH PUtJZhGaAbW0bAGKD8O4XBn4NKs9tRhKpUM/X7xA0/qxzfsvhT1929wfZAp8p1AGCBPD cO3h6MPySg10MVrHHhATYO/51/6/XqcxbkKeKiTsAUzvuus96fXOsSa9DTFShLBAAgds bNzA== X-Gm-Message-State: AOAM531Ss8RSZPICEdmk5pfVUEg0GhXA2gDaYLJxPL0rZbD/H8MBu4a3 7/Hi1+4NHdsnQGfBZwZLiZU= X-Google-Smtp-Source: ABdhPJzsAhLRdm5Vhh1mrcxhsBCyBkviPS/loH5F3Pgc28n71l+pmQ9byZx/ujEWifce3m9TNq5YoQ== X-Received: by 2002:a5d:678d:: with SMTP id v13mr68401429wru.85.1621189439288; Sun, 16 May 2021 11:23:59 -0700 (PDT) Received: from localhost (0.2.a.7.9.f.b.3.5.1.d.5.a.1.9.8.4.3.5.d.1.c.a.7.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:7ac1:d534:891a:5d15:3bf9:7a20]) by smtp.gmail.com with ESMTPSA id b15sm13928696wru.64.2021.05.16.11.23.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 16 May 2021 11:23:58 -0700 (PDT) MIME-Version: 1.0 Subject: Re: announce: my fork of alot From: Patrick Totzke To: Anton Khirnov , Michael J Gruber , notmuch@notmuchmail.org In-Reply-To: <162118724451.29687.13284058079630704324@lain.red.khirnov.net> References: <162116038546.29687.12722695687857643272@lain.red.khirnov.net> <162116372803.55588.12574083715280154635.git@grubix.eu> <162117970935.470262.11733111308148672432@piu> <162118724451.29687.13284058079630704324@lain.red.khirnov.net> Date: Sun, 16 May 2021 19:23:58 +0100 Message-ID: <162118943864.470262.9109053349416524142@piu> User-Agent: alot/0.9.1 Message-ID-Hash: RD365NCM22NUKGVMFZ3UIBSAPJ6RJVZA X-Message-ID-Hash: RD365NCM22NUKGVMFZ3UIBSAPJ6RJVZA X-MailFrom: patricktotzke@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-notmuch.notmuchmail.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.2.1 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1621189455; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=8PM6msXT3HnMUyHgkK2owgLfVJROMXbjndk88aKYg7c=; b=hZ1BuuC7/4+yHoeppRvp+EAhfsjWVmbIvIHvUBL6rBBZlpCK2KDJH0WQlmbEUQ9Mx6jXBE ybcWSxUMDHUtZ860XqYqge6c3EOizfN8DKqKHj0QaKvA4vLbDn7T7fI+ebKm/uzpf8TiN4 Ry/HLSIqa4zp0I+l+kWWgKmDyhzEYx+fBpZ+YNzo7KY3Kp3iyjkuq/RWLGeA+/aSnj+OAb gsicLdOxO4FKs4JxJRDw2rx7TgSvpeWjVyTFD5Qgc8lNCrA4k11gMi98NlIPpNY9lVrx8t ue/re7STedBvoQDaDdTCFz+k6PFPyUg/Qegh4Ie5MbxkFiBtMNQ1FIQESty3XQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1621189455; a=rsa-sha256; cv=none; b=PzNsn9B7kkVfNUMmvfYZZ+Z1QX6/XOZkZMz5oY1D3rJ78Lzqr6/idYvADcP91T1WgaUeSK lBo4ZiLIlXYjojaAf3PXYViKYC/rVh7Y65lWjPcCWEa2a2ymorEyojWXKOVnr+O1NmSOrW R07sFPDIZmBDS3E49WeC9UcRnmFWzuiFJ6hfn6Jlby+HpblWDTAJpbj5mep8GHWcTm9OJF 6gtto0hhhuyH0oqgvLOIi8hDmYC5+7I6pmWIWwyueLGQlOYihGG0lgxRDtjvqVp90c5/0C opU/6v4uCTrJXDmBrEAGcRZdw+AnN6SBUjnLL7ehYQ55KwPOSvBKetf54fzIXg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("body hash did not verify") header.d=gmail.com header.s=20161025 header.b=G+GqzR2q; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 144.217.243.247 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Spam-Score: 1.03 Authentication-Results: aspmx1.migadu.com; dkim=fail ("body hash did not verify") header.d=gmail.com header.s=20161025 header.b=G+GqzR2q; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 144.217.243.247 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Queue-Id: 3036013D1F X-Spam-Score: 1.03 X-Migadu-Scanner: scn0.migadu.com X-TUID: JH+szWK979lL 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