Re: [Gluster-devel] Initiative to increase developer participation
On 05/30/2014 01:16 PM, Niels de Vos wrote: snip Documentation in the wiki, mainly these pages: - http://www.gluster.org/community/documentation/index.php/Main_Page#Developers - http://www.gluster.org/community/documentation/index.php/Developers - Over time make these new comers as experienced developers in glusterfs :-) Maintainers, Could you please come up with the initial list of bugs by next Wednesday before community meeting? If we mark bugs with the EasyFix keyword (see below), all bugs can get listed with a simple Bugzilla query: - https://bugzilla.redhat.com/buglist.cgi?bug_status=NEWkeywords=EasyFixproduct=GlusterFS Niels, Could you send out the guideline to mark the bugs as easy fix. Also the wiki link for backports. To mark a bug as Easy to Fix, open the Bug, and add in 'EasyFix' in the 'Keywords' field. Of course, it would help any newcomer if there is a comment on where (i.e. which source file, function) the changes are needed. For example, https://bugzilla.redhat.com/1100204 contains a clear description what is needed, and where. For the stable branches (release-3.4 and release-3.5 in the git repository), it often is needed to 'backport' a change from the current development branch (master). Backporting is for many changes relatively easy and we have started to document the steps here: - http://www.gluster.org/community/documentation/index.php/Backport_Guidelines The Backport Wishlist is a list of patches/bugs that are proposed candidates for backporting. When a backport request has been filed, a bug for this backport and the release-version should be created. Depending on the change, the EasyFix keyword could be set by the person creating the bug (or by a developer or sub-maintainer after a review). snip We have started a page in gluster wiki about easyfix bugs [1]. It contains the initial information for developers who want to fix easy bugs in GlusterFS. [1] http://www.gluster.org/community/documentation/index.php/EasyFix_Bugs Happy hacking!! Thanks, Lala ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Initiative to increase developer participation
On Thu, May 29, 2014 at 11:08:34PM -0400, Pranith Kumar Karampuri wrote: hi, We are taking an initiative to come up with some easy bugs where we can help volunteers in the community to send patches for. Goals of this initiative: - Each maintainer needs to come up with a list of bugs that are easy to fix in their components. - All the developers who are already active in the community to help the new comers by answering the questions. - Improve developer documentation to address FAQ Documentation in the wiki, mainly these pages: - http://www.gluster.org/community/documentation/index.php/Main_Page#Developers - http://www.gluster.org/community/documentation/index.php/Developers - Over time make these new comers as experienced developers in glusterfs :-) Maintainers, Could you please come up with the initial list of bugs by next Wednesday before community meeting? If we mark bugs with the EasyFix keyword (see below), all bugs can get listed with a simple Bugzilla query: - https://bugzilla.redhat.com/buglist.cgi?bug_status=NEWkeywords=EasyFixproduct=GlusterFS Niels, Could you send out the guideline to mark the bugs as easy fix. Also the wiki link for backports. To mark a bug as Easy to Fix, open the Bug, and add in 'EasyFix' in the 'Keywords' field. Of course, it would help any newcomer if there is a comment on where (i.e. which source file, function) the changes are needed. For example, https://bugzilla.redhat.com/1100204 contains a clear description what is needed, and where. For the stable branches (release-3.4 and release-3.5 in the git repository), it often is needed to 'backport' a change from the current development branch (master). Backporting is for many changes relatively easy and we have started to document the steps here: - http://www.gluster.org/community/documentation/index.php/Backport_Guidelines The Backport Wishlist is a list of patches/bugs that are proposed candidates for backporting. When a backport request has been filed, a bug for this backport and the release-version should be created. Depending on the change, the EasyFix keyword could be set by the person creating the bug (or by a developer or sub-maintainer after a review). PS: This is not just for new comers to the community but also for existing developers to explore other components. Please feel free to suggest and give feedback to improve this process :-). And, as a reminder, anyone that is interested in trying to write a patch, do not hesitate to ask questions. If something in the documentation is unclear, we do need to know so that we can improve it. Furthermore, I am of the opinion that there hardly exist stupid questions, and it's more stupid to not ask questions that others can easily answer. Always assume that if you have a question, someone else would like to hear the answer too :-) Reach out to the developers in #gluster or #gluster-dev on Freenode IRC, or on one of the mailinglists, try to keep the discussions public so that anyone can learn from it. Thanks, Niels ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Initiative to increase developer participation
Thanks Pranith/Niels, It is a great initiative, it will help us a lot :) On 05/30/2014 01:16 PM, Niels de Vos wrote: On Thu, May 29, 2014 at 11:08:34PM -0400, Pranith Kumar Karampuri wrote: hi, We are taking an initiative to come up with some easy bugs where we can help volunteers in the community to send patches for. Goals of this initiative: - Each maintainer needs to come up with a list of bugs that are easy to fix in their components. - All the developers who are already active in the community to help the new comers by answering the questions. - Improve developer documentation to address FAQ Documentation in the wiki, mainly these pages: - http://www.gluster.org/community/documentation/index.php/Main_Page#Developers - http://www.gluster.org/community/documentation/index.php/Developers - Over time make these new comers as experienced developers in glusterfs :-) Maintainers, Could you please come up with the initial list of bugs by next Wednesday before community meeting? If we mark bugs with the EasyFix keyword (see below), all bugs can get listed with a simple Bugzilla query: - https://bugzilla.redhat.com/buglist.cgi?bug_status=NEWkeywords=EasyFixproduct=GlusterFS Niels, Could you send out the guideline to mark the bugs as easy fix. Also the wiki link for backports. To mark a bug as Easy to Fix, open the Bug, and add in 'EasyFix' in the 'Keywords' field. Of course, it would help any newcomer if there is a comment on where (i.e. which source file, function) the changes are needed. For example, https://bugzilla.redhat.com/1100204 contains a clear description what is needed, and where. For the stable branches (release-3.4 and release-3.5 in the git repository), it often is needed to 'backport' a change from the current development branch (master). Backporting is for many changes relatively easy and we have started to document the steps here: - http://www.gluster.org/community/documentation/index.php/Backport_Guidelines The Backport Wishlist is a list of patches/bugs that are proposed candidates for backporting. When a backport request has been filed, a bug for this backport and the release-version should be created. Depending on the change, the EasyFix keyword could be set by the person creating the bug (or by a developer or sub-maintainer after a review). PS: This is not just for new comers to the community but also for existing developers to explore other components. Please feel free to suggest and give feedback to improve this process :-). And, as a reminder, anyone that is interested in trying to write a patch, do not hesitate to ask questions. If something in the documentation is unclear, we do need to know so that we can improve it. Furthermore, I am of the opinion that there hardly exist stupid questions, and it's more stupid to not ask questions that others can easily answer. Always assume that if you have a question, someone else would like to hear the answer too :-) Reach out to the developers in #gluster or #gluster-dev on Freenode IRC, or on one of the mailinglists, try to keep the discussions public so that anyone can learn from it. Thanks, Niels ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
