Re: More classes of maintainer

[Herby G]

I think the challenge with base is that it's a Tcl codebase, which is a
language most developers these days are less familiar with.
Folks write Portfiles, yes, but they don't have to write proper Tcl too
much as much of Portfile development is very declarative.

I also understand the desire not to get too bought into Github, but like it
or not, it's a massive default in the world of modern software development.

I have a strong notion that if we started using Github Issues for tickets,
after a while we'd see an uptick in tickets being opened by the community
(granted that it would take a while for the understanding to propagate that
Github Issues is available). That's because Github Issues is less friction
for folks already using Github for all the other software they're working
with, as compared to having to deal with an entirely separate ticketing
system.  Don't get me wrong: Trac is arguably low-friction, but a lot of
folks would just not bother the minute they see it's something they have to
go outside of Github to do.

On Wed, Nov 8, 2023 at 7:33 PM Eric Gallager  wrote:

> On Wed, Nov 8, 2023 at 3:47 PM Clemens Lang  wrote:
> >
> > Hi,
> >
> > On Sun, Nov 05, 2023 at 01:58:00PM -0500, Perry E. Metzger wrote:
> > > On 11/5/23 13:37, Daniel J. Luke wrote:
> > > > To clarify - this was in the context of commits to base/
> > > >
> > > > (That may or may not change your perception - but like I said, I
> > > > didn’t measure and this is totally measurable).
> > >
> > > I don't think the base tools are getting a lot of attention because
> > > they mostly just work?
> >
> > Maybe that's the perception, but I'd argue it really isn't true. There
> > are lots of improvements that could be had in base, if somebody had the
> > time to implement them.
> >
> > Just to name a few ideas:
> >
> > - Hooks to run certain scriptlets (defined somewhere in the ports tree)
> >   when files in specific directories are installed
> > - Switching selfupdate from rsync to http, which would avoid leaving
> >   users behind where the network blocks rsync
> > - Switching to more modern signatures compared to the RSA signature over
> >   the RMD160 hash we're still using today
> > - Improvements to make builds more reproducible (e.g.,
> >   SOURCE_DATE_EPOCH, clamping mtimes of generated files, ...)
> > - Finishing the 'port migrate' command to automate the migration process
> > - Better post-build testing to detect problems in ports, e.g., scanning
> >   all compiled binaries to ensure that the files they link against are
> >   in their declared transitive dependencies.
> >
> > And these are just the ones I have worked on, or have on my todo list.
> >
>
> Yeah, I've got a bunch written down, too; this Trac query gets the
> ones that I've filed tickets for on Trac over the years:
>
> https://trac.macports.org/query?status=accepted&status=assigned&status=new&status=reopened&component=base&reporter=egall%40macports.org&reporter=egall%40gwmail.gwu.edu&reporter=cooljeanius&order=priority
> ...and these are the ones I'm on cc for:
>
> https://trac.macports.org/query?status=accepted&status=assigned&status=new&status=reopened&cc=~egall%40macports.org&cc=~egall%40gwmail.gwu.edu&cc=~cooljeanius&component=base&order=id
>
> > --
> > Clemens
> >
>

Re: More classes of maintainer

[Eric Gallager]

On Wed, Nov 8, 2023 at 3:47 PM Clemens Lang  wrote:
>
> Hi,
>
> On Sun, Nov 05, 2023 at 01:58:00PM -0500, Perry E. Metzger wrote:
> > On 11/5/23 13:37, Daniel J. Luke wrote:
> > > To clarify - this was in the context of commits to base/
> > >
> > > (That may or may not change your perception - but like I said, I
> > > didn’t measure and this is totally measurable).
> >
> > I don't think the base tools are getting a lot of attention because
> > they mostly just work?
>
> Maybe that's the perception, but I'd argue it really isn't true. There
> are lots of improvements that could be had in base, if somebody had the
> time to implement them.
>
> Just to name a few ideas:
>
> - Hooks to run certain scriptlets (defined somewhere in the ports tree)
>   when files in specific directories are installed
> - Switching selfupdate from rsync to http, which would avoid leaving
>   users behind where the network blocks rsync
> - Switching to more modern signatures compared to the RSA signature over
>   the RMD160 hash we're still using today
> - Improvements to make builds more reproducible (e.g.,
>   SOURCE_DATE_EPOCH, clamping mtimes of generated files, ...)
> - Finishing the 'port migrate' command to automate the migration process
> - Better post-build testing to detect problems in ports, e.g., scanning
>   all compiled binaries to ensure that the files they link against are
>   in their declared transitive dependencies.
>
> And these are just the ones I have worked on, or have on my todo list.
>

