Hi,
Over the last couple of weeks, I've talked to several people, mostly engineers with not too much development experience, who said they would like to start contributing little fixes to SSSD. I would like to find some tasks that they can easily handle without making their had spin from looking at harder stuff like asynchronous tevent code :-)
In the past, we used the 'easyfix' tag in the sssd tickets. We still had some, but not enough. I tagged quite a few today, but if anyone knows about more easy fixes, please tag them as well. https://fedorahosted.org/sssd/report/34
Can anybody think of more tasks to ask newcomes to do? I know adding tests would be great, tests don't require C knowledge, but only Python. But we would have to document how to write new tests, currently the process is very convoluted.
We also need to improve and fix documentation on the wiki.
Anything else?
On Thu, Aug 04, 2016 at 10:20:37AM +0200, Jakub Hrozek wrote:
Hi,
Over the last couple of weeks, I've talked to several people, mostly engineers with not too much development experience, who said they would like to start contributing little fixes to SSSD. I would like to find some tasks that they can easily handle without making their had spin from looking at harder stuff like asynchronous tevent code :-)
In the past, we used the 'easyfix' tag in the sssd tickets. We still had some, but not enough. I tagged quite a few today, but if anyone knows about more easy fixes, please tag them as well. https://fedorahosted.org/sssd/report/34
Can anybody think of more tasks to ask newcomes to do? I know adding tests would be great, tests don't require C knowledge, but only Python. But we would have to document how to write new tests, currently the process is very convoluted.
We also need to improve and fix documentation on the wiki.
Anything else?
btw I amended the Contribute page with so that the tasks for newcomers are better visible: https://fedorahosted.org/sssd/wiki/Contribute?action=diff&version=46&...
I know it's not code related, but documentation and guides come to mind. Maybe let people contribute more freely to the upstream wiki as they work on tickets?
On Tue, Aug 9, 2016 at 6:34 AM, Jakub Hrozek jhrozek@redhat.com wrote:
On Thu, Aug 04, 2016 at 10:20:37AM +0200, Jakub Hrozek wrote:
Hi,
Over the last couple of weeks, I've talked to several people, mostly engineers with not too much development experience, who said they would like to start contributing little fixes to SSSD. I would like to find
some
tasks that they can easily handle without making their had spin from looking at harder stuff like asynchronous tevent code :-)
In the past, we used the 'easyfix' tag in the sssd tickets. We still had some, but not enough. I tagged quite a few today, but if anyone knows about more easy fixes, please tag them as well. https://fedorahosted.org/sssd/report/34
Can anybody think of more tasks to ask newcomes to do? I know adding tests would be great, tests don't require C knowledge, but only Python. But we would have to document how to write new tests, currently the process is very convoluted.
We also need to improve and fix documentation on the wiki.
Anything else?
btw I amended the Contribute page with so that the tasks for newcomers are better visible: https://fedorahosted.org/sssd/wiki/Contribute?action=diff& version=46&old_version=45 _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@ lists.fedorahosted.org
On Tue, Aug 09, 2016 at 07:26:24AM -0400, Dan Lavu wrote:
I know it's not code related, but documentation and guides come to mind. Maybe let people contribute more freely to the upstream wiki as they work on tickets?
Yes, how should we let potential contributors let about what's needed? File tickets as well?
I think it should be less formal than that, maybe on the wiki page, to have a simple wishlist? So they'll ask to do it, grant access, write a draft in the wiki, one reviewer, then publish?
On Tue, Aug 9, 2016 at 7:38 AM, Jakub Hrozek jhrozek@redhat.com wrote:
On Tue, Aug 09, 2016 at 07:26:24AM -0400, Dan Lavu wrote:
I know it's not code related, but documentation and guides come to mind. Maybe let people contribute more freely to the upstream wiki as they work on tickets?
Yes, how should we let potential contributors let about what's needed? File tickets as well? _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@ lists.fedorahosted.org
On Tue, Aug 09, 2016 at 08:18:16AM -0400, Dan Lavu wrote:
I think it should be less formal than that, maybe on the wiki page, to have a simple wishlist? So they'll ask to do it, grant access, write a draft in the wiki, one reviewer, then publish?
We can do that, but I would stil prefer (at least for my tracking) to have tickets as well, maybe in a special milestone that would not be used otherwise, otherwise the wishlist might get out of sync easily..
On 08/04/2016 04:20 AM, Jakub Hrozek wrote:
Hi,
Over the last couple of weeks, I've talked to several people, mostly engineers with not too much development experience, who said they would like to start contributing little fixes to SSSD. I would like to find some tasks that they can easily handle without making their had spin from looking at harder stuff like asynchronous tevent code :-)
In the past, we used the 'easyfix' tag in the sssd tickets. We still had some, but not enough. I tagged quite a few today, but if anyone knows about more easy fixes, please tag them as well. https://fedorahosted.org/sssd/report/34
Can anybody think of more tasks to ask newcomes to do? I know adding tests would be great, tests don't require C knowledge, but only Python. But we would have to document how to write new tests, currently the process is very convoluted.
We also need to improve and fix documentation on the wiki.
Anything else?
Hello,
I wanted to provide some feedback on the Contribute wiki page from an outsiders perspective after spending time writing a few patches for sssd. I hope it will be of some value to improve the wiki page and create a lower barrier for entry for contributors especially as sssd progresses and becomes more popular. As a caveat, I expect some of my comments may be a result of slight misunderstandings from my part and could be interpreted differently from another contributor or someone with more git/make experience.
Getting the source
You can also enable the commit template by:
git config commit.template .git-commit-template
I ran the commands provided in the 'Getting the source' section
from top to bottom but the .git-commit-template does not exist yet until you clone the git repo. I suggest we move this line to after downloading the git repo
Building SSSD To build SSSD from source, follow these steps: 1. Install necessary tools 2. Create source rpm (run from git root directory) 3. Install SSSD dependencies
It was not clear to me if these commands need to be run each time
you create a new patch or amend a patch, or if only just once.
Finally, assuming you have sudo privilege, you can run the sssinstall alias to install this debug build onto the build machine.
when sssinstall completes, I was not sure if it succeeded or
failed. It would be nice if there is some way to test and be sure or at perhaps add to the alias '&& echo sssinstall Completed'
Sending patch to upstream Submitting
You can create multiple commits and then change -1 to -N where N is the number of commits to produce patches for.
Is there any general rule or guidance on when a fix should be split
up into multiple commits/patches? If so, is it worth adding this information to the wiki?
Also, some miscellaneous suggestions I have for improving the wiki:
- the wiki mentions that you should write a unit test to go along with the patch, but it does not mention you should actually test your fix and verify that the problem is corrected and expected results are returned. This is implied by the Building SSSD section but it is not explicitly stated.
- I found the following link useful for understanding the role of internal sssd components and their interaction, I think it may be worth adding here though I suspect it could be an outdated doc
https://fedorahosted.org/sssd/wiki/InternalsDocs
Everything else was very straightforward and easy to understand so I would like to say thanks for providing this wiki!
Kind regards, Justin Stephenson
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On Wed, Aug 24, 2016 at 10:45:03AM -0400, Justin Stephenson wrote:
On 08/04/2016 04:20 AM, Jakub Hrozek wrote:
Hi,
Over the last couple of weeks, I've talked to several people, mostly engineers with not too much development experience, who said they would like to start contributing little fixes to SSSD. I would like to find some tasks that they can easily handle without making their had spin from looking at harder stuff like asynchronous tevent code :-)
In the past, we used the 'easyfix' tag in the sssd tickets. We still had some, but not enough. I tagged quite a few today, but if anyone knows about more easy fixes, please tag them as well. https://fedorahosted.org/sssd/report/34
Can anybody think of more tasks to ask newcomes to do? I know adding tests would be great, tests don't require C knowledge, but only Python. But we would have to document how to write new tests, currently the process is very convoluted.
We also need to improve and fix documentation on the wiki.
Anything else?
Hello,
I wanted to provide some feedback on the Contribute wiki page from an outsiders perspective after spending time writing a few patches for sssd. I hope it will be of some value to improve the wiki page and create a lower barrier for entry for contributors especially as sssd progresses and becomes more popular. As a caveat, I expect some of my comments may be a result of slight misunderstandings from my part and could be interpreted differently from another contributor or someone with more git/make experience.
Hi,
thanks for the feedack. Feel free to just go and update the page as you see fit, please just send a note when you're done so we can review the diff..
Getting the source
You can also enable the commit template by:
git config commit.template .git-commit-template
I ran the commands provided in the 'Getting the source' section from top
to bottom but the .git-commit-template does not exist yet until you clone the git repo. I suggest we move this line to after downloading the git repo
Building SSSD To build SSSD from source, follow these steps:
- Install necessary tools
- Create source rpm (run from git root directory)
- Install SSSD dependencies
It was not clear to me if these commands need to be run each time you
create a new patch or amend a patch, or if only just once.
Finally, assuming you have sudo privilege, you can run the sssinstall alias to install this debug build onto the build machine.
when sssinstall completes, I was not sure if it succeeded or failed. It
would be nice if there is some way to test and be sure or at perhaps add to the alias '&& echo sssinstall Completed'
well, if there is no error message, it's successfull :) but feel free to change the wiki..
Sending patch to upstream Submitting
You can create multiple commits and then change -1 to -N where N is the number of commits to produce patches for.
Is there any general rule or guidance on when a fix should be split up
into multiple commits/patches? If so, is it worth adding this information to the wiki?
I think it's worth adding. Normally the patches should be split so that every logical change in the large patchset is contained in its own patch. I think the example where you added a new public function in one patch along with a test and used the function to add new functionality to sssd is a perfect one.
Also, some miscellaneous suggestions I have for improving the wiki:
- the wiki mentions that you should write a unit test to go along with the
patch, but it does not mention you should actually test your fix and verify that the problem is corrected and expected results are returned. This is implied by the Building SSSD section but it is not explicitly stated.
Feel free to add this, I always thought it goes without saying the developer should test their patch.
- I found the following link useful for understanding the role of internal
sssd components and their interaction, I think it may be worth adding here though I suspect it could be an outdated doc
I /hope/ it's not outdated. If anything feels fishy there, please tell us, we need to keep this document up-to-date.
https://fedorahosted.org/sssd/wiki/InternalsDocs
Everything else was very straightforward and easy to understand so I would like to say thanks for providing this wiki!
Cool!
On 08/25/2016 03:41 AM, Jakub Hrozek wrote:
On Wed, Aug 24, 2016 at 10:45:03AM -0400, Justin Stephenson wrote:
On 08/04/2016 04:20 AM, Jakub Hrozek wrote:
Hi,
Over the last couple of weeks, I've talked to several people, mostly engineers with not too much development experience, who said they would like to start contributing little fixes to SSSD. I would like to find some tasks that they can easily handle without making their had spin from looking at harder stuff like asynchronous tevent code :-)
In the past, we used the 'easyfix' tag in the sssd tickets. We still had some, but not enough. I tagged quite a few today, but if anyone knows about more easy fixes, please tag them as well. https://fedorahosted.org/sssd/report/34
Can anybody think of more tasks to ask newcomes to do? I know adding tests would be great, tests don't require C knowledge, but only Python. But we would have to document how to write new tests, currently the process is very convoluted.
We also need to improve and fix documentation on the wiki.
Anything else?
Hello,
I wanted to provide some feedback on the Contribute wiki page from an outsiders perspective after spending time writing a few patches for sssd. I hope it will be of some value to improve the wiki page and create a lower barrier for entry for contributors especially as sssd progresses and becomes more popular. As a caveat, I expect some of my comments may be a result of slight misunderstandings from my part and could be interpreted differently from another contributor or someone with more git/make experience.
Hi,
thanks for the feedack. Feel free to just go and update the page as you see fit, please just send a note when you're done so we can review the diff..
Hi Jakub, I made some minor updates including - adding the sssinstall command - information about splitting patches - adding the SSSD internals page link
Feel free to edit as you see fit.
-Justin
Getting the source
You can also enable the commit template by:
git config commit.template .git-commit-template
I ran the commands provided in the 'Getting the source' section from top
to bottom but the .git-commit-template does not exist yet until you clone the git repo. I suggest we move this line to after downloading the git repo
Building SSSD To build SSSD from source, follow these steps:
- Install necessary tools
- Create source rpm (run from git root directory)
- Install SSSD dependencies
It was not clear to me if these commands need to be run each time you
create a new patch or amend a patch, or if only just once.
Finally, assuming you have sudo privilege, you can run the sssinstall alias to install this debug build onto the build machine.
when sssinstall completes, I was not sure if it succeeded or failed. It
would be nice if there is some way to test and be sure or at perhaps add to the alias '&& echo sssinstall Completed'
well, if there is no error message, it's successfull :) but feel free to change the wiki..
Sending patch to upstream Submitting
You can create multiple commits and then change -1 to -N where N is the number of commits to produce patches for.
Is there any general rule or guidance on when a fix should be split up
into multiple commits/patches? If so, is it worth adding this information to the wiki?
I think it's worth adding. Normally the patches should be split so that every logical change in the large patchset is contained in its own patch. I think the example where you added a new public function in one patch along with a test and used the function to add new functionality to sssd is a perfect one.
Also, some miscellaneous suggestions I have for improving the wiki:
- the wiki mentions that you should write a unit test to go along with the
patch, but it does not mention you should actually test your fix and verify that the problem is corrected and expected results are returned. This is implied by the Building SSSD section but it is not explicitly stated.
Feel free to add this, I always thought it goes without saying the developer should test their patch.
- I found the following link useful for understanding the role of internal
sssd components and their interaction, I think it may be worth adding here though I suspect it could be an outdated doc
I /hope/ it's not outdated. If anything feels fishy there, please tell us, we need to keep this document up-to-date.
https://fedorahosted.org/sssd/wiki/InternalsDocs
Everything else was very straightforward and easy to understand so I would like to say thanks for providing this wiki!
Cool! _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On Sun, Aug 28, 2016 at 03:31:05PM -0400, Justin Stephenson wrote:
Hello,
I wanted to provide some feedback on the Contribute wiki page from an outsiders perspective after spending time writing a few patches for sssd. I hope it will be of some value to improve the wiki page and create a lower barrier for entry for contributors especially as sssd progresses and becomes more popular. As a caveat, I expect some of my comments may be a result of slight misunderstandings from my part and could be interpreted differently from another contributor or someone with more git/make experience.
Hi,
thanks for the feedack. Feel free to just go and update the page as you see fit, please just send a note when you're done so we can review the diff..
Hi Jakub, I made some minor updates including
- adding the sssinstall command
- information about splitting patches
- adding the SSSD internals page link
Feel free to edit as you see fit.
-Justin
Looks good, thanks!
sssd-devel@lists.fedorahosted.org