Improvements for automated port lint
Thanks to William Siegrist for setting up the automated port lint and email following each commit! Now here's some thoughts about some problems and how they could be dealt with. * I'm worried what will happen when someone does a batch cleanup operation affecting dozens or hundreds of portfiles in a single commit. (We've had this situation in r33441, r30218, r28561, r22478, r19376, etc.) I don't want this to fire off dozens or hundreds of lint emails. A thought here is that if a single commit affects, say, more than 5 portfiles, no lint report is run and no emails are sent. Or, just one email could be sent to the committer, letting them know why lint was not run. * The subject line of the lint emails reads "[MacPorts Lint] Portfile Lint Errors for: <port>". Not all information returned by lint is an error though; some of it is just warnings. There's also a lot of words up front there in the subject that I don't need. I would change the subject to "[<rev>] <port> lint report" * Possibly obsoleting both of the above observations, what would people think about appending the port lint report to the diff email that's already generated and sent to macports-changes? I'm not sure if this is the best idea, or even possible with the diff email script we use, but the idea occurred to me so I thought I'd see what others think.
I can work on the first two points sometime this week probably. The script is in the repo also, so I'll take patches of course if someone wants something specific/quicker. On the 3rd point, the email/diff script is a 3rd-party perl module, so this would be more work. This does bring up the point I asked before (though maybe just to the MP management), do we want lint emails to go to one of the mailing lists instead of just the maintainers? -Bill On Feb 11, 2008, at 11:56 PM, Ryan Schmidt wrote:
Thanks to William Siegrist for setting up the automated port lint and email following each commit! Now here's some thoughts about some problems and how they could be dealt with.
* I'm worried what will happen when someone does a batch cleanup operation affecting dozens or hundreds of portfiles in a single commit. (We've had this situation in r33441, r30218, r28561, r22478, r19376, etc.) I don't want this to fire off dozens or hundreds of lint emails. A thought here is that if a single commit affects, say, more than 5 portfiles, no lint report is run and no emails are sent. Or, just one email could be sent to the committer, letting them know why lint was not run.
* The subject line of the lint emails reads "[MacPorts Lint] Portfile Lint Errors for: <port>". Not all information returned by lint is an error though; some of it is just warnings. There's also a lot of words up front there in the subject that I don't need. I would change the subject to "[<rev>] <port> lint report"
* Possibly obsoleting both of the above observations, what would people think about appending the port lint report to the diff email that's already generated and sent to macports-changes? I'm not sure if this is the best idea, or even possible with the diff email script we use, but the idea occurred to me so I thought I'd see what others think.
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist@apple.com 408 862 7337
On Feb 12, 2008, at 02:24, William Siegrist wrote:
On Feb 11, 2008, at 11:56 PM, Ryan Schmidt wrote:
Thanks to William Siegrist for setting up the automated port lint and email following each commit! Now here's some thoughts about some problems and how they could be dealt with.
* I'm worried what will happen when someone does a batch cleanup operation affecting dozens or hundreds of portfiles in a single commit. (We've had this situation in r33441, r30218, r28561, r22478, r19376, etc.) I don't want this to fire off dozens or hundreds of lint emails. A thought here is that if a single commit affects, say, more than 5 portfiles, no lint report is run and no emails are sent. Or, just one email could be sent to the committer, letting them know why lint was not run.
* The subject line of the lint emails reads "[MacPorts Lint] Portfile Lint Errors for: <port>". Not all information returned by lint is an error though; some of it is just warnings. There's also a lot of words up front there in the subject that I don't need. I would change the subject to "[<rev>] <port> lint report"
* Possibly obsoleting both of the above observations, what would people think about appending the port lint report to the diff email that's already generated and sent to macports-changes? I'm not sure if this is the best idea, or even possible with the diff email script we use, but the idea occurred to me so I thought I'd see what others think.
I can work on the first two points sometime this week probably. The script is in the repo also, so I'll take patches of course if someone wants something specific/quicker.
Attached should be a patch for my point #2 above. I didn't test it but it seems simple enough.
On the 3rd point, the email/diff script is a 3rd-party perl module, so this would be more work.
We're using svnnotify. I see from "svnnotify --help" that it has an option "--footer" to specify the text of a footer to append to the email. Maybe that would work?
This does bring up the point I asked before (though maybe just to the MP management), do we want lint emails to go to one of the mailing lists instead of just the maintainers?
I remember you sending me that question, and me not responding; sorry! I initially thought we shouldn't spam any of the mailing lists. Appending the lint report to the existing diff mail, though, might make sense. Then again, it might not, since the warnings and errors reported by lint may or may not have resulted from that commit. Also, it's possible (maybe even likely) that the maintainer is not subscribed to macports-changes and thus wouldn't see the lint report. However, if the maintainer doesn't care enough to be on macports-changes, maybe they don't care to see the lint reports either. Maybe it's primarily the committer who should see the lint report, and all committers are hopefully subscribed to macports-changes.
On Feb 12, 2008, at 12:59 AM, Ryan Schmidt wrote:
On Feb 12, 2008, at 02:24, William Siegrist wrote:
On Feb 11, 2008, at 11:56 PM, Ryan Schmidt wrote:
Thanks to William Siegrist for setting up the automated port lint and email following each commit! Now here's some thoughts about some problems and how they could be dealt with.
* Possibly obsoleting both of the above observations, what would people think about appending the port lint report to the diff email that's already generated and sent to macports-changes? I'm not sure if this is the best idea, or even possible with the diff email script we use, but the idea occurred to me so I thought I'd see what others think.
I can work on the first two points sometime this week probably. The script is in the repo also, so I'll take patches of course if someone wants something specific/quicker.
Attached should be a patch for my point #2 above. I didn't test it but it seems simple enough.
Thanks. The subject line is fixed.
On the 3rd point, the email/diff script is a 3rd-party perl module, so this would be more work.
We're using svnnotify. I see from "svnnotify --help" that it has an option "--footer" to specify the text of a footer to append to the email. Maybe that would work?
Good idea with --footer. There is still the problem is getting two independent post-commit processes to share data, but at least its all at the hook level and not in svnnotify internals. The way hooks are laid out for Mac OS Forge makes this tricky, so I'll try to work out a solution on the server.
This does bring up the point I asked before (though maybe just to the MP management), do we want lint emails to go to one of the mailing lists instead of just the maintainers?
I remember you sending me that question, and me not responding; sorry! I initially thought we shouldn't spam any of the mailing lists. Appending the lint report to the existing diff mail, though, might make sense. Then again, it might not, since the warnings and errors reported by lint may or may not have resulted from that commit. Also, it's possible (maybe even likely) that the maintainer is not subscribed to macports-changes and thus wouldn't see the lint report. However, if the maintainer doesn't care enough to be on macports-changes, maybe they don't care to see the lint reports either. Maybe it's primarily the committer who should see the lint report, and all committers are hopefully subscribed to macports- changes.
This reminds me... Right now the email goes to the _maintainers_, not the committer. There are cases where the committer is not a maintainer, right? We should probably add in the committer when they arent also a maintainer? -Bill ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist@apple.com 408 862 7337
On Feb 13, 2008, at 20:59, William Siegrist wrote:
On Feb 12, 2008, at 12:59 AM, Ryan Schmidt wrote:
On Feb 12, 2008, at 02:24, William Siegrist wrote:
On Feb 11, 2008, at 11:56 PM, Ryan Schmidt wrote:
Thanks to William Siegrist for setting up the automated port lint and email following each commit! Now here's some thoughts about some problems and how they could be dealt with.
* Possibly obsoleting both of the above observations, what would people think about appending the port lint report to the diff email that's already generated and sent to macports-changes? I'm not sure if this is the best idea, or even possible with the diff email script we use, but the idea occurred to me so I thought I'd see what others think.
I can work on the first two points sometime this week probably. The script is in the repo also, so I'll take patches of course if someone wants something specific/quicker.
Attached should be a patch for my point #2 above. I didn't test it but it seems simple enough.
Thanks. The subject line is fixed.
Thank you!
On the 3rd point, the email/diff script is a 3rd-party perl module, so this would be more work.
We're using svnnotify. I see from "svnnotify --help" that it has an option "--footer" to specify the text of a footer to append to the email. Maybe that would work?
Good idea with --footer. There is still the problem is getting two independent post-commit processes to share data, but at least its all at the hook level and not in svnnotify internals. The way hooks are laid out for Mac OS Forge makes this tricky, so I'll try to work out a solution on the server.
I don't know about your infrastructure, but it would seem that you would run lint for each affected portfile, get its output all together, and then pass it to the --footer switch when you call svnnotify.
This does bring up the point I asked before (though maybe just to the MP management), do we want lint emails to go to one of the mailing lists instead of just the maintainers?
I remember you sending me that question, and me not responding; sorry! I initially thought we shouldn't spam any of the mailing lists. Appending the lint report to the existing diff mail, though, might make sense. Then again, it might not, since the warnings and errors reported by lint may or may not have resulted from that commit. Also, it's possible (maybe even likely) that the maintainer is not subscribed to macports-changes and thus wouldn't see the lint report. However, if the maintainer doesn't care enough to be on macports-changes, maybe they don't care to see the lint reports either. Maybe it's primarily the committer who should see the lint report, and all committers are hopefully subscribed to macports-changes.
This reminds me... Right now the email goes to the _maintainers_, not the committer. There are cases where the committer is not a maintainer, right? We should probably add in the committer when they arent also a maintainer?
Right, sending it to the committer too was part of my initial suggestion, and I just realized when looking at the code for the first time that it doesn't do that. But if we change to appending the lint report to the changes email, then this point is moot since the changes email just goes to the changes list.
participants (2)
-
Ryan Schmidt
-
William Siegrist