Yeah, I've got a bunch written down, too; this Trac query gets the
ones that I've filed tickets for on Trac over the years:
https://trac.macports.org/query?status=accepted&status=assigned&status=new&status=reopened&component=base&reporter=egall%40macports.org&reporter=egall%40gwmail.gwu.edu&reporter=cooljeanius&order=priority
...and these are the ones I'm on cc for:
https://trac.macports.org/query?status=accepted&status=assigned&status=new&status=reopened&cc=~egall%40macports.org&cc=~egall%40gwmail.gwu.edu&cc=~cooljeanius&component=base&order=id

> --
> Clemens
>

Re: More classes of maintainer

[Clemens Lang]

Hi,

On Sun, Nov 05, 2023 at 01:58:00PM -0500, Perry E. Metzger wrote:
> On 11/5/23 13:37, Daniel J. Luke wrote:
> > To clarify - this was in the context of commits to base/
> > 
> > (That may or may not change your perception - but like I said, I
> > didn’t measure and this is totally measurable).
> 
> I don't think the base tools are getting a lot of attention because
> they mostly just work?

Maybe that's the perception, but I'd argue it really isn't true. There
are lots of improvements that could be had in base, if somebody had the
time to implement them.

Just to name a few ideas:

- Hooks to run certain scriptlets (defined somewhere in the ports tree)
  when files in specific directories are installed
- Switching selfupdate from rsync to http, which would avoid leaving
  users behind where the network blocks rsync
- Switching to more modern signatures compared to the RSA signature over
  the RMD160 hash we're still using today
- Improvements to make builds more reproducible (e.g.,
  SOURCE_DATE_EPOCH, clamping mtimes of generated files, ...)
- Finishing the 'port migrate' command to automate the migration process
- Better post-build testing to detect problems in ports, e.g., scanning
  all compiled binaries to ensure that the files they link against are
  in their declared transitive dependencies.

And these are just the ones I have worked on, or have on my todo list.

-- 
Clemens

Re: More classes of maintainer

[Perry E. Metzger]

On 11/6/23 06:49, Mark Anderson wrote:
The other thing that is different now is GitHub issues and projects 
have come a long way in terms of features - we can probably implement 
everything we do on Trac on Github as well.


As I recall Github issues didn't have all the features we needed. It 
also would help us not need to manage our own Trac instance.


It has indeed become much more feature complete, and loads more people 
are used to using github issues when a project is managed on github.


Perry

Re: More classes of maintainer

[Rainer Müller]

[Resending, K-9 Mail from mobile sent it with an empty HTML version.]

On 06/11/2023 12.49, Mark Anderson wrote:
> The other thing that is different now is GitHub issues and projects have
> come a long way in terms of features - we can probably implement
> everything we do on Trac on Github as well. 

Well, that is what I was asking... I am not aware of improvements. What
has changed with GitHub Issues?

How would we find issues for specific ports? There is only a lose
full-text search. Imagine how that will work for a port named "add"
(real example) or any other common English word.

You cannot assign issues to non-member maintainers (at least they would
have to leave a comment first). We already experience the same situation
for pull-requests where mentions are used as a workaround.

GitHub Projects are nice, but we are not an agile development team doing
sprints. If we moved the tickets for base it would be replacement for
the milestones on Trac.

