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

Previous Next

To reply to this bug, email your comments to 78216 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Ship Mints <shipmints <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] * admin/MAINTAINERS: Added myself as the vtable.el maintainer.
Date: Fri, 2 May 2025 11:19:36 -0400

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

See subject.

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

[0001-admin-MAINTAINERS-Added-myself-as-the-vtable.el-main.patch (application/octet-stream, attachment)]

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

From: Ship Mints <shipmints <at> gmail.com>
To: 78216 <at> debbugs.gnu.org
Subject: Re: bug#78216: [PATCH] * admin/MAINTAINERS: Added myself as the
 vtable.el maintainer.
Date: Fri, 2 May 2025 11:23:38 -0400

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

On Fri, May 2, 2025 at 11:21 AM Ship Mints <shipmints <at> gmail.com> wrote:

> See subject.
>

Lars suggested I request committer rights. I assume I would commit to limit
commits to vtable-related files.

-Stephane

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

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

From: Corwin Brust <corwin <at> bru.st>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 78216 <at> debbugs.gnu.org
Subject: Re: bug#78216: [PATCH] * admin/MAINTAINERS: Added myself as the
 vtable.el maintainer.
Date: Fri, 2 May 2025 12:12:25 -0500

On Fri, May 2, 2025 at 10:23 AM Ship Mints <shipmints <at> gmail.com> wrote:
>
> On Fri, May 2, 2025 at 11:21 AM Ship Mints <shipmints <at> gmail.com> wrote:
>>
>> See subject.
>
>
> Lars suggested I request committer rights. I assume I would commit to limit commits to vtable-related files.
>

FWIW, this type of request doesn't usually come via Email.

You should be able to request commit rights from Savannah's web-ux,
given you have registered an account (which is needed to be granted
membership in Emacs or whatever project).

https://savannah.gnu.org/project/memberlist.php?group=emacs

Let me know if you have any problems!

PS, once you have membership in any project on Savannah you can use
the memher form of cloning (ssh://YOU <at> git.savannah.gnu.org/...) for
any project we host.  It's faster and makes better use of savannah's
compute compared to using https).

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: Corwin Brust <corwin <at> bru.st>
Cc: 78216 <at> debbugs.gnu.org
Subject: Re: bug#78216: [PATCH] * admin/MAINTAINERS: Added myself as the
 vtable.el maintainer.
Date: Wed, 18 Jun 2025 13:02:24 -0400

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

On Fri, May 2, 2025 at 1:12 PM Corwin Brust <corwin <at> bru.st> wrote:

> On Fri, May 2, 2025 at 10:23 AM Ship Mints <shipmints <at> gmail.com> wrote:
> >
> > On Fri, May 2, 2025 at 11:21 AM Ship Mints <shipmints <at> gmail.com> wrote:
> >>
> >> See subject.
> >
> >
> > Lars suggested I request committer rights. I assume I would commit to
> limit commits to vtable-related files.
> >
>
> FWIW, this type of request doesn't usually come via Email.
>
> You should be able to request commit rights from Savannah's web-ux,
> given you have registered an account (which is needed to be granted
> membership in Emacs or whatever project).
>
> https://savannah.gnu.org/project/memberlist.php?group=emacs
>
> Let me know if you have any problems!
>
> PS, once you have membership in any project on Savannah you can use
> the memher form of cloning (ssh://YOU <at> git.savannah.gnu.org/...) for
> any project we host.  It's faster and makes better use of savannah's
> compute compared to using https).
>

I've reinstated my savannah account, registered an ssh key, and requested
emacs group access.

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.

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

Message #17 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 08:09:02 +0300

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

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)]

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.