issue_comments

Table actions

2 rows where author_association = "CONTRIBUTOR", issue = 287852184 and user = 12229877 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: created_at (date), updated_at (date)

user 1

  • Zac-HD · 2 ✖

issue 1

  • v0.10.1 Release · 2 ✖

author_association 1

  • CONTRIBUTOR · 2 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
368686954 https://github.com/pydata/xarray/issues/1821#issuecomment-368686954 https://api.github.com/repos/pydata/xarray/issues/1821 MDEyOklzc3VlQ29tbWVudDM2ODY4Njk1NA== Zac-HD 12229877 2018-02-26T23:20:45Z 2018-02-26T23:20:45Z CONTRIBUTOR

First: thanks, everyone, for such a prompt and helpful response! I'm excited both to have 10.1 (:tada:), and by the prospect of faster/automated releases in future.

Reading over the releasing instructions, I think there are three parts we need to work on to go fully automated. By fully automated, I mean "no maintainer action whatsoever beyond merging pulls, which are not release-specific":

  • Most things can be automated with continuous deployment scripts like Hypothesis'. We deploy a patch or minor release for every pull request, but if that's undesirable you could run the deployment from a weekly "cron" job on Travis.
  • Changelog management (for weekly rather than per-PR releases) can be automated with https://github.com/hawkowl/towncrier - there's a substitute for all of us :smile:
  • Xarray would need some novel scripts for uploading Github releases and driving the conda-forge feedstock. (Which Hypothesis would borrow in turn - it's lower priority for us but still nice to have)

In short, my advice is to be creative, and if release processes can't be automated - change them!

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   v0.10.1 Release 287852184
368303298 https://github.com/pydata/xarray/issues/1821#issuecomment-368303298 https://api.github.com/repos/pydata/xarray/issues/1821 MDEyOklzc3VlQ29tbWVudDM2ODMwMzI5OA== Zac-HD 12229877 2018-02-25T11:55:31Z 2018-02-25T11:55:31Z CONTRIBUTOR

@jhamman & @shoyer - I think Xarray has a release frequency problem.

  • 1782 has been merged, but I still can't plot timeseries with an all-nan step

  • 1796, #1819, and #1893 have been merged - but I still can't plot RGB images

  • 1840 has been merged - but loading CF-int-encoded data still uses double the memory it needs.

  • All of these daily tasks for myself and my colleagues are harder than they should be.

It's been more than three months now without a patch release. This is really, really frustrating as an Xarray contributor, user, and advocate - getting my work merged upstream literally isn't worth anything until it's released, my colleagues have trouble using it (and go back to Matlab or IDL!), and it's harder to ask for anything in meetings with eg @opendatacube.

Moving to weekly patch releases would fix all of these problems.

Maintainer availability doesn't need to be a limiting factor, either - for example, @HypothesisWorks has a deployment pipeline where the only human involvement is to click 'merge', and I'd be happy to help out if you'd like to set up a similar system.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   v0.10.1 Release 287852184

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

CREATE TABLE [issue_comments] (
   [html_url] TEXT,
   [issue_url] TEXT,
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [created_at] TEXT,
   [updated_at] TEXT,
   [author_association] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [issue] INTEGER REFERENCES [issues]([id])
);
CREATE INDEX [idx_issue_comments_issue]
    ON [issue_comments] ([issue]);
CREATE INDEX [idx_issue_comments_user]
    ON [issue_comments] ([user]);