But I don't see how GitHub Projects would help us with the issues for
ports, which are most of the tickets being filed every day.

> As I recall Github issues didn't have all the features we needed. It
> also would help us not need to manage our own Trac instance.

The other big part of Trac is the wiki. GitHub also has a wiki, but only
on the level of repositories. However, our wiki also covers many topics
that overlap between base, ports, etc.

Conversion of the wiki to GitHub with Markdown syntax would certainly be
possible, but to me that feels like hiding it even more and will not
give it more exposure.

Rainer

Re: More classes of maintainer

[Rainer Müller]

On November 6, 2023 12:49:26 PM GMT+01:00, Mark Anderson  
wrote:
>The other thing that is different now is GitHub issues and projects have
>come a long way in terms of features - we can probably implement everything
>we do on Trac on Github as well.

Well, that is what I was asking... I am not aware of improvements. What has 
changed with GitHub Issues?

How would we find issues for specific ports? There is only a lose full-text 
search. Imagine how that will work for a port named "add" (real example) or any 
other common English word.

You cannot assign issues to non-member maintainers (at least they would have to 
leave a comment first). We already experience the same situation for 
pull-requests where mentions are used as a workaround.

GitHub Projects are nice, but we are not an agile development team doing 
sprints. If we moved the tickets for base it would be replacement for the 
milestones on Trac.

But I don't see how GitHub Projects would help us with the issues for ports, 
which are most of the tickets being filed every day.

>As I recall Github issues didn't have all the features we needed. It also
>would help us not need to manage our own Trac instance.

The other big part of Trac is the wiki. GitHub also has a wiki, but only on the 
level of repositories. However, our wiki also covers many topics that overlap 
between base, ports, etc.

Conversion of the wiki to GitHub with Markdown syntax would certainly be 
possible, but to me that feels like hiding it even more and will not give it 
more exposure.

Rainer

Re: More classes of maintainer

[Mark Anderson]

The other thing that is different now is GitHub issues and projects have
come a long way in terms of features - we can probably implement everything
we do on Trac on Github as well.

As I recall Github issues didn't have all the features we needed. It also
would help us not need to manage our own Trac instance.

—Mark
___
Mark E. Anderson 
MacPorts Trac WikiPage 
GitHub Profile 



On Sun, Nov 5, 2023 at 2:13 PM Joshua Root  wrote:

> On 6/11/2023 05:58, Perry E. Metzger wrote:
> > On 11/5/23 13:37, Daniel J. Luke wrote:
> >> To clarify - this was in the context of commits to base/
> >>
> >> (That may or may not change your perception - but like I said, I
> >> didn’t measure and this is totally measurable).
> >
> > I don't think the base tools are getting a lot of attention because they
> > mostly just work?
>
> Could well be a factor. I'm certainly pretty satisfied with the state of
> base now, considering what it was like in 2006.
>
> There are still quite a few tickets and not a lot of people closing them
> though. (Not to mention all the stuff on the "nice to get to someday"
> list, some of which is too vague to even make sense as a ticket.)
>
> - Josh
>

Re: More classes of maintainer

[Joshua Root]

On 6/11/2023 05:58, Perry E. Metzger wrote:

On 11/5/23 13:37, Daniel J. Luke wrote:

To clarify - this was in the context of commits to base/

(That may or may not change your perception - but like I said, I 
didn’t measure and this is totally measurable).


I don't think the base tools are getting a lot of attention because they 
mostly just work?


Could well be a factor. I'm certainly pretty satisfied with the state of 
base now, considering what it was like in 2006.


There are still quite a few tickets and not a lot of people closing them 
though. (Not to mention all the stuff on the "nice to get to someday" 
list, some of which is too vague to even make sense as a ticket.)


- Josh

Re: More classes of maintainer

[Joshua Root]

On 6/11/2023 05:57, Perry E. Metzger wrote:

