A year ago I have started an issue on github repository of a popular open source project. There wasn't enough data to fix it because bug was caused only by one closed source program. Recently I have stumbled upon other program that causes the bug and this one is open source. This should make it possible to fix the issue.
I have added new comment in issue providing new information, but it got no response for 10 days.
https://github.com/linuxmint/Cinnamon/issues/6253
I wonder if maintainers see comments on old issues in their notifications?
If they do did they discard it by accident or perhaps because in their experience most comments on old issues are useless?
Should I just edit last comment there slightly?
Will they see that?
Or what to do?
The good news is the project is not dead. Issues have been closed recently and PRs have been merged. Someone is watching the queue. The bad news is the project has over 800 open issues at this time which means they're probably swamped.
Open Source projects are typically run by volunteers, and that looks like a low priority issue. If you want it solved, do everything you can do reduce the work necessary to fix the problem. You've already given clear instructions on how to reproduce the problem, that's a very good start.
The single best thing you can do is submit a PR with a complete patch including tests. Be sure to conform to their developer guidelines. That project does not leave PRs open long. If you can't do a complete patch, take a stab at it and submit the PR asking for help. If you don't know where to start patching, make a comment on the issue asking for help with where to start.
Basically, do the work. If you can't do the work, show a willingness to do the work.
Related
I have this issue when I try to merge my branch to the main one for my RASA chatbot project and I want to know if there are any ways to fix this and create a pull request or should I just change my main branch to the domain-side branch
Ok so I fixed the issue by deleting the .rasa cache folder
This can occur when there are a lot of commits in your Pull Request
Unfortunately, this is a known github issue.
Thanks for writing to GitHub support and sorry for the trouble!
We have received a few similar reports regarding big pull requests. I can confirm that our team is working on fixing this problem, and I've added your report to that issue.
Unfortunately I won't be able to provide an estimated time on when this might get fixed. We know this is not ideal, but hope you understand.
Is there anything we can do to preserve our comments and alleviate this issue now and in the future?
You should be able to use our API to get a copy of the comments in this pull request:
https://developer.github.com/v3/pulls/comments/#list-comments-on-a-pull-request
https://developer.github.com/v3/pulls/reviews/#list-reviews-on-a-pull-request
If you have any question regarding using API we can definitely offer more detailed instructions.
Unfortunately I'm not sure if there's anything you can do on your part to view this pull request normally.
One thing you could try is viewing this PR in Incognito window or logged out.
I was actually able to view the PR you linked because I don't have write access to this repository, so GitHub will try to load less things for me such as edit buttons and so on. Of course this won't allow you to merge the pull request and so on, but perhaps it would help for you to look at its content?
Lastly, while we are working on consistently supporting large pull requests, you might consider keeping pull requests relatively short for now to avoid running into this again.
I hope this helps clear things up, and please let us know if you have any other questions.
Please refer to the full discussion provided here.
On Github issues pages, how do you know which post contains the solution to the issue?
Take this page, for example.
The issue is closed, so we are to presume the problem is solved... yet this discussion thread (and many are much longer) seems to be mostly people talking back and forth in circles and it's very confusing to try to determine which post is intended or generally accepted to be the solution.
I was thinking it would be nice if the repo owner/representative could designate a post as what they determine to be the solution... with some kind of graphic... but I don't see that.
Ideally, if a pull request fixes an issue they would be linked by referencing the issue from the PR. For example, if a PR closes issue #123 the PR description would say closes #123 or fixes #123. You can also link them manually.
The PR would appear in the issue's "Linked Pull Requests" sidebar, and vice-versa.
For example, we can see that this PR is linked to this issue.
And from the issue we can see the linked PR.
In the issue, we can see activity on the linked PR as well as anything which mentioned it. A mention is a commit log or comment or issue or PR with something like #43878.
If the issue is closed for some other reason, ideally the person closing mentions why in a comment.
If people keep coming back to the issue and are confused, that may indicate the issue is not closed, or perhaps there is a related documentation issue.
In your example, we can see where the issue was mentioned in other issues.
And, sure enough, its referenced in issue #63056 and in PR #9 https://github.com/aws-amplify/amplify-flutter/pull/9#issuecomment-670038832. That information might help.
And we can see why the issue was closed, the change was intentional.
Unfortunately, the reason and resolution is buried in a comment. Improving the documentation may have been a better choice. That would have been done in a linked PR.
I was thinking it would be nice if the repo owner/representative could designate a post as what they determine to be the solution... with some kind of graphic... but I don't see that.
That would be nice. I don't believe Github has that feature. Posting it here is unlikely to reach Github. You could suggest it in Github Community or ask Support.
As a work around, one can make their final comment and then lock the issue so no further comments can be made. This would avoid burying the resolution. Then people would have to open a new issue if they really want to comment.
Or, one can edit the description of the issue to include a prominent reference to the resolution.
See also
Autolinked references and URLs
Linking a pull request to an issue
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm new to github and I like to help other people with their projects that I find interesting.
I know there are a lot of guides in the github place, but I think it could be nice to gather a bunch of real people's experiences.
So, I invite you to post about your first experiences in github.
Whether you are a not-so-newbie or you are a heavy rock in github comunnity, I think your lines could encourage real newbies like me about entering this great open source community.
It's pretty simple. You can summarise a simple community project's development into a circular process of just two simple actions:
Bug tracking. Testing the software, logging bugs, making sure they're filed in the right place, asking for more detail, etc. If valid, these reports carry the detail for the next phase:
Patching. Target a bug, reproduce it, change your code to fix it, test locally and push your patch. This loops back around to the first phase where the bug report is marked fixed or otherwise.
You've got to start with phase one. You don't have to follow a bug right through and you can help as simply as just hopping in and making sure other bug reporters are doing the right things (making sure there are dumps where applicable, making sure the tags are right, merging duplicates).
Or you can be more involved and test the software to find new bugs. The onus on getting things right is now your own.
Once you're more familiar with the project, its code and its maintainers, then you might be ready to get involved with fixing some of the outstanding bugs.
An important thing to remember is you can ask for help. Nobody expects an outsider to understand all the code or be able to fix all the bugs. Maintainers will very often be more than happy to help somebody get started because they'll often get their time back from work you do on the project.
EDIT: CodeTriage.com can help for this.
This is kind of an old question, but there is a new site that's trying to help people like the OP to find projects to contribute to.
The site is called Looking For Pull Requests (it's dead now in 2016) and it aims to help people looking for help to find people wanting to help.
You can just browse the list of projects and see how active they are, or you can even publish your project pretty easily.
Github is just a website which aggregates projects. You need to ask the project maintainers themselves how they want you to help. It is pointless asking here as we do not know the specific rules for the project you are interested in. Different projects have different ways of doing things and require help in different areas.
Learn how to use Git would be the number one thing to say. Oh, and make sure you following the coding standards.
I struggled asking that question but here it is.
I am using source control since several years for multiple projects using different systems (svn, hg, git) and I learned how to improve my messages by following guidelines etc.
But as far as I can remember I never ever had a look at them afterwards.
So ... how do you profit from your own commit messages? When I need to go back because I smashed something and need a fresh start, I usually just go back to the latest "node" (where I started or merged a branch). Do I write those messages just for people monitoring the project who are curious what is going on?
Regards
You write them as an aid to your future self, and others on the team. To give you some background of when I have found them useful:
I used to work on a project where commit messages were invaluable - on more than one occasion I used them to track down code that was years old. On that project our bug tracking system was also integrated with our VCS (ClearCase). So when you checked in a change, it would record the bug number in the commit comments. This was very helpful to allow you to trace back exactly what was changed and why.
So to sum it up, although commit messages may seem pointless if you are just starting out (especially if you are the only one working on the project), they become invaluable once you have a successful product that is supported in production by multiple developers.
Update
Another useful feature of commit messages is that they require you to review and summarize the changes you just made. Even if I remember what I have changed, I will often do a quick diff of a file before checking it in. I will briefly read it all over again to make sure there are no typo's, that I changed everything I meant to, etc. This is a simple way to review your code for those small little bugs that would otherwise find their way into your code. Anyway, after doing this I have a clear picture of what changed, so I use this to write a concise summary of the change when checking in the file. This is a simple habit that helps increase code quality with little effort on your part.
"Send me a list of the things you did in the past two weeks" - Boss
Your messages are more for other users than yourself. Although I make sure to place good commit messages even on personal repos as well. Helps when you get sidetracked on a project and visit it months down the line to get a handle of the recent work done on a project.
One thing I've found is that the commit messages are a good way to keep myself from not committing often enough. If I can't put the changes into a short commit message I probably should have committed the changes earlier.
In the best case, a commit is bound to a work item in a feature/bug tracker. That way you will be able to easily see which feature/bug has been implemented/fixed. This is not only useful to know if a certain revision contains a feature or bug fix but also to easily create a release note.
What would be the point of a commit without a note to tell you what it is? It's like asking 'Why do books have titles on the sides?', or perhaps 'Why do books have indexes and page numbers?'. It seems to me that a source control log that didn't have a description for each change wouldn't be very useful.
Reasons you may need to refer to the commit message include
A bug has surfaced and you want to find when that part of the code was changed last
You decide to undo some changes and need to decide which revision to revert to
For either of these possibilities, without good commit messages, you would be left looking through the diffs for every single commit until you found what you were looking for in the code.
There is a lot of conversation about commenting code, but how about commenting on check-ins?
I found this blog post:
http://redbitbluebit.com/subversion-check-in-comment-great-practices/
As the guy who is putting together the release notes, I am looking for ways to make that job easier.
Currently we defined our own scheme with <Begin_Doc>...<End_Doc> for anything that should be published to our software customers. But even for the internal stuff, I'd like to know the "why" for every change.
Every feature has a ticket/issue/bugreport/task/whatever-you-call-it, and the ticket number is always referenced in the check-in comment. This gives context.
I would advocate NOT using/overloading your version control system for this. I would suggest the issue tracking software as a better fit.
For one, it does not seem appropriate to have developers add all the context and duplicated information in a commit message that is already in a requirements doc or issue/defect system.
You can use a tool to gather the relevant fixes/issue numbers that are in the commit comments and then go collect those from your other repository, but I think it is a mistake to basically make your revision tool an external facing thing.
You need to define what the Source/version repository/SVN is - is it for managing your source files, or is it also for writing release note. I think it should not be overloaded.
We try to keep it simple: write one sentence describing the change that you are committing. If a developer needs two or more sentences to describe the commit, then perhaps the commit is two unrelated pieces of work. When commits like this end up in version control, then it is difficult to revert fixes in isolation.
Another piece of information that we like to include in our commit comment is the defect / feature number that the commit fixes / implements. Not all work that we do is related to a defect in our issue tracking system, so this is not compulsory.
One last piece of information that we put in our commit comments is the name of one code reviewer. This is the person who did a sanity check on the changes before the commit takes place.
I recommend functional comments. The comments should give a summary of what was changed. If something was changed, and why. Every commit should be explainable, if you can't explain it clearly, you probably shouldn't be checking it in.
The most important thing to remember when using source control logs is they are there to determine when and what was changed. The more functional, and detailed the better. commits should be made in bite size pieces, that can be explained with bite size comments.
My personal preference is this style:
UPDATED the error logging system.
Added a legacy error parsing routine using regex to get the legacy error codes.
Changed the text in the database error messages, to correct misspellings.
Removed commented out sections of code, because they were not used any more.
The key is what are you going to do with the comments. If you're creating release notes, then you can do as you suggested. However I would recommend instead you keep track of release notes somewhere else, such as in a project management or bug tracking tool.
As for developer related comments, we've generally asked people to explain what they're doing, a one sentence explanation. It doesn't need to be too formal, mainly because if it is people will push back against it. Plus, if you know who did it, and you have a quick comment, you can generally trace back the issue and find the person.
As well, if you use a tool like FogBugz, you can link an SVN checkin to a case number. Which means that you can look up the case to get the full discussion, comments, screenshots, etc. Which is much more information than you could ever enter in a checkin comment.
Agree with Remembrance, but you should also write a little bit about why you implemented the change /bug fix the way you did.
If you belive in checking in often, you should also include TO DO's in order to make it possible for one of your co-workers to complete the task.
Making my changes small helps: I can provide detailed descriptions of my changes this way.
The checkin comments should be the information that a developer wants: this includes refactorings, motivation behind the code, etc.
On our projects we always advocate providing some detail to what a commit is about and to assist in not having to duplicate information like the problem we use Trac and have our repository integrated. The advantage is that you can then reference the issue ticket in the comment and only state the resolution or steps of work carried out. Trac then automatically links the reference number to the original issue number and applies your commit message as a comment to the issue. Then when you want to see what has been done you can simply read the issues within Trac and have full context.
With regards to release notes we have found that taking the list of issues within a release and using the commit information as a basis for the comments has worked fine. Generally you will not have release notes that have the raw commit messages in them as your clients do not really care about every little change or even the level of detail that may be included in the comment. So you would normally need to do a fair amount of editing to highlight the main changes and bug fixes implemented in that release.
I would say to try to follow a changelog style. The first line should be a short summary, and include the issue/ticket number (if any). This should possibly be followed by a blank line depending on how your VCS handles multi-line commit messages, then a fuller multiline description. I would say it's unreasonable to impose any strict formatting since it will discourage frequent commits, but so long as the important commits (the ones closing issues, or major changes) are done this way you should be ok.
If you use something like Trac or roundup + svn integration, it can pick out issue numbers from the commit messages. I would always put these in the first line since they're so useful.
Edit: Given that this is by far my most downvoted answer, I think it's worth emphasizing what's hidden in the last paragraph: I'm a sole proprietor. I have 100% ownership of these projects and do not work with other developers. In a shop with more than one developer, everything I'm saying in this answer may be completely inapposite.
I subscribe to DRY here as in all things.
I almost never add a comment to my commits. A comment is almost always repeating myself. The answer to the question "what changed in this commit"? is almost always in the diff.
When I'm looking at a file and I ask "what the hell happened here?", the first thing I do is look at the diff with the previous rev. 90% of the time the answer is immediately apparent, either because the code's self-evident or because there was something not self-evident that I commented in the code. If it's not, I correlate the rev dates of the file with the bug-tracking system and the answer is there.
This always works. It sometimes requires a little investigation to figure something out, because I didn't comment my code adequately. But I've never been unable to find the answer fairly quickly.
The only time I add a comment to the commit log is when I know that a diff isn't going to help me. For instance, when I sort a class's members: the only thing that a diff is going to tell me in that case is that something very big happened. When I do that, I commit the file as soon as I've fixed it. There's no appropriate place to comment a change of that scope in the file, so I add a comment to the effect that the only change in this rev is reordering the members.
("Why wouldn't you comment a change like that in the revision history at the top of the file?" you might ask. I don't keep a revision history at the top of my files. That was a scary, break-the-habit-of-a-lifetime change to make, and I've never regretted it for a moment. The revision history is Subversion.)
If I didn't have 100% ownership of the project, it might be different. It might be too hard to correlate commits with bug fixes. It might be too hard to train other developers to code to a style that makes it possible to rely on version control effectively. I'd have to see.