Re: More classes of maintainer

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

Re: More classes of maintainer

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

Re: More classes of maintainer

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

Re: More classes of maintainer

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 als

Re: More classes of maintainer

[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

Re: More classes of maintainer

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 awa

Re: More classes of maintainer

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 T

Re: More classes of maintainer

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 getti

Re: More classes of maintainer

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

Re: More classes of maintainer

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 ju

Re: More classes of maintainer

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

Re: More classes of maintainer

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.

Re: More classes of maintainer

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:

Re: More classes of maintainer

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 perceptio

Re: More classes of maintainer

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,

Re: More classes of maintainer

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

Re: More classes of maintainer

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 f

Re: More classes of maintainer

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

Re: More classes of maintainer

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 cha

Re: More classes of maintainer

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 wa

Re: More classes of maintainer

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

Re: More classes of maintainer

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

Re: More classes of maintainer

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 ch

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

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

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

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 anyo

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

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 w