On 11/5/23 13:36, Joshua Root wrote:
There has been an increase in commit volume in more recent years, but 
it certainly didn't coincide with the GitHub migration in 2016.


Put it differently: I do a lot of merges of updates from random people 
to the repository, and I'd probably be doing none of it if I couldn't do 
the code review, CI checks, etc. cleanly and easily inside of Github. 
Modern development tools make a lot of stuff ever so much easier.


I don't disagree that PRs are a smoother workflow for some common cases. 
You don't have to sell GitHub for this, we already decided to use it. :)


If we did ever decide to switch platforms, it would almost certainly be 
to something with equivalent functionality.


Perhaps it took a while from the repository transfer until people got 
the hang of things so the increase wasn't synchronous, but I really 
don't think anyone would sanely want to go back. It's much better now.


It's really impossible to draw any conclusions about causality here; 
there are too many confounding factors just for starters (like a pandemic.)


- Josh

Re: More classes of maintainer

[Perry E. Metzger]

On 11/5/23 13:37, Daniel J. Luke wrote:

To clarify - this was in the context of commits to base/

(That may or may not change your perception - but like I said, I 
didn’t measure and this is totally measurable).


I don't think the base tools are getting a lot of attention because they 
mostly just work?


Perry

Re: More classes of maintainer

[Perry E. Metzger]

On 11/5/23 13:36, Joshua Root wrote:
There has been an increase in commit volume in more recent years, but 
it certainly didn't coincide with the GitHub migration in 2016.


Put it differently: I do a lot of merges of updates from random people 
to the repository, and I'd probably be doing none of it if I couldn't do 
the code review, CI checks, etc. cleanly and easily inside of Github. 
Modern development tools make a lot of stuff ever so much easier.


Perhaps it took a while from the repository transfer until people got 
the hang of things so the increase wasn't synchronous, but I really 
don't think anyone would sanely want to go back. It's much better now.


Perry

Re: More classes of maintainer

[Joshua Root]

On 6/11/2023 05:37, Daniel J. Luke wrote:

To clarify - this was in the context of commits to base/

(That may or may not change your perception - but like I said, I didn’t 
measure and this is totally measurable).


Indeed, the picture is even more clear with base. 



- Josh

Re: More classes of maintainer

[Daniel J. Luke]

To clarify - this was in the context of commits to base/ 

(That may or may not change your perception - but like I said, I didn’t measure 
and this is totally measurable). 
-- 
Daniel J. Luke

> On Nov 5, 2023, at 1:26 PM, Perry E. Metzger  wrote:
> 
> 
>> On 11/4/23 02:42, Daniel J. Luke wrote:
>> 
>>  (Before we moved to github there were many people saying we'd get lots more 
>> commits by moving to it, but the volume doesn't seem much higher to me - of 
>> course, I also didn't measure before/after so my perception could be 
>> incorrect).
> I think that's very, very wrong. There are vastly, vastly more community 
> submitted updates now, and they are easy to apply to the repository with low 
> effort on the part of the macports committers. It's been an unequivocal win.
> 
> Perry
> 
> 

Re: More classes of maintainer

[Joshua Root]

On 6/11/2023 05:26, Perry E. Metzger wrote:

On 11/4/23 02:42, Daniel J. Luke wrote:

