issue_comments
Data license: AGPL · Data source: ACEmulator Project
3 rows where issue = 224988064
This data as json, CSV (advanced)
Suggested facets: user, created_at (date), updated_at (date)
id ▼ | html_url | issue_url | node_id | user | created_at | updated_at | author_association | body | reactions | performed_via_github_app | issue |
---|---|---|---|---|---|---|---|---|---|---|---|
298093388 | https://github.com/ACEmulator/ACE/pull/301#issuecomment-298093388 | https://api.github.com/repos/ACEmulator/ACE/issues/301 | MDEyOklzc3VlQ29tbWVudDI5ODA5MzM4OA== | delasteve 595925 | 2017-04-28T20:01:58Z | 2017-04-28T20:01:58Z | CONTRIBUTOR | - `.gitattributes` - This file is recommended for git development. It helps with line endings, which is an issue when you are talking cross platform development. Furthermore, if you create any new project from Visual Studio, this file is created along with a `.gitignore` file. - `.editorconfig` - It is becoming more and more common to have a config file for editors and IDEs. I have my editor set to 2 spaces by default for any project. If we allow for cross platform development, this helps solve the problem for others in the same situation (not everyone will use Visual Studio), as well as me. - Changing to `Xunit` - Let's be honest, the projects tests aren't tests. They just assume that if the project starts up, it runs. You could have just made a console app for each and it would've had the same effect. I don't have much else to say for this. - Adding `.github` folder and an `ISSUE_TEMPLATE.md` file - This project is getting bigger, and also hosted on GitHub. When issues arise, a standard format should be used so that we can easily navigate the issue and what's expected to resolve it. This is supported by GitHub and most larger projects use this. - Breaking AppVeyor and adding Travis - AppVeyor doesn't support Linux and Unix, so another CI platform is needed that does. This way, we can support all 3 major OSes. As a to do item, I was going to fix this before the PR was merged. - x64 - I didn't know about this. I'll remove it. I created a new Solution file via the dotnet cli and worked from there. - Folder structure - Yeah, could've been done in another PR. If you have that big of a beef with it, I really don't care enough. Again, it's labelled as a WIP PR and up here for review for a reason. If you would like me to break this PR out into several, that's fine, too. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | [WIP] feat: move project to dotnet core 224988064 | |
298124530 | https://github.com/ACEmulator/ACE/pull/301#issuecomment-298124530 | https://api.github.com/repos/ACEmulator/ACE/issues/301 | MDEyOklzc3VlQ29tbWVudDI5ODEyNDUzMA== | delasteve 595925 | 2017-04-28T22:53:52Z | 2017-04-29T01:25:47Z | CONTRIBUTOR | In addition to the above concerns, since I feel I didn't adequately explain why I did what I did with the folder structure. There are many examples of this structure being used in the .NET world. For example, https://github.com/dotnet/docs/blob/master/docs/core/porting/project-structure.md, and the accompanying GitHub repo https://github.com/dotnet/docs/tree/master/samples/framework/libraries. I was simply standardizing the project from examples put forth by Microsoft themselves. There was the question you posed of would I do this on a new team? Yes, I would, if I was tasked with converting the project from .NET Framework to .NET Core, which I was with this PR, given the above example as just one of the cases I'd put forth of why I am doing what I did. I never intended to have this PR merged in without the to do list being completed (have CI working again, logging being in place, etc). | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | [WIP] feat: move project to dotnet core 224988064 | |
298326534 | https://github.com/ACEmulator/ACE/pull/301#issuecomment-298326534 | https://api.github.com/repos/ACEmulator/ACE/issues/301 | MDEyOklzc3VlQ29tbWVudDI5ODMyNjUzNA== | Mogwai-TheFurry 25351661 | 2017-05-01T12:28:20Z | 2017-05-01T12:28:20Z | CONTRIBUTOR | Short wrap-up / summary: Please limit PRs to 1 feature. If you're changing design or architecture, a discussion ahead of time would be much preferred, but putting comments in your PR to explain things is better than nothing. I've never used Github for issue tracking or project management (and we don't have any Github experts on the team yet, either) so we're not aware of what all it can do or how it does it. That said, we are very open to improving our process here - we just need things explained. I don't argue that our tests do much. They make sure the DB prepared statements are syntactically correct, but changing to XUnit doesn't change that either. We currently have no plans or desire to support non-Windows development. We have a number of Unix/Ubuntu/Linux developers that have had no major objections to this. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | [WIP] feat: move project to dotnet core 224988064 |
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]);