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

Previous Next

Full log

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
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 05:09:19 -0400

[Message part 1 (text/plain, inline)]

On Thu, Jun 19, 2025 at 1:09 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Cc: 78216 <at> debbugs.gnu.org
> > From: Stéphane Marks <shipmints <at> gmail.com>
> > Date: Wed, 18 Jun 2025 13:02:24 -0400
> >
> > My aim will be to create a feature branch for the vtable fixes and
> updates (of which there are quite a few
> > along with improved documentation) with the ultimate goal to merge it to
> master.
>
> 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.

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 :).

-Stéphane

[Message part 2 (text/html, inline)]

Previous Next

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