(Before we moved to github there were many people saying we'd get lots more 
commits by moving to it, but the volume doesn't seem much higher to me - of 
course, I also didn't measure before/after so my perception could be incorrect).


I think that's very, very wrong. There are vastly, vastly more community 
submitted updates now, and they are easy to apply to the repository with 
low effort on the part of the macports committers. It's been an 
unequivocal win.


The data seems less certain on that: 



There has been an increase in commit volume in more recent years, but it 
certainly didn't coincide with the GitHub migration in 2016.


 - Josh

Re: More classes of maintainer

[Perry E. Metzger]

On 11/4/23 02:42, Daniel J. Luke wrote:

(Before we moved to github there were many people saying we'd get lots more 
commits by moving to it, but the volume doesn't seem much higher to me - of 
course, I also didn't measure before/after so my perception could be incorrect).


I think that's very, very wrong. There are vastly, vastly more community 
submitted updates now, and they are easy to apply to the repository with 
low effort on the part of the macports committers. It's been an 
unequivocal win.


Perry

Re: More classes of maintainer

[Gagan Sidhu via macports-dev]

i agree with this.

i’m still pissed i can’t merge my legacy trac with the new git system. the fact 
they were separate in the first place is like, the antithesis of what the APPUL 
mantra USED to mean.

but whatever. mobile rulz. 2fa, mfa, gfy

tethered to a cancer box no matter what it seems, or maybe that’s what the 
“investors” behind the 2000 tech stocks, who remain the power players, are 
trying to force upon us.

i want to put all of my money into credit suisse first BAHSTUN, right away.

Thanks,
Gagan

> On Nov 3, 2023, at 9:29 PM, grey  wrote:
> 
> To chime in on this, and take what I write with a grain of salt since
> I still feel relatively new to MacPorts, but too much dependence on
> GitHub gives me the heebie jeebies.
> 
> I realize Trac isn't perfect, but there are far worse issue tracking
> systems that I have administered over the decades.
> 
> If anything, I think it would be fantastic (though obviously, a non
> trivial amount of effort) if MacPorts were more self sufficient and
> self hosted and treated closed source for-profit proprietary entities
> such as GitHub as read-only mirrors; or maybe facilitated other git
> front ends such as codeberg, etc.?

Re: More classes of maintainer

[Daniel J. Luke]

On Nov 2, 2023, at 9:26 PM, Perry E. Metzger  wrote:
> On 11/2/23 20:58, Rainer Müller wrote:
>> Did the situation change since our assessment back then? As far as I am
>> aware, there is still not a way to categorize GitHub Issues except with
>> labels. How would we manage the ~4000 open tickets for ports with GitHub
>> Issues?
> 
> I think that much of what's changed in the last seven years has been people's 
> expectations and how people engage with open source projects hosted on 
> Github. It's clearly the case that moving tickets to Github would mean loss 
> of some information, but I think it would be far outweighed by the 
> improvement in engagement by the user community.

I don't have an opinion here other than to say that without any testing, it's 
hard to know what will actually improve engagement.

(Before we moved to github there were many people saying we'd get lots more 
commits by moving to it, but the volume doesn't seem much higher to me - of 
course, I also didn't measure before/after so my perception could be incorrect).

-- 
Daniel J. Luke

Re: More classes of maintainer

[grey]

To chime in on this, and take what I write with a grain of salt since
I still feel relatively new to MacPorts, but too much dependence on
GitHub gives me the heebie jeebies.

I realize Trac isn't perfect, but there are far worse issue tracking
systems that I have administered over the decades.

If anything, I think it would be fantastic (though obviously, a non
trivial amount of effort) if MacPorts were more self sufficient and
self hosted and treated closed source for-profit proprietary entities
such as GitHub as read-only mirrors; or maybe facilitated other git
front ends such as codeberg, etc.?

Re: More classes of maintainer

[Perry E. Metzger]

On 11/2/23 20:58, Rainer Müller wrote:

Did the situation change since our assessment back then? As far as I am
aware, there is still not a way to categorize GitHub Issues except with
labels. How would we manage the ~4000 open tickets for ports with GitHub
Issues?


I think that much of what's changed in the last seven years has been 
people's expectations and how people engage with open source projects 
hosted on Github. It's clearly the case that moving tickets to Github 
would mean loss of some information, but I think it would be far 
outweighed by the improvement in engagement by the user community.


Perry

Re: More classes of maintainer

[Rainer Müller]

On 02/11/2023 21.19, Herby G wrote:
> I actually do think moving tickets and issues from Trac to GitHub Issues
> is a good idea, and would increase engagement for the project.

We evaluated this option thoroughly back in 2016 when we moved the code
repositories to GitHub. As far as I remember it was Ryan who even did a
test run of a conversion of all the Trac tickets to GitHub Issues. The
evaluation phase of different tools went on for weeks.

But the results and the experience with GitHub Issues were not to our
satisfaction. In the end, we decided to keep Trac for the tickets. The
hope was that hosting our own Trac instance would also offer more
flexible options for future improvements, while with GitHub Issues we
would be locked in.

We integrated our Trac instance more closely with GitHub and invested
effort to improve the trac-github plugin (login, roles based on GitHub
teams, closing tickets on merge, links for commit hashes, etc.).

For reference, this was the announcement of the migration to GitHub in
the mail archive:
https://lists.macports.org/pipermail/macports-dev/2016-August/033405.html

Did the situation change since our assessment back then? As far as I am
aware, there is still not a way to categorize GitHub Issues except with
labels. How would we manage the ~4000 open tickets for ports with GitHub
Issues?

Rainer

Re: More classes of maintainer

[Eric Gallager]

I agree, I would just urge caution and a full examination of all the
migration tools available; there are some projects that have done more
successful migrations than others. For example, there was this one
that made "mannequin" accounts of people so that the original
commenters were preserved, and I thought that was pretty neat. I
forget which project it was, though...

On Thu, Nov 2, 2023 at 4:19 PM Herby G  wrote:
>
> I actually do think moving tickets and issues from Trac to GitHub Issues is a 
> good idea, and would increase engagement for the project.
>
> On Thu, Nov 2, 2023, 10:19 Perry E. Metzger  wrote:
>>
>>
>> On 11/1/23 21:54, Joshua Root wrote:
>> > On 2/11/2023 12:32, Perry E. Metzger wrote:
>> >> As an aside, as it stands, the rules situation with closed maintainer
>> >> / open maintainer is kind of unpleasant already. For example, I'd
>> >> like to be able to indicate that I'm happy with anyone making
>> >> reasonable changes to my ports on their own without waiting three
>> >> days for me, but there's no way to do that, because "open maintainer"
>> >> really means "three day timeout" just like closed. It would be nice
>> >> if we had some sort of larger set of gradations for what people
>> >> prefer, from "I handle all commits on this, period" to "if you have
>> >> commit access and want to help, don't ask, just do it."
>> >
>> > A reasonable idea. I'd say that at some point you become less of a
>> > maintainer and more of an interested party, but a list of people who
>> > would just like to be Cc'd on the tickets and PRs for a port isn't a
>> > bad thing to have.
>> >
>> > We seem to have somewhat different experiences, as the reason I
>> > removed openmaintainer from some of my ports was that it seemed to be
>> > interpreted more like "commit whatever you want without asking." So
>> > being able to set expectations more clearly would be nice.
>>
>> For most of my stuff, I don't want to get in the way of trivial updates.
>> If that just makes me an "interested party" so be it. What process would
>> work here?
>>
>> >> As another aside, we also have a ton of ghost maintainers who never
>> >> respond but whose name being on the port means you have to
>> >> ritualistically wait three days for a reply you know will never come.
>> >
>> > This is of course what the Port Abandoned procedure is for.
>> > Regrettably however, it also involves a three-day wait. :)
>>
>> The problem is, with separate trac and github stuff, there's now more
>> friction on those tickets, and I don't think it happens very much in
>> practice. Maybe part of that might be an indication that it's time to
>> move the ticket system to github, and the other trac pages into a github
>> wiki.
>>
>>
>> Perry
>>
>>

Re: More classes of maintainer

[Herby G]

I actually do think moving tickets and issues from Trac to GitHub Issues is
a good idea, and would increase engagement for the project.

On Thu, Nov 2, 2023, 10:19 Perry E. Metzger  wrote:

>
> On 11/1/23 21:54, Joshua Root wrote:
> > On 2/11/2023 12:32, Perry E. Metzger wrote:
> >> As an aside, as it stands, the rules situation with closed maintainer
> >> / open maintainer is kind of unpleasant already. For example, I'd
> >> like to be able to indicate that I'm happy with anyone making
> >> reasonable changes to my ports on their own without waiting three
> >> days for me, but there's no way to do that, because "open maintainer"
> >> really means "three day timeout" just like closed. It would be nice
> >> if we had some sort of larger set of gradations for what people
> >> prefer, from "I handle all commits on this, period" to "if you have
> >> commit access and want to help, don't ask, just do it."
> >
> > A reasonable idea. I'd say that at some point you become less of a
> > maintainer and more of an interested party, but a list of people who
> > would just like to be Cc'd on the tickets and PRs for a port isn't a
> > bad thing to have.
> >
> > We seem to have somewhat different experiences, as the reason I
> > removed openmaintainer from some of my ports was that it seemed to be
> > interpreted more like "commit whatever you want without asking." So
> > being able to set expectations more clearly would be nice.
>
> For most of my stuff, I don't want to get in the way of trivial updates.
> If that just makes me an "interested party" so be it. What process would
> work here?
>
> >> As another aside, we also have a ton of ghost maintainers who never
> >> respond but whose name being on the port means you have to
> >> ritualistically wait three days for a reply you know will never come.
> >
> > This is of course what the Port Abandoned procedure is for.
> > Regrettably however, it also involves a three-day wait. :)
>
> The problem is, with separate trac and github stuff, there's now more
> friction on those tickets, and I don't think it happens very much in
> practice. Maybe part of that might be an indication that it's time to
> move the ticket system to github, and the other trac pages into a github
> wiki.
>
>
> Perry
>
>
>

Re: More classes of maintainer

[Perry E. Metzger]

On 11/1/23 21:54, Joshua Root wrote:

On 2/11/2023 12:32, Perry E. Metzger wrote:
As an aside, as it stands, the rules situation with closed maintainer 
/ open maintainer is kind of unpleasant already. For example, I'd 
like to be able to indicate that I'm happy with anyone making 
reasonable changes to my ports on their own without waiting three 
days for me, but there's no way to do that, because "open maintainer" 
really means "three day timeout" just like closed. It would be nice 
if we had some sort of larger set of gradations for what people 
prefer, from "I handle all commits on this, period" to "if you have 
commit access and want to help, don't ask, just do it."


A reasonable idea. I'd say that at some point you become less of a 
maintainer and more of an interested party, but a list of people who 
would just like to be Cc'd on the tickets and PRs for a port isn't a 
bad thing to have.


We seem to have somewhat different experiences, as the reason I 
removed openmaintainer from some of my ports was that it seemed to be 
interpreted more like "commit whatever you want without asking." So 
being able to set expectations more clearly would be nice.


For most of my stuff, I don't want to get in the way of trivial updates. 
If that just makes me an "interested party" so be it. What process would 
work here?


As another aside, we also have a ton of ghost maintainers who never 
respond but whose name being on the port means you have to 
ritualistically wait three days for a reply you know will never come.


This is of course what the Port Abandoned procedure is for. 
Regrettably however, it also involves a three-day wait. :)


