Looking into GitHub numbers we can easily found an “issue” with the SuiteCRM project: there are many bugs reported but not solved. This can be considered normal on collaborative projects but the real problem is: many of them has fix proposed.
SuiteCRM is an opensource project with the code controlled by a company. So we should expect that those fix proposed are evaluated with public comments if they could be a path to go or not!
I place now 2 questions:
1- How to improve the workflow on code received from users?
2- How users with same bugs will know what fix proposed are to consider and test for them and what to ignore?
I was just going to subscribe to this topic but then I wanted to write something too… Thanks @horus68 for your hard work, I hope that your questions get answered.
For the Pull Requests - All of these will need to be tested to ensure they work in fixing the issue and don’t break something else.
What will help speed this process along is if the community get involved in testing these pull requests.
To ensure of this, make sure the PR passes all the checks and doesn’t have any conflicts.
Then test out the fix on a instance of the most recent version of SuiteCRM.
If it all works tag one of the admin(e.g. shogunpol, myself etc) and tell them it works who will set the pull request as ‘Assessed’ this will allow us to know that the fix works and all we have to do is check for any additional conflicts and double check it then pull it into the core product.
If it doesn’t work, tag the author giving full details about what doesn’t work and what may help fix it.
If the community could do that, many more bugs could be fixed.
I personally don’t deal with GitHub however I try and test as many PR’s in my spare time.
If a PR is tested by more than 1 user it will help us confirm it works
**Please don’t test your own PR and remember to test in different views and browsers and themes
For the Bugs - This links to the above, of the 386 bugs would be great if the community could help validate these issues in the most recent version of SuiteCRM especially for older bugs and fixes for these are always welcomed from the community.
As I’m not super-familiar with git, what’s the workflow for collaborators to test out these pull requests and test them on latest version of SuiteCRM? Could you provide a 5 step quick’n’dirty description of what you need to do this efficiently? i.e. pull newest SuiteCRM from where? what steps necessary to check for conflicts (github? local command line?). How to find most relevant issues to check. How to setup notifications, etc.
Something like that would really help. I’m not been using Git at all so far for SuiteCRM purposes.
Regarding your suggestions, this now needs to be placed as a formal workflow on your site or Git help.
There are 228 PRs waiting for “time” from your end. We can help…there are already volunteers, but
[ul]
[li]We can’t just start with all at the same time (how will know if a PR from 2 years is actually wanted by Salesagility or simple ignored until now?) [/li]
[li]We need a direction on what to focus and a time frame to do that. [/li]
[/ul]
Also there has been too long without any valid workflow and many users was left without desire to contribute. You need to gain their trust again.
Lead the way,:
[ol]
[li]Place a clear workflow on bugs, issues and PRs (not just a forum reply)[/li]
[li]Pick 10 to start with (also tag them on git)[/li]
[li]Make the evolution visible to anyone[/li]
[/ol]
Then people will find if the time spent will be considered useful or not. Build and they will come!
In the mean while I would focus on PRs that fix bug issues. If they work as expected they would get pulled where as suggestions or enhancements would have to be reviewed further by SalesAgility.
Also agree on suggestions enhancements. The main issue here are bugs!
Maybe you need to review your actual github workflow and maybe start by merging those PR from your team and the ones already “acessed”
Take a look on 19 PR already accessed but not merged yet (some from 2015):
I have made one or two PR reviews on Github (even though I have no special rights there). The trick is to go into the “Files changed” tab of the PR, and you get a button to “Review changes”. I don’t know exactly what effects this has, but at least it’s a way of communicating my conclusions after trying the fix.
I can’t say I understand the logic behind labeling an issue a “Bug” versus a “Suggestion”. It doesn’t seem as though suggestions are being worked on, as far as I can tell. I have a few reported issues that ended up there, even though they are obviously bugs in the software, some of them with grave consequences.
I see too many things on Github that should be handled here in the forums. If something is just happening on somebody’s system, it’s too soon to create an issue for it. We need to guide people to come here first, so we can tell them to “check your logs and permissions” (mikebeck’s signature!).
I completely second horus68’s suggestion of publishing the worklow(s). I suggest using the “Wiki” tab on Github, everything in one page, just the essentials.
The problem is the developers at SuiteCRM dont care about fixing bugs, but instead work on a new theme. Of course the new theme means new bugs, and so other issues and pull request lay there for over a year and longer, while bugs on the new theme get fixed instantly.
Finally the pull request cannot be merged because the code has changed or the author of the pull request moved on or does not remember what was one year ago.
There was an item in the Roadmap for 7.8 which said “Bug blitz”. I was waiting eagerly for that one. Now it’s gone. The release is postponed for January 2017 (that’s ok, I don’t mind that) but the Bug Blitz is gone… It’s a pity, I wish it could be reinstated.
I agree with a lot of what has been said and its great to see a community of people taking a interest to support the project.
If I can address a few points
We have some fairly new members of the team working to drive down the issues and PR’s, but as they are new it going to take them some time to get up to speed and will make mistakes. So if you for example get some marked as suggestion where you don’t think it is feed that back and we can review that.
Similarly with issue if you think it need a high priority, or is important the more people that comment, agree or flag up the issue, then that will help. But I will be looking for better way for issues to be voted up.
PR’s I think the best way the community could help with this is to peer review each other PR’s, I know @Horus has recently used this on his PR and that is big help if 1. someone has tested it to see it work or 2. reviewed the code to see that it is suitable, meets that standard and is secure. Again if you think a PR needs more attention flag it up.
We will be working to clarify the documentation on the workflow/process so everyone who can help out so if you feel something is missing or not clear let us know
One question: how are we supposed to “flag up” an issue or a PR for attention? I don’t suppose just adding those “+1” generates any notifications to other people. So are we supposed to mention someone like this “@mattlorimer”?
Because I’m afraid it’s too tempting to just flag each and every SalesAgility employee all the time, and people (including me) will abuse it, eventually forcing you to ignore all (or most) of that notification traffic…
There are now 21 Accessed PR just waiting for a merge.
The thing is: if your staff approves a PR then is necessary for it to be merged into the Hot-fix Branch.
This is the only way that we can move on to the next fix so it can be accessed.
Else there will be too many branches and collisions on fixes.
I will be putting up clarification the workflow, but for now just so you are aware if it is Assessed it only means it has passed a basic assessment,
Following that or even without prior assessment, all pull requests will be reviewed by a Senior member of the SuiteCRM team and only then will it be merged.
I understand that this process takes too long at the moment, but we working to improve this.
