Front page | perl.perl5.porters |
Postings from February 2022
On 12/24/21 00:56, Nicholas Clark wrote: > 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. > > LGTMThread Previous | Thread Next