On Thu, Dec 23, 2021 at 10:25:25PM +0100, Leon Timmermans wrote: > I can't help noticing that for many distributions it's rather unintuitive > what its upstream will be. I have the general impression that it's often a > matter of "it was orphaned, so we adopted it" more than anything else. I > don't think that state is desirable. > > I would propose that we would aim to split them on a simple question "will > most changes come from inside or outside of core". That would mean that > e.g. Devel::PPPort would stay dist/, but something like FindBin should move > to cpan/. That doesn't mean we should move all those things right away, > often we should find a reliable maintainer first. This *seems* to be what we *say* we already do. From perlhack.pod: =head2 Patching a core module This works just like patching anything else, with one extra consideration. Modules in the F<cpan/> directory of the source tree are maintained outside of the Perl core. When the author updates the module, the updates are simply copied into the core. See that module's documentation or its listing on L<https://metacpan.org/> for more information on reporting bugs and submitting patches. In most cases, patches to modules in F<cpan/> should be sent upstream and should not be applied to the Perl core individually. If a patch to a file in F<cpan/> absolutely cannot wait for the fix to be made upstream, released to CPAN and copied to blead, you must add (or update) a C<CUSTOMIZED> entry in the F<"Porting/Maintainers.pl"> file to flag that a local modification has been made. See F<"Porting/Maintainers.pl"> for more details. In contrast, modules in the F<dist/> directory are maintained in the core. ie dist: we can patch it directly in blead cpan: we should send patches upstream And making this distinction easy to see was (also) important, which was why we made the split like this. I wouldn't want to get rid of that - if we re-arrange things so that we have a directory where *some* subdirectories "shouldn't be patches" and some should, that is also hard to follow. Note, there is no reason to stick to just 3 subdirectories ext/ dist/ and cpan/ We could split dist and go 4 ways: ext: unchanged. core-only bundle: what was cpan/ dist: upstream blead, dual life cpan: blead can patch if needed I think that this layout would address both concerns. Nicholas ClarkThread Previous | Thread Next