Re: new ports and maintainer
On Aug 9, 2014, at 3:11 PM, Sean Farley s...@macports.org wrote: In fact I've proposed combining openmaintainer and nomaintainer before. But would this actually get us anything useful? For one, it would save the manual work of reminding devs that forget. For another, it would be consolidate some of the work that it takes to remind people on Trac. what? how does changing the label in the portfile do any of that? But really, it's just about cleaning up code and streamlining some of this review process for the MacPorts community. I understand you want to make the review/update process faster/easier/better - but I'm not sure if you've actually proposed anything (yet) that does any of that? -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: new ports and maintainer
Daniel J. Luke writes: On Aug 9, 2014, at 3:11 PM, Sean Farley s...@macports.org wrote: In fact I've proposed combining openmaintainer and nomaintainer before. But would this actually get us anything useful? For one, it would save the manual work of reminding devs that forget. For another, it would be consolidate some of the work that it takes to remind people on Trac. what? how does changing the label in the portfile do any of that? It saves the emailing and new commits to change openmaintainer to nomaintainer for mistakes. Furthermore, it makes removing a name from a maintainer list a simple task of search and replace, rather than figuring out if that name was the last one so nomaintainer can be added (and also checking that openmaintainer wasn't in that list). This change would be a small step in streamlining macports development. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: new ports and maintainer
On Aug 8, 2014, at 11:48 PM, Sean Farley wrote: Ryan Schmidt writes: On Aug 8, 2014, at 10:59 PM, Ryan Schmidt wrote: port echo name:^p5- and maintainer:nomaintainer How would you produce that list if nomaintainer and openmaintainer were combined into a single value? Thinking about it a bit more, I guess the answer is that it is a regular expression search so I could just anchor it to the beginning and end. Ports I am the only maintainer of: $ port echo maintainer:^ryandesign$|wc -l 357 Ports I maintain with others or openly: $ port echo maintainer:ryandesign|wc -l 908 :-) In general, these kinds of problems are a matter of implementation, not design. For instance, we could augment this language to have finer grain search operators: $ port echo maintainer:(ryandesign and not openmaintainer) That can already be done: $ port echo maintainer:ryandesign and not maintainer:openmaintainer | wc -l 369 Although that search takes a lot longer than it really should. But the issue at hand was not finding maintained ports without openmaintainer; the issue was differentiating maintained-but-open ports from unmaintained ports in a hypothetical future where we no longer use separate terms, and I used my own handle as an example. But as I said using a double-anchored regular expression would work. In fact I've proposed combining openmaintainer and nomaintainer before. But would this actually get us anything useful? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: new ports and maintainer
Ryan Schmidt writes: On Aug 8, 2014, at 11:48 PM, Sean Farley wrote: Ryan Schmidt writes: On Aug 8, 2014, at 10:59 PM, Ryan Schmidt wrote: port echo name:^p5- and maintainer:nomaintainer How would you produce that list if nomaintainer and openmaintainer were combined into a single value? Thinking about it a bit more, I guess the answer is that it is a regular expression search so I could just anchor it to the beginning and end. Ports I am the only maintainer of: $ port echo maintainer:^ryandesign$|wc -l 357 Ports I maintain with others or openly: $ port echo maintainer:ryandesign|wc -l 908 :-) In general, these kinds of problems are a matter of implementation, not design. For instance, we could augment this language to have finer grain search operators: $ port echo maintainer:(ryandesign and not openmaintainer) That can already be done: $ port echo maintainer:ryandesign and not maintainer:openmaintainer | wc -l 369 Although that search takes a lot longer than it really should. But the issue at hand was not finding maintained ports without openmaintainer; the issue was differentiating maintained-but-open ports from unmaintained ports in a hypothetical future where we no longer use separate terms, and I used my own handle as an example. But as I said using a double-anchored regular expression would work. In fact I've proposed combining openmaintainer and nomaintainer before. But would this actually get us anything useful? For one, it would save the manual work of reminding devs that forget. For another, it would be consolidate some of the work that it takes to remind people on Trac. But really, it's just about cleaning up code and streamlining some of this review process for the MacPorts community. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: new ports and maintainer
Daniel J. Luke writes: On Jul 25, 2014, at 7:21 AM, Ryan Schmidt ryandes...@macports.org wrote: On Jul 24, 2014, at 5:08 PM, Sean Farley wrote: The maintainer is supposed to hold the consolidated knowledge of that software as relates to building it within MacPorts, and may have very good reasons for why a port does or does not do something and doesn't want it changed by someone who may not be aware of all the implications. +1 for this. Especially since the maintainer has signed on to handle primary support for the port(s) she/he has agreed to maintain. Yes. Consolidated knowledge is something that is hard to manage and share. The best I've seen how other projects deal is to leave constructive and helpful comments as to why something is done the way it is. Admittedly, that is a lot of work. We do have exceptions where others may commit to non-open ports. Yes - if a port is broken (build failure, upstream security release/patch) - where the smallest reasonable change can be applied immediately (although notifying the maintainer in this case is always a good idea). If we need to change policy to make this easier (give more general exceptions, make the timeouts shorter, proactively figure out when maintainers leave, etc.) we should do so. I think this is one of two things Sean is getting at (if I understand correctly). Yes, indeed. That's something I was trying to get at. On Jul 24, 2014, at 8:06 PM, Mihai Moldovan wrote: I do not want to have to update a timestamp in every portfile periodically. That's just busywork. We have other ways to see if a maintainer is active. +1 for this too. I have at least one non-openmaintainer port that went ~9 years between upstream releases - I'm not going to remember to check in a mostly meaningless timestamp update every 6 months just to keep it non-openmaintainer. Updating some timestamp is doomed to fail. I agree we have a problem with maintainers disappearing and it taking some time for us to notice and react. But we do have a port abandonment procedure, and I would instead focus on improvements to that procedure, and better maintainer education. For example, we could improve the port abandonment procedure to include all other ports by the same maintainer; that's how I usually file the tickets anyway. +1 Yes, improving this procedure would be great and go a long ways, I think. We could mention in the guide what our expectations are when a maintainer no longer has the time or interest for maintaining. We could recommend the addition of openmaintainer when someone assumes maintainership, especially for non-committers. We could include information on how to retire in the email that management sends to approved committers. There was a recent discussion about manually sending out a maintainer survey, but it would be nice not to bother maintainers who are clearly active. We could develop an automated way to survey maintainers about their continued involvement. An automated system could estimate a maintainer's level of current involvement in the project by checking for tickets filed, commits made, mailing list posts sent, and only send such emails periodically to developers who have not been active in the last 3 months, say. A maintainer could reply to such an email to indicate whether they are still active; a no response or multiple unanswered emails could trigger the port abandonment procedure, e.g. by automatically filing a port abandonment ticket or even by automatically removing them as maintainer of their ports. I wouldn't mind responding to an email (or filling out a web form linked from an email) periodically even if there's other evidence that I'm active. How about we just have a policy (or just a community understanding) that if a developer timed out (for whatever reason) and then comes back, that he/she can re-add their name? This would be something akin to garbage collection in a programming language :-) I /think/ this addresses (or starts to address) half of what Sean is asking for. The other half seems to be distaste for trac and the current ticket workflow (and reminds me of earlier conversations about moving to github). I'm pretty indifferent to that, since I think trac works well enough for the most part and am not convinced that the effort of moving to something different will really pay off in any way. I'm pretty indifferent to it, though. Sean - did I get that right? You're suggesting that 1. Maintainer Timeout / Port abandonment procedure is too hard and takes too long and 2. trac (as currently configured) is not good enough? Yep, pretty much. It took a while (since I was traveling) to collect my thoughts on the matter and respond. One of my points is that there is no real difference between 'openmaintainer' and 'nomaintainer'. One has other devs listed, the other does not, so why not combine the names? It's easy enough to see
Re: new ports and maintainer
On Aug 8, 2014, at 9:30 AM, Sean Farley wrote: One of my points is that there is no real difference between 'openmaintainer' and 'nomaintainer'. One has other devs listed, the other does not, so why not combine the names? It's easy enough to see that if 'openmaintainer' is listed and no one else listed, then that port has no actual maintainer. It is much easier to find unmaintained ports by searching for nomaintainer. For example, as I work through the perl ports adding 5.18 and 5.20 to the supported branches, I'm beginning by working on those that are not maintained: port echo name:^p5- and maintainer:nomaintainer How would you produce that list if nomaintainer and openmaintainer were combined into a single value? My reason for working on nomaintainer ports first, before openmaintainer ports, is that openmaintainer ports are theoretically being maintained by others who might take care of the issues before I get a chance to look at them, thus saving me time. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: new ports and maintainer
On Aug 8, 2014, at 10:59 PM, Ryan Schmidt wrote: port echo name:^p5- and maintainer:nomaintainer How would you produce that list if nomaintainer and openmaintainer were combined into a single value? Thinking about it a bit more, I guess the answer is that it is a regular expression search so I could just anchor it to the beginning and end. Ports I am the only maintainer of: $ port echo maintainer:^ryandesign$|wc -l 357 Ports I maintain with others or openly: $ port echo maintainer:ryandesign|wc -l 908 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: new ports and maintainer
Ryan Schmidt writes: On Aug 8, 2014, at 10:59 PM, Ryan Schmidt wrote: port echo name:^p5- and maintainer:nomaintainer How would you produce that list if nomaintainer and openmaintainer were combined into a single value? Thinking about it a bit more, I guess the answer is that it is a regular expression search so I could just anchor it to the beginning and end. Ports I am the only maintainer of: $ port echo maintainer:^ryandesign$|wc -l 357 Ports I maintain with others or openly: $ port echo maintainer:ryandesign|wc -l 908 :-) In general, these kinds of problems are a matter of implementation, not design. For instance, we could augment this language to have finer grain search operators: $ port echo maintainer:(ryandesign and not openmaintainer) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: new ports and maintainer
On Jul 25, 2014, at 9:31 AM, Mihai Moldovan wrote: I agree we have a problem with maintainers disappearing and it taking some time for us to notice and react. But we do have a port abandonment procedure, and I would instead focus on improvements to that procedure, and better maintainer education. For example, we could improve the port abandonment procedure to include all other ports by the same maintainer; that's how I usually file the tickets anyway. We could mention in the guide what our expectations are when a maintainer no longer has the time or interest for maintaining. We could recommend the addition of openmaintainer when someone assumes maintainership, especially for non-committers. We could include information on how to retire in the email that management sends to approved committers. That's a good idea, as long as openmaintainer stays a recommendation and not a requirement. Right. I just think we got too much in the habit of encouraging new contributors to become a newly submitted port's sole maintainer, without adequately educating them about the responsibilities that entails. We should improve on that, and also encourage the addition of openmaintainer so that submitters who agree to maintain but don't stick around don't hinder us later. There was a recent discussion about manually sending out a maintainer survey, but it would be nice not to bother maintainers who are clearly active. We could develop an automated way to survey maintainers about their continued involvement. An automated system could estimate a maintainer's level of current involvement in the project by checking for tickets filed, commits made, mailing list posts sent, and only send such emails periodically to developers who have not been active in the last 3 months, say. A maintainer could reply to such an email to indicate whether they are still active; a no response or multiple unanswered emails could trigger the port abandonment procedure, e.g. by automatically filing a port abandonment ticket or even by automatically removing them as maintainer of their ports. Manually sending out mails and processing answers is not going to fly. Not with the huge maintainer list there is. Automatically determining inactive maintainers by your outlined criteria and sending out surveys on the other hand sounds good. At the same time, replies will also have to handled automated, I cannot believe one or several people could handle the burden of keeping track of answering or not answering maintainers. Compared to just updating a timestamp, this is far worse busywork. I like that idea very much though and think it's the way to go. There's just one problem with it. It sounds complicated to write scripts doing of all this. You'd have to hook into the mailing list, query the Trac database backend directly (the website has no means of searching for comments made by a specific user), keep a list of sent mails, update that on replies and decide and implement timeout measures. This probably could qualify as a GSoC project, alongside adding an option to Trac to be able to search for comments made by a specific address. Given MacPorts is understaffed as it is, I don't see something like this being implemented, up and running in just a few hours. My plan for the new web site is that in addition to a page for each port, there should be a page for each maintainer. It would include automated statistics, such as graphs of ports maintained over time, tickets filed, ticket comments, mailing list posts... For committers, it could include a graph of commits. Once the web site has this data, it could be reduced down to a single indicator of how active the contributor has been lately. We could then do things with that indicator, like sort the list of maintainers by activity, or have the web site backend send out the emails to inactive contributors, store the results, display them on the site too... ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: new ports and maintainer
On Jul 25, 2014, at 9:52 AM, Frank Schima m...@macports.org wrote: We definitely need a better process for determining which maintainers are inactive. That was the basis of my idea of a short and simple mass email. I suspect we have lots of dead email addresses which will be easy to remove. Even if that alone could somehow be determined such as by examining the mail logs somehow, it would be very helpful. Shree, Will, is this possible? +1 Temporary email delivery failures should be considered. A monthly maintenance script where 3 consecutive failures triggers maintainer drop seems reasonable. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: new ports and maintainer
On Jul 24, 2014, at 5:08 PM, Sean Farley wrote: Yes, so why have the exclusivity? The maintainer is supposed to hold the consolidated knowledge of that software as relates to building it within MacPorts, and may have very good reasons for why a port does or does not do something and doesn't want it changed by someone who may not be aware of all the implications. For example, I've received numerous requests to reinstate the hdri option for the ImageMagick port, but we *cannot* add that option without breaking binary compatibility, which is why the option was removed and will not be re-added until some future major restructuring of ImageMagick into separate subports for such ABI-changing options. Also, some ports are very important, because they are depended on by lots of other ports; I don't want an inexperienced developer committing an incompletely-considered change to e.g. gettext that breaks half of MacPorts. We do have exceptions where others may commit to non-open ports. For example, I updated libgcrypt to 1.6.1 recently, which changed the library version, so it was my job to also revbump of all dependent ports so that they would not be broken. In some cases, this involved also having to update a dependent to a newer version or apply a patch to ensure continued successful building. If I had to update a port's version I would probably want to have maintainer approval first; IIRC the only ports I updated in this case were mine or nomaintainer. On Jul 24, 2014, at 8:06 PM, Mihai Moldovan wrote: However, non-openmaintainer ports are required to insert a comment in the Portfile, reading something along those lines: # TIMESTAMP: openmaintainer prohibited. TIMESTAMP could be something like 20140725. A script could periodically go through all Portfiles and examine them regarding this comment. If the timestamp is, say, older than six months, it is removed and openmaintainer forcefully added. Port maintainers are required to increase the timestamp on each change (or at least often enough to prevent escalation to openmaintainer. I don't literally mean each change. For rarely updated ports, it will effectively be on each change.) I do not want to have to update a timestamp in every portfile periodically. That's just busywork. We have other ways to see if a maintainer is active. I agree we have a problem with maintainers disappearing and it taking some time for us to notice and react. But we do have a port abandonment procedure, and I would instead focus on improvements to that procedure, and better maintainer education. For example, we could improve the port abandonment procedure to include all other ports by the same maintainer; that's how I usually file the tickets anyway. We could mention in the guide what our expectations are when a maintainer no longer has the time or interest for maintaining. We could recommend the addition of openmaintainer when someone assumes maintainership, especially for non-committers. We could include information on how to retire in the email that management sends to approved committers. There was a recent discussion about manually sending out a maintainer survey, but it would be nice not to bother maintainers who are clearly active. We could develop an automated way to survey maintainers about their continued involvement. An automated system could estimate a maintainer's level of current involvement in the project by checking for tickets filed, commits made, mailing list posts sent, and only send such emails periodically to developers who have not been active in the last 3 months, say. A maintainer could reply to such an email to indicate whether they are still active; a no response or multiple unanswered emails could trigger the port abandonment procedure, e.g. by automatically filing a port abandonment ticket or even by automatically removing them as maintainer of their ports. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: new ports and maintainer
On Jul 25, 2014, at 7:21 AM, Ryan Schmidt ryandes...@macports.org wrote: On Jul 24, 2014, at 5:08 PM, Sean Farley wrote: The maintainer is supposed to hold the consolidated knowledge of that software as relates to building it within MacPorts, and may have very good reasons for why a port does or does not do something and doesn't want it changed by someone who may not be aware of all the implications. +1 for this. Especially since the maintainer has signed on to handle primary support for the port(s) she/he has agreed to maintain. We do have exceptions where others may commit to non-open ports. Yes - if a port is broken (build failure, upstream security release/patch) - where the smallest reasonable change can be applied immediately (although notifying the maintainer in this case is always a good idea). If we need to change policy to make this easier (give more general exceptions, make the timeouts shorter, proactively figure out when maintainers leave, etc.) we should do so. I think this is one of two things Sean is getting at (if I understand correctly). On Jul 24, 2014, at 8:06 PM, Mihai Moldovan wrote: I do not want to have to update a timestamp in every portfile periodically. That's just busywork. We have other ways to see if a maintainer is active. +1 for this too. I have at least one non-openmaintainer port that went ~9 years between upstream releases - I'm not going to remember to check in a mostly meaningless timestamp update every 6 months just to keep it non-openmaintainer. I agree we have a problem with maintainers disappearing and it taking some time for us to notice and react. But we do have a port abandonment procedure, and I would instead focus on improvements to that procedure, and better maintainer education. For example, we could improve the port abandonment procedure to include all other ports by the same maintainer; that's how I usually file the tickets anyway. +1 We could mention in the guide what our expectations are when a maintainer no longer has the time or interest for maintaining. We could recommend the addition of openmaintainer when someone assumes maintainership, especially for non-committers. We could include information on how to retire in the email that management sends to approved committers. There was a recent discussion about manually sending out a maintainer survey, but it would be nice not to bother maintainers who are clearly active. We could develop an automated way to survey maintainers about their continued involvement. An automated system could estimate a maintainer's level of current involvement in the project by checking for tickets filed, commits made, mailing list posts sent, and only send such emails periodically to developers who have not been active in the last 3 months, say. A maintainer could reply to such an email to indicate whether they are still active; a no response or multiple unanswered emails could trigger the port abandonment procedure, e.g. by automatically filing a port abandonment ticket or even by automatically removing them as maintainer of their ports. I wouldn't mind responding to an email (or filling out a web form linked from an email) periodically even if there's other evidence that I'm active. I /think/ this addresses (or starts to address) half of what Sean is asking for. The other half seems to be distaste for trac and the current ticket workflow (and reminds me of earlier conversations about moving to github). I'm pretty indifferent to that, since I think trac works well enough for the most part and am not convinced that the effort of moving to something different will really pay off in any way. I'm pretty indifferent to it, though. Sean - did I get that right? You're suggesting that 1. Maintainer Timeout / Port abandonment procedure is too hard and takes too long and 2. trac (as currently configured) is not good enough? -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: new ports and maintainer
* On 25.07.2014 01:21 pm, Ryan Schmidt wrote: On Jul 24, 2014, at 8:06 PM, Mihai Moldovan wrote: [...] # TIMESTAMP: openmaintainer prohibited. [...] I do not want to have to update a timestamp in every portfile periodically. That's just busywork. We have other ways to see if a maintainer is active. * On 25.07.2014 03:50 pm, Daniel J. Luke wrote: +1 for this too. I have at least one non-openmaintainer port that went ~9 years between upstream releases - I'm not going to remember to check in a mostly meaningless timestamp update every 6 months just to keep it non-openmaintainer. It is busywork. However, I find it very unlikely that a port doesn't get changed at least once every 6 months. Maybe not for updates, but because dependencies require a revision bump, a new OS version came out requiring a quick fix, or just because base evolved. I agree we have a problem with maintainers disappearing and it taking some time for us to notice and react. But we do have a port abandonment procedure, and I would instead focus on improvements to that procedure, and better maintainer education. For example, we could improve the port abandonment procedure to include all other ports by the same maintainer; that's how I usually file the tickets anyway. We could mention in the guide what our expectations are when a maintainer no longer has the time or interest for maintaining. We could recommend the addition of openmaintainer when someone assumes maintainership, especially for non-committers. We could include information on how to retire in the email that management sends to approved committers. That's a good idea, as long as openmaintainer stays a recommendation and not a requirement. There was a recent discussion about manually sending out a maintainer survey, but it would be nice not to bother maintainers who are clearly active. We could develop an automated way to survey maintainers about their continued involvement. An automated system could estimate a maintainer's level of current involvement in the project by checking for tickets filed, commits made, mailing list posts sent, and only send such emails periodically to developers who have not been active in the last 3 months, say. A maintainer could reply to such an email to indicate whether they are still active; a no response or multiple unanswered emails could trigger the port abandonment procedure, e.g. by automatically filing a port abandonment ticket or even by automatically removing them as maintainer of their ports. Manually sending out mails and processing answers is not going to fly. Not with the huge maintainer list there is. Automatically determining inactive maintainers by your outlined criteria and sending out surveys on the other hand sounds good. At the same time, replies will also have to handled automated, I cannot believe one or several people could handle the burden of keeping track of answering or not answering maintainers. Compared to just updating a timestamp, this is far worse busywork. I like that idea very much though and think it's the way to go. There's just one problem with it. It sounds complicated to write scripts doing of all this. You'd have to hook into the mailing list, query the Trac database backend directly (the website has no means of searching for comments made by a specific user), keep a list of sent mails, update that on replies and decide and implement timeout measures. This probably could qualify as a GSoC project, alongside adding an option to Trac to be able to search for comments made by a specific address. Given MacPorts is understaffed as it is, I don't see something like this being implemented, up and running in just a few hours. Mihai smime.p7s Description: S/MIME Cryptographic Signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: new ports and maintainer
On Jul 25, 2014, at 10:31 AM, Mihai Moldovan io...@ionic.de wrote: * On 25.07.2014 03:50 pm, Daniel J. Luke wrote: +1 for this too. I have at least one non-openmaintainer port that went ~9 years between upstream releases - I'm not going to remember to check in a mostly meaningless timestamp update every 6 months just to keep it non-openmaintainer. It is busywork. However, I find it very unlikely that a port doesn't get changed at least once every 6 months. Maybe not for updates, but because dependencies require a revision bump, a new OS version came out requiring a quick fix, or just because base evolved. this is something we could mine our subversion repo to see if it's true or not (or how true it is). -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: new ports and maintainer
On Jul 25, 2014, at 5:21 AM, Ryan Schmidt ryandes...@macports.org wrote: On Jul 24, 2014, at 8:06 PM, Mihai Moldovan wrote: However, non-openmaintainer ports are required to insert a comment in the Portfile, reading something along those lines: # TIMESTAMP: openmaintainer prohibited. TIMESTAMP could be something like 20140725. A script could periodically go through all Portfiles and examine them regarding this comment. If the timestamp is, say, older than six months, it is removed and openmaintainer forcefully added. Port maintainers are required to increase the timestamp on each change (or at least often enough to prevent escalation to openmaintainer. I don't literally mean each change. For rarely updated ports, it will effectively be on each change.) I do not want to have to update a timestamp in every portfile periodically. That's just busywork. We have other ways to see if a maintainer is active. I agree we have a problem with maintainers disappearing and it taking some time for us to notice and react. But we do have a port abandonment procedure, and I would instead focus on improvements to that procedure, and better maintainer education. For example, we could improve the port abandonment procedure to include all other ports by the same maintainer; that's how I usually file the tickets anyway. We could mention in the guide what our expectations are when a maintainer no longer has the time or interest for maintaining. We could recommend the addition of openmaintainer when someone assumes maintainership, especially for non-committers. We could include information on how to retire in the email that management sends to approved committers. There was a recent discussion about manually sending out a maintainer survey, but it would be nice not to bother maintainers who are clearly active. We could develop an automated way to survey maintainers about their continued involvement. An automated system could estimate a maintainer's level of current involvement in the project by checking for tickets filed, commits made, mailing list posts sent, and only send such emails periodically to developers who have not been active in the last 3 months, say. A maintainer could reply to such an email to indicate whether they are still active; a no response or multiple unanswered emails could trigger the port abandonment procedure, e.g. by automatically filing a port abandonment ticket or even by automatically removing them as maintainer of their ports. We definitely need a better process for determining which maintainers are inactive. That was the basis of my idea of a short and simple mass email. I suspect we have lots of dead email addresses which will be easy to remove. Even if that alone could somehow be determined such as by examining the mail logs somehow, it would be very helpful. Shree, Will, is this possible? Cheers! -Frank ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: new ports and maintainer
* On 25.07.2014 04:55 pm, Daniel J. Luke wrote:
On Jul 25, 2014, at 10:31 AM, Mihai Moldovan io...@ionic.de wrote:
It is busywork. However, I find it very unlikely that a port doesn't get
changed at least once every 6 months. Maybe not for updates, but because
dependencies require a revision bump, a new OS version came out requiring a
quick fix, or just because base evolved.
this is something we could mine our subversion repo to see if it's true or
not (or how true it is).
Out of 9694 Portfiles total:
root@nopileos~# find
/opt/local/var/macports/sources/macports.rsync.ionic.de/release/ports/ -iname
Portfile -exec zsh -c 'i={}; PORT=${i%%/Portfile}; PORT=${PORT##*/};
DATETIME=$(grep ^#.*Id: Portfile.* ${i} | cut -d -f 5); YEAR=$(cut -d
- -f 1 $DATETIME); MONTH=$(cut -d - -f 2 $DATETIME); [[
$YEAR -lt 2014 ]] { echo ${PORT}: ${YEAR} ${MONTH} } || { [[ $MONTH
-lt 2 ]] echo ${PORT}: ${YEAR} ${MONTH} }' \;
| wc -l
7369
Thus, most of them haven't been updated within 6 months. My estimation seems to
have been way off.
Mihai
smime.p7s
Description: S/MIME Cryptographic Signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
new ports and maintainer
Hi all, I am wondering if there is a well defined policy regarding maintainer ship for new ports. I understand that it is quite usual to assume maintainer ship when contributing a new port and that nomantainer is more usual for abandoned ports. But is it usual to commit new ports as with `nomaintainer` as well, or should this be avoided? What to do with ports where the contributor does not assume maintainership? Any thoughts? Thanks! ~petr ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: new ports and maintainer
On 7/24/14 4:25 AM, p...@macports.org wrote: Hi all, I am wondering if there is a well defined policy regarding maintainer ship for new ports. I understand that it is quite usual to assume maintainer ship when contributing a new port and that nomantainer is more usual for abandoned ports. But is it usual to commit new ports as with `nomaintainer` as well, or should this be avoided? What to do with ports where the contributor does not assume maintainership? Any thoughts? Thanks! ~petr _ This is done from time to time but my thoughts are that if you are going to create a port and submit it you should also be willing to maintain it. Many other distributions would not accept a port on such a basis or drop it if no one was willing to maintain it. MacPorts is more permissive. Again these are my thoughts as you requested not necessarily a statement of MacPorts policy. Dave Evans ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: new ports and maintainer
David Evans writes: On 7/24/14 4:25 AM, p...@macports.org wrote: Hi all, I am wondering if there is a well defined policy regarding maintainer ship for new ports. I understand that it is quite usual to assume maintainer ship when contributing a new port and that nomantainer is more usual for abandoned ports. But is it usual to commit new ports as with `nomaintainer` as well, or should this be avoided? What to do with ports where the contributor does not assume maintainership? Any thoughts? Thanks! ~petr _ This is done from time to time but my thoughts are that if you are going to create a port and submit it you should also be willing to maintain it. Many other distributions would not accept a port on such a basis or drop it if no one was willing to maintain it. MacPorts is more permissive. Again these are my thoughts as you requested not necessarily a statement of MacPorts policy. I've been thinking about this and sometimes I wonder why we even have 'openmaintainer'? I mean, it seems like a huge I/O block because the waiting 72 hours turns into forgetting the ticket for a few weeks. Why not drop 'openmaintainer' and amend the community policy to have every port be what we now call 'openmaintainer'? Furthermore, we could set up a way for the listed port authors to be emailed when a port with their name on it has changed. Also, can we get tickets to be automatically closed when the commit message says closes #1234? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: new ports and maintainer
On Jul 24, 2014, at 2:37 PM, Sean Farley s...@macports.org wrote: Why not drop 'openmaintainer' and amend the community policy to have every port be what we now call 'openmaintainer'? Furthermore, we could set up a way for the listed port authors to be emailed when a port with their name on it has changed. I, for one, appreciate the ability to specify which ports I don't care if people apply patches to vs. ports where I'm very careful about updating/keeping things from breaking. Ultimately, I'm not willing to provide active support for something that lots of other people are going to (potentially) be updating (and, in general, I prefer to get prior notice of a possible change before it hits the repo). -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: new ports and maintainer
A compromise here could be, instead of getting rid of openmaintainer entirely, or keeping it opt-in like it currently is, we could make it opt-out instead. There are two ways we could do this: 1. When committing new ports submitted by users without commit access, make it a policy to automatically add openmaintainer for them unless they specifically request otherwise, or: 2. Get rid of the openmaintainer pseudo-maintainername entirely, and replace it with a new pseudo-maintainername that would be equivalent to what is currently signified by leaving out the openmaintainer pseudo-maintainername. I am not sure what we would call this replacement though... On Thu, Jul 24, 2014 at 3:13 PM, Daniel J. Luke dl...@geeklair.net wrote: On Jul 24, 2014, at 2:37 PM, Sean Farley s...@macports.org wrote: Why not drop 'openmaintainer' and amend the community policy to have every port be what we now call 'openmaintainer'? Furthermore, we could set up a way for the listed port authors to be emailed when a port with their name on it has changed. I, for one, appreciate the ability to specify which ports I don't care if people apply patches to vs. ports where I'm very careful about updating/keeping things from breaking. Ultimately, I'm not willing to provide active support for something that lots of other people are going to (potentially) be updating (and, in general, I prefer to get prior notice of a possible change before it hits the repo). -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: new ports and maintainer
Daniel J. Luke writes: On Jul 24, 2014, at 2:37 PM, Sean Farley s...@macports.org wrote: Why not drop 'openmaintainer' and amend the community policy to have every port be what we now call 'openmaintainer'? Furthermore, we could set up a way for the listed port authors to be emailed when a port with their name on it has changed. I, for one, appreciate the ability to specify which ports I don't care if people apply patches to vs. ports where I'm very careful about updating/keeping things from breaking. Well, the problem is people still commit on your ports. Unless you've left comments in your portfiles, then there's no auditable way to maintain your ports if, say, you stop being a maintainer. I would instead like to encourage better practices rather than don't touch my port which, I believe, leads to bottlenecks for fixing tickets. Ultimately, I'm not willing to provide active support for something that lots of other people are going to (potentially) be updating (and, in general, I prefer to get prior notice of a possible change before it hits the repo). Ideally, we'd have a pull request or code review model where you (and whomever else is listed in the portfile) would be notify to review. This is kind of what Ryan and other core devs try to do by reviewing the mailing list of changes but would now allow them (and other reviewers) to stop before a change is integrated. Honestly, I think you'd be better served by having a comment say please run changes past email address / macports-dev before committing. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: new ports and maintainer
On Jul 24, 2014, at 4:55 PM, Sean Farley s...@macports.org wrote: I, for one, appreciate the ability to specify which ports I don't care if people apply patches to vs. ports where I'm very careful about updating/keeping things from breaking. Well, the problem is people still commit on your ports. they do? I've found that it's very rare that someone touches my non-openmaintainer port(s) Unless you've left comments in your portfiles, then there's no auditable way to maintain your ports if, say, you stop being a maintainer. I can't parse this sentence. no auditable way what are you auditing? it's worth nothing that the complexity of an individual portfile is generally pretty low (as it should be). I would instead like to encourage better practices rather than don't touch my port which, I believe, leads to bottlenecks for fixing tickets. this isn't something we have to rely on 'belief' for - we could actually measure response time on tickets. I would suspect that there are easier ways to fix the problem you're outlining (maintainer timeout) without having to go so far as to say no more exclusive maintainer Ultimately, I'm not willing to provide active support for something that lots of other people are going to (potentially) be updating (and, in general, I prefer to get prior notice of a possible change before it hits the repo). Ideally, we'd have a pull request or code review model where you (and whomever else is listed in the portfile) would be notify to review. um, that's how non-openmaintainer ports work. You open a ticket (with a patch) assigned to the maintainer who then reviews it before it's committed. This is kind of what Ryan and other core devs try to do by reviewing the mailing list of changes but would now allow them (and other reviewers) to stop before a change is integrated. which is the opposite of just letting anyone with commit access commit changes (which is what openmaintainer says). Honestly, I think you'd be better served by having a comment say please run changes past email address / macports-dev before committing. and again, that's how non-openmaintainer ports work (ie, if you email me a diff/patch/change for subversion - I'll review it and either apply it, modify it and apply it, tell you to apply it, or discuss why we may not want to apply it as-is ... I follow the same process if you open a ticket and assign it to me, which is better since it's stored where others can see it). -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: new ports and maintainer
* On 24.07.2014 11:49 pm, Daniel J. Luke wrote: Unless you've left comments in your portfiles, then there's no auditable way to maintain your ports if, say, you stop being a maintainer. I can't parse this sentence. no auditable way what are you auditing? Don't nitpick. :) He means that there is no reliable way to determine whether a maintainer has stopped contributing or is just taking a break for a week or two or ... I would instead like to encourage better practices rather than don't touch my port which, I believe, leads to bottlenecks for fixing tickets. this isn't something we have to rely on 'belief' for - we could actually measure response time on tickets. I would suspect that there are easier ways to fix the problem you're outlining (maintainer timeout) without having to go so far as to say no more exclusive maintainer Unless you want to implement functionality like that in Trac, which probably is very painful to integrate anyway, there really isn't no good way of measuring maintainer response. That's what Sean is aiming at and he's right, to my mind. Ultimately, I'm not willing to provide active support for something that lots of other people are going to (potentially) be updating (and, in general, I prefer to get prior notice of a possible change before it hits the repo). Ideally, we'd have a pull request or code review model where you (and whomever else is listed in the portfile) would be notify to review. um, that's how non-openmaintainer ports work. You open a ticket (with a patch) assigned to the maintainer who then reviews it before it's committed. Pretend the maintainer(s) stopped doing work and even checking mail. Waiting for a timeout unnecessarily prolongs the fixing period. I'd prefer just force-pushing the change, even if the port is non-openmaintainer. Honestly, I think you'd be better served by having a comment say please run changes past email address / macports-dev before committing. Actually, this spawned another idea in my head. What about this: we keep openmaintainer and its absence as-is. However, non-openmaintainer ports are required to insert a comment in the Portfile, reading something along those lines: # TIMESTAMP: openmaintainer prohibited. TIMESTAMP could be something like 20140725. A script could periodically go through all Portfiles and examine them regarding this comment. If the timestamp is, say, older than six months, it is removed and openmaintainer forcefully added. Port maintainers are required to increase the timestamp on each change (or at least often enough to prevent escalation to openmaintainer. I don't literally mean each change. For rarely updated ports, it will effectively be on each change.) Even if bumping is forgotten, no harm done, anyway. The change is easily revertible. What do you guys think? Mihai smime.p7s Description: S/MIME Cryptographic Signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: new ports and maintainer
Daniel J. Luke writes: On Jul 24, 2014, at 4:55 PM, Sean Farley s...@macports.org wrote: I, for one, appreciate the ability to specify which ports I don't care if people apply patches to vs. ports where I'm very careful about updating/keeping things from breaking. Well, the problem is people still commit on your ports. they do? I've seen it happen here on the mailing list. I've found that it's very rare that someone touches my non-openmaintainer port(s) Unless you've left comments in your portfiles, then there's no auditable way to maintain your ports if, say, you stop being a maintainer. I can't parse this sentence. no auditable way what are you auditing? In this sense, I meant auditing to just be port maintenance without having access to inside your thoughts. it's worth nothing that the complexity of an individual portfile is generally pretty low (as it should be). Yes, so why have the exclusivity? I would instead like to encourage better practices rather than don't touch my port which, I believe, leads to bottlenecks for fixing tickets. this isn't something we have to rely on 'belief' for - we could actually measure response time on tickets. I would suspect that there are easier ways to fix the problem you're outlining (maintainer timeout) without having to go so far as to say no more exclusive maintainer Possibly but exclusivity for portfiles doesn't help people get involved with learning how to maintain other ports. Ultimately, I'm not willing to provide active support for something that lots of other people are going to (potentially) be updating (and, in general, I prefer to get prior notice of a possible change before it hits the repo). Ideally, we'd have a pull request or code review model where you (and whomever else is listed in the portfile) would be notify to review. um, that's how non-openmaintainer ports work. Not in general, no. How many times has someone done a search-and-replace and notified others beforehand? I've seen it maybe once or twice, tops. You open a ticket (with a patch) assigned to the maintainer who then reviews it before it's committed. If trac were integrated to work closer with the repository, I'd be inclined to drop this point, but it's not. Getting patches through the browser or some random script is a pain, at best. The worst part is that you get one giant diff instead of seeing the commit history. This is kind of what Ryan and other core devs try to do by reviewing the mailing list of changes but would now allow them (and other reviewers) to stop before a change is integrated. which is the opposite of just letting anyone with commit access commit changes (which is what openmaintainer says). Yes, I was proposing a pull-request model (just as an example, though) where there would be a small number of integrators. Honestly, I think you'd be better served by having a comment say please run changes past email address / macports-dev before committing. and again, that's how non-openmaintainer ports work (ie, if you email me a diff/patch/change for subversion - I'll review it and either apply it, modify it and apply it, tell you to apply it, or discuss why we may not want to apply it as-is ... I follow the same process if you open a ticket and assign it to me, which is better since it's stored where others can see it). What I'm trying to do is develop a way to encourage more involvement. So, instead of engaging a macports devevloper separately, the whole community can be involved. I think however you slice this, openmaintainer is not needed. Either there are no other reviewers (nomaintainer ... would we really need to list this?) or there are others to ping. It would a long ways (a really, really longs way) if trac were better at code review, automatically assigning reviewers to an issue, and automatically closing tickets. But these are worthy of their own thread of discussion. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: new ports and maintainer
Mihai Moldovan writes: * On 24.07.2014 11:49 pm, Daniel J. Luke wrote: Unless you've left comments in your portfiles, then there's no auditable way to maintain your ports if, say, you stop being a maintainer. I can't parse this sentence. no auditable way what are you auditing? Don't nitpick. :) He means that there is no reliable way to determine whether a maintainer has stopped contributing or is just taking a break for a week or two or ... Yes, thank you. I would instead like to encourage better practices rather than don't touch my port which, I believe, leads to bottlenecks for fixing tickets. this isn't something we have to rely on 'belief' for - we could actually measure response time on tickets. I would suspect that there are easier ways to fix the problem you're outlining (maintainer timeout) without having to go so far as to say no more exclusive maintainer Unless you want to implement functionality like that in Trac, which probably is very painful to integrate anyway, there really isn't no good way of measuring maintainer response. I will comment again that Trac is a big pain and it seems that most the work involved in the macports community goes into the same tedious tasks: - correct the 'owned by' field of a ticket - correct the CCs - tell the user to upload log files - tell the user to upload a unified diff - fix formatting - periodically go through and close tickets That's what Sean is aiming at and he's right, to my mind. :-) Ultimately, I'm not willing to provide active support for something that lots of other people are going to (potentially) be updating (and, in general, I prefer to get prior notice of a possible change before it hits the repo). Ideally, we'd have a pull request or code review model where you (and whomever else is listed in the portfile) would be notify to review. um, that's how non-openmaintainer ports work. You open a ticket (with a patch) assigned to the maintainer who then reviews it before it's committed. Pretend the maintainer(s) stopped doing work and even checking mail. Waiting for a timeout unnecessarily prolongs the fixing period. I'd prefer just force-pushing the change, even if the port is non-openmaintainer. Honestly, I think you'd be better served by having a comment say please run changes past email address / macports-dev before committing. Actually, this spawned another idea in my head. What about this: we keep openmaintainer and its absence as-is. However, non-openmaintainer ports are required to insert a comment in the Portfile, reading something along those lines: # TIMESTAMP: openmaintainer prohibited. TIMESTAMP could be something like 20140725. A script could periodically go through all Portfiles and examine them regarding this comment. If the timestamp is, say, older than six months, it is removed and openmaintainer forcefully added. Port maintainers are required to increase the timestamp on each change (or at least often enough to prevent escalation to openmaintainer. I don't literally mean each change. For rarely updated ports, it will effectively be on each change.) Even if bumping is forgotten, no harm done, anyway. The change is easily revertible. What do you guys think? This is one possible way to do it. I would add that 'openmaintainer' really isn't needed. Either the portfile has a '# TIMESTAMP: due to reason (hopefully link to an issue)' or it doesn't. Honestly, I think we just need a better code review process instead of creating fiefdoms for the portfiles. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