The problem is, with separate trac and github stuff, there's now more 
friction on those tickets, and I don't think it happens very much in 
practice. Maybe part of that might be an indication that it's time to 
move the ticket system to github, and the other trac pages into a github 
wiki.



Perry

Re: Re: More classes of maintainer (was: Re: branch master updated: nmap: fixes for 32-bit and pre-C++11 platforms)

[Christopher A. Chavez via macports-dev]

On 11/1/23 at 9:02 PM, Eric Gallager wrote:

> I think if we add a separate "interested party" role, it would
> probably be good to change the abandonment procedure so that instead
> of removing unresponsive maintainers entirely, they'd just get moved
> to the "interested party" role instead. Sometimes reporting bugs
> against nomaintainer ports can be pretty frustrating since no one
> notices them since there's no one to cc, but with a separate
> "interested party" field there could still be someone to cc. I guess
> another way of thinking of it is separate maintainers for issues vs.
> PRs? That is, "this person can help solve bugs with this port" vs.
> "this person can make changes to this port" or something.


I have been interested in something similar. There are ports for which I would 
like to be notified of changes or issues, but I am not interested in being 
responsible for maintaining.
https://lists.macports.org/pipermail/macports-dev/2023-March/044956.html

Re: More classes of maintainer (was: Re: branch master updated: nmap: fixes for 32-bit and pre-C++11 platforms)

