On 20 Sep 2016 8:59 a.m., "Father Chrysostomos via RT" < perlbug-followup@perl.org> wrote: > > On Tue Sep 20 05:07:29 2016, davem wrote: > > How about we just don't bother keeping MANIFEST strictly sorted during > > development, (and so don't automatically test it for sortedness), and > > instead have it as an extra manual step in the release process ("step > > 97: > > run 'make manisort' and commit if MANIFEST has changed"). So it just > > gets > > done once per month and doesn't get in the way of everyone else. > > That makes sense. I was thinking of proposing that next if anyone objected to a simple revert of the change. I have been wondering since I started hacking on perl why we needed to keep it sorted anyway. I object to your change so long as we test for sorted manifests routinely. ☺️ As the comment shows I only made the change to eliminate manual build steps which were mandated by these tests. > The best way to solve something that shouldn’t be a problem to begin with is to remove the problem instead of working around it. That assumes there is consensus about what the problem is. Historically when these kinds of tests have generated developer frustration there has not been agreement on removing the test or changing our build process to remove the frustration. For instance I have in the past proposed much the same build test policy for porting tests as you have here without achieving consensus that it was a good idea. So when this issue came up for me I did what hackers always do and automated a solution to my frustrations. I'm sorry it caused issues, but not sorry I tried to eliminate make-work from the build process. > > That does however leave open the issue of whether we should still > > automatically check for correctness (i.e. that MANFEST == git ls- > > files). > > manifest.t should continue to perform its other tests. I think manifest.t shouldn't be an automated test. We should have a make test_porting target to run them prerelease. YvesThread Previous | Thread Next