issue_comments

Table actions

3 rows where issue = 1042652334 and user = 5635139 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: created_at (date)

user 1

  • max-sixty · 3 ✖

issue 1

  • Release frequency · 3 ✖

author_association 1

id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
958583164 https://github.com/pydata/xarray/issues/5927#issuecomment-958583164 https://api.github.com/repos/pydata/xarray/issues/5927 IC_kwDOAMm_X845ItF8 max-sixty 5635139 2021-11-03T01:14:03Z 2021-11-03T01:14:03Z MEMBER

Agree that stable can always point to the latest release!

 
{
    "total_count": 2,
    "+1": 2,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Release frequency 1042652334
958114423 https://github.com/pydata/xarray/issues/5927#issuecomment-958114423 https://api.github.com/repos/pydata/xarray/issues/5927 IC_kwDOAMm_X845G6p3 max-sixty 5635139 2021-11-02T19:47:10Z 2021-11-02T19:47:10Z MEMBER

I quite like this idea in particular. I guess we also need to decide if we are okay with any release being fully automated though.

Maybe this is a confession — but when I do releases I'm not really adding any judgement. CI needs to pass but otherwise I'm not sure I'm adding any value beyond button-pressing...

 
{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Release frequency 1042652334
958106835 https://github.com/pydata/xarray/issues/5927#issuecomment-958106835 https://api.github.com/repos/pydata/xarray/issues/5927 IC_kwDOAMm_X845G4zT max-sixty 5635139 2021-11-02T19:36:15Z 2021-11-02T19:36:15Z MEMBER

I very much agree! To signal boost: - Lowering the cost of doing releases! Whatever frequency we want to do releases, this is beneficial. And if people think we should do more frequent releases, then it becomes even more important. I haven't been able to spend enough time on xarray recently, but I've tried to add a bit more automation on each go (as have many others!). - Not waiting for anything for a release. If it's ready then great; if not then another is arriving soon. - The only reasons I could see for waiting are a) features are insufficiently independent and b) it's a "call to action" that gives people a prod to get something finished. I've rarely seen (a) here, though I can sometimes empathize with (b)...

I don't have a particularly strong view on more frequent releases — they seem a bit better — maybe contributors are more likely to contribute if they can use their code in a public release soon. (Though maybe it's possible to do numbered alpha / beta releases to PyPI so it's possible to use them immediately)

One idea if we want to do very frequent releases is to write quality release notes a bit less frequently — i.e. "here are some of the big things that we've added over the past three months" — and then a bi-weekly release is automatically generated with less fanfare.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Release frequency 1042652334

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]);