Front page | perl.perl5.porters |
Postings from January 2009
Re: Revised git related information in -v/-V output (and %Config)
Thread Previous
|
Thread Next
From:
demerphq
Date:
January 1, 2009 11:03
Subject:
Re: Revised git related information in -v/-V output (and %Config)
Message ID:
9b18b3110901011103q292d7b9du250caa7dce4a0bbc@mail.gmail.com
2009/1/1 David Golden <xdaveg@gmail.com>:
> On Thu, Jan 1, 2009 at 7:24 AM, demerphq <demerphq@gmail.com> wrote:
>>
>> Also to be clear, it wont always say "Derived from:", it could also
>> say "Local commit:", or "Commit id:", depending on whether the
>> directory is dirty, and whether the commit is local or not. The point
>> here is that it will be immediately obvious in a bug report that the
>> user has built something we "released" by merging it into the central
>> repo. "Derived from:" means "dirty working directory", "Local commit:"
>> + "Ancestor:" means an unpushed commit, and "Commit id:" means "a
>> commit on $remote/$branch (with the assumption being that this is a
>> canonical perl branch)". And actually I think p5p has to reserve the
>> right to change this output as it needs.
>
> I think it's a bad idea to have fields that sometimes appear and sometimes
> don't.
You mean "Ancestor"? Or the variable title of the second line of -V?
Ancestor is only interesting when there are unpushed commits. And is a
flag that shouts out "this is not an official perl version that can be
duplicated from a clone of perl5.git.perl.org", it should never appear
in a smoke report. Its like the optional * next to the describe in -V,
purely there as a flag to visually indicate to the developer that what
they are looking at has uncommitted changes.
Im not sure what the usefulness is of sending out report mails about
perls that include unpushed commits, which is the only time Ancestor
would ever show.
Anyone building from an unmodified rsync from the APC will always
produce a perl that includes only the "Commit id: ..." form. They
would never see "Derived from:" or "Local commit:".
> Moreover, this would seem to imply that the build system needs to be
> git-aware to know what the status us. I get what you're trying to achieve,
> but I think the mechanism you've described is clumsy and confusing. (I'll
> think more about this and reply separately.)
Ok, but im not saying that the build system HAS to be git-aware. Its
just that it is better if it is, and we want to encourage people to
use git to develop and build perl with. The case where people use a
git unaware system then presumably they are going through an rsync of
the APC or bundled release, in which case they would have a .patch
file, which is sufficient to build from.
And I'm very much hoping that redistributors do so from git, and use
git to track any changes that might make to the tree. In fact its
arguable that we should automatically include in the INSTALL data any
patches that they might have applied or made to the tree before they
do. Would make our life on p5p much easier.
Anyway, I'm looking forward to hearing any suggestions to improve things.
> One reason I want consistency between "-v" and "-V" is so that if someone
> gives their "version number" in a bug report, it doesn't matter which flag
> they used to discover it. I.e. let's make it easy for people to find the
> thing we want them to report. And let's make it easy even for new or
> infrequent perl porters to know the right way to describe or follow a
> discussion of work on some point on the source tree.
Well, thats the thing, the git-describe contains the prefix of the
commit that is included in -V, so in essence the same version info
*is* there. The -V output just contains more output, but there is
really nothing (useful) in the -v that is not in the -V.
Anyway, I guess if you really feel strongly that the git-describe
should also be include in -V we can do it. :-)
>> If people are parsing perl -V output I really wonder. Isnt it easier
>> to parse "-V:.*" instead? Whats the story there?
>>
>
> It's the usual legacy compatibility story. If someone starts CPAN Testers
> smoktesting on bleadperl, the tools include the "-V" output in the text of
> the report and central analysis of those reports depends on being able to
> parse -V.
OK. That makes sense. Perhaps if there is a module that does this then
we could add a note to the relevent build processes that patches
should be created for the module or notifications of pending changes
sent to its owner if we change -V. Then at least there would be some
kind of manageable dependency relationship so that perl5-porters isnt
constrained from changing -V layout.
>> Also, id like to point out how the output above really makes perl -v
>> and perl -V look like the header and footer of a single document, and
>> that unnecessarily duplicating information between them doesnt seem
>> right from that point of view. For instance its ok to duplicate the
>> perl version, because in the -V its split up. But in the case of a git
>> describe we wouldn't be splitting it up.
>
> I always saw them as "short version" and 'long version", myself. So I don't
> have a probem with duplication. That "-V" is explicit about "revision
> version subversion" I assume is a holdover from before we had dotted
> decimals in 5.6.0. (E.g. 5.00504 meaning "revision 5 version 5 subversion
> 4")
Sounds plausible for sure.
Happy New Year btw!
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next