[Eric Gallager]

On Wed, Nov 1, 2023 at 9:54 PM Joshua Root  wrote:
>
> On 2/11/2023 12:32, Perry E. Metzger wrote:
> > As an aside, as it stands, the rules situation with closed maintainer /
> > open maintainer is kind of unpleasant already. For example, I'd like to
> > be able to indicate that I'm happy with anyone making reasonable changes
> > to my ports on their own without waiting three days for me, but there's
> > no way to do that, because "open maintainer" really means "three day
> > timeout" just like closed. It would be nice if we had some sort of
> > larger set of gradations for what people prefer, from "I handle all
> > commits on this, period" to "if you have commit access and want to help,
> > don't ask, just do it."
>
> A reasonable idea. I'd say that at some point you become less of a
> maintainer and more of an interested party, but a list of people who
> would just like to be Cc'd on the tickets and PRs for a port isn't a bad
> thing to have.
>
> We seem to have somewhat different experiences, as the reason I removed
> openmaintainer from some of my ports was that it seemed to be
> interpreted more like "commit whatever you want without asking." So
> being able to set expectations more clearly would be nice.
>
> > As another aside, we also have a ton of ghost maintainers who never
> > respond but whose name being on the port means you have to
> > ritualistically wait three days for a reply you know will never come.
>
> This is of course what the Port Abandoned procedure is for. Regrettably
> however, it also involves a three-day wait. :)
>

