Merge ~racb/git-ubuntu:changelog-date-parsing into git-ubuntu:master

Proposed by Robie Basak
Status: Merged
Merged at revision: 6ff151dc208809e1b8e3108c69c05090174e6221
Proposed branch: ~racb/git-ubuntu:changelog-date-parsing
Merge into: git-ubuntu:master
Diff against target: 195 lines (+135/-6)
3 files modified
gitubuntu/git_repository.py (+71/-6)
gitubuntu/git_repository_test.py (+59/-0)
gitubuntu/importer.py (+5/-0)
Reviewer Review Type Date Requested Status
Server Team CI bot continuous-integration Approve
Bryce Harrington Approve
Review via email: mp+387855@code.staging.launchpad.net

Commit message

Make Jenkins happy

To post a comment you must log in.
Revision history for this message
Robie Basak (racb) wrote :

This branch is ready except for the final commit. I don't think the assertion is correct. We might also have to ensure that CI is running in C.UTF-8 - otherwise the assertion (when fixed) will fail.

Revision history for this message
Robie Basak (racb) wrote :

Another minor issue might be that git-ubuntu.self-test will start to fail when run in a different locale. I'm not sure how this should work - ideally git-ubuntu.self-test would mainly run in the user's locale except for the changelog date parsing.

Revision history for this message
Robie Basak (racb) wrote :

Thanks to Colin in #ubuntu-devel for clarifying how it's supposed to work. I think I've now got it correct and with a force push the branch is now ready.

Revision history for this message
Server Team CI bot (server-team-bot) wrote :

PASSED: Continuous integration, rev:f5cdca0822e95d6954ffaf43db6a94819ea4bd3e
https://jenkins.ubuntu.com/server/job/git-ubuntu-ci/530/
Executed test runs:
    SUCCESS: VM Setup
    SUCCESS: Build
    SUCCESS: Unit Tests
    IN_PROGRESS: Declarative: Post Actions

Click here to trigger a rebuild:
https://jenkins.ubuntu.com/server/job/git-ubuntu-ci/530//rebuild

review: Approve (continuous-integration)
Revision history for this message
Bryce Harrington (bryce) wrote :

8d447a009bc64585603751c5ec766927cb3b565f
  - In code docs, param changelog_date_timestamp should be changelog_timestamp_string
  - strptime() throws a ValueError on parsing error. May be worth testing for in git_authorship()?

26a3f3b66b4ae429116f11f1c7c493fc4ff7fcc4
  - Looks good, a concise solution to a rather messy problem. The set of regex's provided seem to cover the various combinations, and looks easy to add more cases to.
  - In the assertion message, why is %r used ("Could not parse date %r" % changelog_timestamp_string,) ? It appears to behave properly, but I would have used %s so I'm curious.
  - Thanks for documenting the encountered cases for the invalid dates in the test case.

f5cdca0822e95d6954ffaf43db6a94819ea4bd3e
  - Setting LC_ALL also may be changing collation, which can change sorting behavior. I doubt that will be an issue at all for git-ubuntu, but if odd things start happening could look unsetting LC_ALL and instead setting LC_TIME and LC_CTYPE.
  - That aside, LGTM +1

review: Approve
Revision history for this message
Robie Basak (racb) wrote :

Thanks for the review! I've addressed your comments in a new branch, and
I'll merge that as soon as CI passes.

On Wed, Jul 22, 2020 at 04:57:12PM -0000, Bryce Harrington wrote:
> Review: Approve
>
> 8d447a009bc64585603751c5ec766927cb3b565f
> - In code docs, param changelog_date_timestamp should be changelog_timestamp_string

Fixed, thanks.

> - strptime() throws a ValueError on parsing error. May be worth testing for in git_authorship()?

I added a new test that verifies the known bad cases that should fail.

> 26a3f3b66b4ae429116f11f1c7c493fc4ff7fcc4
> - Looks good, a concise solution to a rather messy problem. The set of regex's provided seem to cover the various combinations, and looks easy to add more cases to.
> - In the assertion message, why is %r used ("Could not parse date %r" % changelog_timestamp_string,) ? It appears to behave properly, but I would have used %s so I'm curious.

%r ensures to escape things that might be awkward for the terminal. As
we're reporting something wrong, it seems more likely than average that
this might happen here - for example with control characters or similar
that might not appear in a human-readable way in logs otherwise.

> - Thanks for documenting the encountered cases for the invalid dates in the test case.
>
> f5cdca0822e95d6954ffaf43db6a94819ea4bd3e
> - Setting LC_ALL also may be changing collation, which can change sorting behavior. I doubt that will be an issue at all for git-ubuntu, but if odd things start happening could look unsetting LC_ALL and instead setting LC_TIME and LC_CTYPE.

I agree there's a risk of disrupting things here. But ultimately we
probably want stable behaviour, so I think it's better to risk this
disruption now rather than later.

Revision history for this message
Server Team CI bot (server-team-bot) wrote :

PASSED: Continuous integration, rev:6ff151dc208809e1b8e3108c69c05090174e6221
https://jenkins.ubuntu.com/server/job/git-ubuntu-ci/532/
Executed test runs:
    SUCCESS: VM Setup
    SUCCESS: Build
    SUCCESS: Unit Tests
    IN_PROGRESS: Declarative: Post Actions

Click here to trigger a rebuild:
https://jenkins.ubuntu.com/server/job/git-ubuntu-ci/532//rebuild

review: Approve (continuous-integration)

There was an error fetching revisions from git servers. Please try again in a few minutes. If the problem persists, contact Launchpad support.

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
The diff is not available at this time. You can reload the page or download it.

Subscribers

People subscribed via source and target branches