GNU bug report logs - #78216
[PATCH] * admin/MAINTAINERS: Added myself as the vtable.el maintainer.

Previous Next

Full log

Message #23 received at 78216 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: corwin <at> bru.st, 78216 <at> debbugs.gnu.org
Subject: Re: bug#78216: [PATCH] * admin/MAINTAINERS: Added myself as the
 vtable.el maintainer.
Date: Thu, 19 Jun 2025 12:14:44 +0300

> From: Stéphane Marks <shipmints <at> gmail.com>
> Date: Thu, 19 Jun 2025 05:09:19 -0400
> Cc: corwin <at> bru.st, 78216 <at> debbugs.gnu.org
> 
>  A feature branch is justified when you are working on a large feature
>  that might potentially break the existing features on master.  Is that
>  the case?  If you intend to install a significant number of changes,
>  but each one of them will be pushed as a single changeset and will not
>  cause vtable to be in inconsistent state that makes it unfit for
>  everyday usage, then we prefer to install such changes on master.
>  This has two important advantages: (1) it lets more people test the
>  changes (since the number of people who will checkout such a branch is
>  expected to be small), and (2) it is easier to install such changes
>  because that avoids the need to switch branches, especially if someone
>  else will install your patches.
> 
>  Thanks.
> 
> There were many intertwined and delicate fixes in vtable that took a while to discover and deal with,
> especially that it was almost completely broken for multiple vtables in a single buffer, and a bunch of nice
> feature additions chosen in collaboration with other vtable users.  I think the revisions are ready for other
> people to try and there are a couple of things I volunteered to do, e.g., a tab-bar feature discussed with Juri
> and I propose something similar for project.el, for which I'd use the revised vtable.
> 
> I'd prefer at this stage to publish a revised vtable and its revised info file all at once, hence the idea it might
> be better suited for a feature branch that might aid public feedback and commits off master until ready.  I
> assumed I'd be able to publish to this feature branch without touching master (or at least commit to not
> touching master if there is no branch protection/authorization mechanism on Savannah).
> 
> All the changes are backward compatible, save the bugs, and I think vtable is still sufficiently young and
> underused (I did my best to survey uses in the wild and read the code I found), that this approach poses little
> risk and much more gain.

If there's no particular reason to believe the individual pushes might
break use of vtable, I think installing on master is preferable.

> Happy to use the mailing list if I'm not yet up-to-snuff to commit to a feature branch or directly to the sole files
> I'd maintain and I'll open a new bug for the revision and close the previous bug I opened when I started this
> (and before I understood how much work Lars left :).

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.