issue_comments
3 rows where author_association = "CONTRIBUTOR" and issue = 287852184 sorted by updated_at descending
This data as json, CSV (advanced)
Suggested facets: created_at (date), updated_at (date)
issue 1
- v0.10.1 Release · 3 ✖
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":
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.
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 | |
365352132 | https://github.com/pydata/xarray/issues/1821#issuecomment-365352132 | https://api.github.com/repos/pydata/xarray/issues/1821 | MDEyOklzc3VlQ29tbWVudDM2NTM1MjEzMg== | czr137 6153603 | 2018-02-13T18:05:06Z | 2018-02-13T18:05:06Z | CONTRIBUTOR | 1865It's a simple fix, but it affects my ability to produce CF1.7 netCDF files for distribution of our satellite data. The pull request #1869 is ready to go. |
{ "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
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]);
user 2