Ryan Schmidt writes:
>> That sounds right. What I'm attempting to improve (or, rather, stir up
>> awareness) are the many steps that are manual. Being that stealth
>> updates are infrequent, I usually forgot to check for them. I think
>>
>> A workflow I am trying to strive for (which maybe should be another email):
>>
>> Task: update outdated ports
>>
>> $ port echo maintainer:sean | parallel --trim lr port livecheck {}
>> mercurial seems to have been updated (port version: 3.0, new version: 3.1)
>
> For this I use my portmylivecheck script:
>
> https://svn.macports.org/repository/macports/users/ryandesign/scripts/
>
>> $ port maintainerupdate mercurial
>> # this would replace the previous version string with the new one and
>> # accept the checksum changes
>
> For this I use my portcheckup script:
>
> https://svn.macports.org/repository/macports/users/ryandesign/scripts/
I have my own scripts (some based of yours) that help me but I would
suggest something more or less built-in (or at the very least installed
in /opt/local somewhere and easy to find).
I believe that would help us guide ticket reporters to take a more
active role in contributing patches.
>> $ hg ci -m "mercurial: update to 3.1"
>> $ hg push try-server
>
> If you're suggesting this just as a personal workflow for you, ok. But if
> you're suggesting this would be an infrastructure available to everyone, then
> we're either back at the old discussion of switching the MacPorts repository
> from Subversion to git or mercurial or something else, which we agreed before
> was too much effort, or we're talking about introducing a second version
> control system into the mix somehow, which sounds really confusing to me.
I mean more of a having a fleet of buildbot(-ish) servers to help
developers run a suite of tests. I personally do not have enough
machines to test every OS. I am willing to pay for some virtual private
servers but I think there would need to be some improvement of MacPorts
infrastructure to allow easy deploy on test machines.
>> # this is where a buildbot would test the change and tell me a few
>> # common issues:
>> # - was there a stealth update
>
> We could perhaps enhance the buildbot scripts to re-fetch the upstream
> distfile every time you commit the port and to let you know if its checksums
> no longer match those in the portfile. But if so, only a human can determine
> if that was because of a stealth update or because of something else. It
> feels like this would be a waste of bandwidth and server resources, however.
This would at least save you the trouble of emailing the port author.
>> # - did I "Use The Right Compiler"
>
> You can of course use the setup documented at the bottom of the
> UsingTheRightCompiler wiki page to determine this on your local machine prior
> to committing.
This is manual and therefore missed by some developers (including me
when I got a new machine).
> If you're wanting the buildbot to automate testing this for you, then I
> suppose instead of the current placeholder script that prints an error and
> exits (which can sometimes be missed because the output is discarded or
> hidden on a config.log or other log file), we could have the placeholder
> script create a log file of its own, followed by actually invoking the
> compiler so that the build succeeds anyway, then do something with the
> logfile later.
Yes, this would be a great addition. Having better output, in general,
would be helpful for tickets, too.
>> # - run "port test" (or something similar)
>
> Yup, we've discussed previously that it would be nice if tests could be
> automatically run, however many ports' tests do currently fail, and some
> others take a very very very long time.
My hope would be for these failures to get better coverage (or in some
cases not tested, e.g. ATLAS).
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