I think if we add a separate "interested party" role, it would
probably be good to change the abandonment procedure so that instead
of removing unresponsive maintainers entirely, they'd just get moved
to the "interested party" role instead. Sometimes reporting bugs
against nomaintainer ports can be pretty frustrating since no one
notices them since there's no one to cc, but with a separate
"interested party" field there could still be someone to cc. I guess
another way of thinking of it is separate maintainers for issues vs.
PRs? That is, "this person can help solve bugs with this port" vs.
"this person can make changes to this port" or something.

> - Josh

More classes of maintainer (was: Re: branch master updated: nmap: fixes for 32-bit and pre-C++11 platforms)

[Joshua Root]

On 2/11/2023 12:32, Perry E. Metzger wrote:
As an aside, as it stands, the rules situation with closed maintainer / 
open maintainer is kind of unpleasant already. For example, I'd like to 
be able to indicate that I'm happy with anyone making reasonable changes 
to my ports on their own without waiting three days for me, but there's 
no way to do that, because "open maintainer" really means "three day 
timeout" just like closed. It would be nice if we had some sort of 
larger set of gradations for what people prefer, from "I handle all 
commits on this, period" to "if you have commit access and want to help, 
don't ask, just do it."


A reasonable idea. I'd say that at some point you become less of a 
maintainer and more of an interested party, but a list of people who 
would just like to be Cc'd on the tickets and PRs for a port isn't a bad 
thing to have.


We seem to have somewhat different experiences, as the reason I removed 
openmaintainer from some of my ports was that it seemed to be 
interpreted more like "commit whatever you want without asking." So 
being able to set expectations more clearly would be nice.


As another aside, we also have a ton of ghost maintainers who never 
respond but whose name being on the port means you have to 
ritualistically wait three days for a reply you know will never come.


This is of course what the Port Abandoned procedure is for. Regrettably 
however, it also involves a three-day wait. :)


- Josh