Front page | perl.perl5.porters |
Postings from September 2016
* Dave Mitchell <davem@iabyn.com> [2016-09-20 14:12]:
> 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.
I had the same thought to begin with.
Then I thought on it a little further, and ended up disagreeing.
If we want MANIFEST to be sorted at all, then we should make sure that
additions to it go in the right place within the commit that adds them,
and we should avoid commits that reorder the file in bulk, because that
is the only way to minimise spurious merge conflicts on that file. Try
to rebase a branch to a new release? Here, hand-clean the MANIFEST!
But writing that down served as my talk-to-the-teddybear: it reminded me
that you can set up custom merge drivers for particular files in Git. We
could write one for MANIFEST which diffs against the base on both sides,
applies all deletions regardless of original context, de-dupes additions
from both sides, appends them all, and sorts the result. The only source
of conflicts (which it has to check for) would be if both sides happened
to add the same path but with different comments (which never happens in
practice but must be caught if it does).
But if we’re writing tooling anyway, it would not be hard to also write
some to keep the file sorted in the ordinary course of development. That
would further keep the noise in commitdiffs to a minimum.
Then we should move the test for proper sorting to the release process,
so it stops bothering vendors patching in stuff during *their* build.
The alternative to all this is to say we don’t care about the order in
MANIFEST at all, ever. Not during development, not in release tarballs,
never.
> That does however leave open the issue of whether we should still
> automatically check for correctness (i.e. that MANFEST == git ls-files).
That should stay. There should maybe even be a hook for it.
* Father Chrysostomos via RT <perlbug-followup@perl.org> [2016-09-21 18:36]:
> On Wed Sep 21 07:00:45 2016, demerphq wrote:
> > By the way there is an option available that we did not discuss. We
> > could simply make the manifest sort contingent on being in a git
> > repository with uncommitted changes to MANIFEST.
> >
> > That would make both of us happy right?
>
> Would it not still cause the problem that was the subject of this
> ticket to begin with? It seems to me that we are using fragile fixes
> to fix fragile fixes when we could just ‘not do that’ to begin with.
It seems not a fragile fix to me but exactly the right idea. Though it
could be a pre-commit hook – any time MANIFEST is dirty, just sort it
before committing it.
That would not address people who run tests prior to committing, but if
the automation takes care of this well enough that we feel free to move
the check for sortedness to the release process, they will no longer be
nagged in the first place.
* Desmond Daignault via RT <perlbug-followup@perl.org> [2016-09-21 01:48]:
> Can the MANIFEST file be sorted via a git hook?
:-)
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Thread Previous
|
Thread Next