Removing "$Id$" lines
David Evans
devans at macports.org
Tue Nov 1 21:07:07 PDT 2016
On 11/1/16 4:06 PM, Ryan Schmidt wrote:
> Off list, Larry likened removing $Id$ lines to adding modelines, which we also haven't globally done to all Portfiles yet. But it's not really the same thing. Adding modelines needs to be done on a case by case basis. For example, if a Portfile currently uses tabs, then just adding the modeline that states spaces are used would be inaccurate. The person adding the modeline should also be converting the tabs to spaces at the same time.
>
> Removing the $Id$ line, by contrast, requires no other actions. I have no objection to removing them all at once, and agree that if we make sure the buildbot is already busy with some time consuming builds at the time that we push that change, we can cancel the applicable portwatcher build before it gets around to scheduling the tens of thousands of portbuilder builds.
>
> On the other hand, we do want to eventually build all ports on all builders, both to build ports on the new builders that have never been built before, and to catch up on some builds on the existing builders that may have been missed; committing the change to remove the $Id$ line would be one way to accomplish that. But to ensure that doesn't take longer than it needs to, I want to switch from SQLite to PostgreSQL, and implement the successcache, before doing that.
>
> Removing the $Id$ lines is not critical. There are other time-critical matters of migrating off of macOS forge that still need to be accomplished in the next two weeks that we should focus on instead.
>
> In the mean time, feel free to remove the $Id$ lines from your ports as you update them, or do nothing with the $Id$ lines until we've figured out what to do.
>
Although it's not a big deal, the current stable version of MacPorts will give a lint error if the $Id$ line is removed
but the version in git master has been already fixed to give an error if it exists. So perhaps a logical point for
doing a mass replace is when 2.3.5 is released. From recemt activity, I assume that's not too far down the line but far
enough to allow for the appropriate preparations.
Another reason for not canceling such a build would be to generate a record of how many ports and which ones are
currently broken. I suspect there are a number that never get reported because they are old or obscure or just not used
very much.
Dave
More information about the macports-dev
mailing list