Re: [Gluster-devel] Glusterfs mainline BZs to close...
I came up with the BZ list by doing the following steps. 1. Find a list of all the BZs which are closed in a community release. Exclude any BZ which has "mainline" set in the version. 2. For each BZ in this list, get the corresponding upstream BZ (BZ which has mainline set in the version) using the Clone of field. Let me know if I missed anything. Thanks Naga - Original Message - From: "Humble Devassy Chirammal" To: "Bipin Kunal" Cc: gluster-devel@gluster.org Sent: Monday, November 2, 2015 6:56:24 PM Subject: Re: [Gluster-devel] Glusterfs mainline BZs to close... Thanks Bipin for working on this! Your first PR Is merged and its live here http://gluster.readthedocs.org/en/latest/Workflow-Guide/Index/ :) Once all the workflow/procedure kind of docs are live in glusterdocs repo, we can remove it from "developer-guide" by placing a pointer to RTD. --Humble On Thu, Oct 29, 2015 at 5:38 PM, Bipin Kunal < bku...@redhat.com > wrote: Hello Niels/Humble, I would like to help you here and by this I can even start collaborating in upstream. I will try to send first pull request very soon, late by next week. Thanks, Bipin Kunal On Wed, Oct 28, 2015 at 5:04 PM, Niels de Vos < nde...@redhat.com > wrote: On Wed, Oct 28, 2015 at 04:02:16PM +0530, Humble Devassy Chirammal wrote: > Hi Niels, > > > > Our shiny docs (or my bookmarks?) are broken again... > > http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20report%20Life%20Cycle/ > > http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20Triage/ > > > > As you know, the "Developer Guide" is now part of glusterfs source code ( > https://github.com/gluster/glusterfs/tree/master/doc/developer-guide ) [1]. > The decision to split the glusterfs documentation into three parts ( > developer spec/feature , Administration ) came late and it caused the > bookmark to break. Right, but I do not think the documentation of procedures and workflows should be part of the developers guide. This counts for topics related to bugs, releases and probably other things. Can we have a section on readthedocs where procedures and workflows can be placed? > Being Media Wiki READONLY, we thought this type of documents can be part > of Developer Guide for now. May be we need to sort the "developer guide" in > source code repo again and put it into correct buckets, but this needs > some time and effort. Yeah, we definitely should do that. And, also make sure that the old wiki gets replaced by appropriate redirects to prevent confusion. Thanks, Niels > > > [1] > > Because of the gerrit plugin issue, the commits in gerrit has not been > synced to github since Sep 10. However you can see the the change here > http://review.gluster.org/#/c/12227/ > > --Humble > > > On Mon, Oct 26, 2015 at 2:44 PM, Niels de Vos < nde...@redhat.com > wrote: > > > On Wed, Oct 21, 2015 at 05:22:49AM -0400, Nagaprasad Sathyanarayana wrote: > > > I came across the following BZs which are still open in mainline. But > > > they are fixed and made available in a upstream release. Planning to > > > close them this week, unless there are any objections. > > > > We have a policy to close bugs when their patches land in a released > > version. The bugs against mainline will get closed when a release is > > made that contains those fixes. For many of the current mainline bugs, > > this would be the case when glusterfs-3.8 is released. > > > > What is the concern of having bugs against the mainline version open > > until a release contains that particular fix? There are many bugs that > > also get backports to stable versions (3.7, 3.6 and 3.5). Those bugs get > > closed with each minor releases for that stable version. > > > > Of course we can change our policy to close mainline bugs earlier. But, > > we need to be consistent in setting the rules for that, and document > > them well. There is an ongoing task about automatically changing the > > status of bugs when patches get posted/merged and releases made. Closing > > mainline bugs should be part of that process. > > > > When do you suggest that a bug against mainline should be closed, when > > one of the stable releases containst the fix, or when all of them do? > > What version with fix should we point the users at when we closed a > > mainline bug? > > > > Our shiny docs (or my bookmarks?) are broken again... > > > > http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20report%20Life%20Cycle/ > > > > http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20Tria
Re: [Gluster-devel] Glusterfs mainline BZs to close...
Thanks Bipin for working on this! Your first PR Is merged and its live here http://gluster.readthedocs.org/en/latest/Workflow-Guide/Index/ :) Once all the workflow/procedure kind of docs are live in glusterdocs repo, we can remove it from "developer-guide" by placing a pointer to RTD. --Humble On Thu, Oct 29, 2015 at 5:38 PM, Bipin Kunal wrote: > Hello Niels/Humble, > > I would like to help you here and by this I can even start collaborating > in upstream. > > I will try to send first pull request very soon, late by next week. > > Thanks, > Bipin Kunal > > On Wed, Oct 28, 2015 at 5:04 PM, Niels de Vos wrote: > >> On Wed, Oct 28, 2015 at 04:02:16PM +0530, Humble Devassy Chirammal wrote: >> > Hi Niels, >> > >> > > >> > Our shiny docs (or my bookmarks?) are broken again... >> > >> > >> http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20report%20Life%20Cycle/ >> > >> http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20Triage/ >> > >> > > >> > As you know, the "Developer Guide" is now part of glusterfs source code >> ( >> > https://github.com/gluster/glusterfs/tree/master/doc/developer-guide) >> [1]. >> > The decision to split the glusterfs documentation into three parts ( >> > developer spec/feature , Administration ) came late and it caused the >> > bookmark to break. >> >> Right, but I do not think the documentation of procedures and workflows >> should be part of the developers guide. This counts for topics related >> to bugs, releases and probably other things. Can we have a section on >> readthedocs where procedures and workflows can be placed? >> >> > Being Media Wiki READONLY, we thought this type of documents can be >> part >> > of Developer Guide for now. May be we need to sort the "developer >> guide" in >> > source code repo again and put it into correct buckets, but this needs >> > some time and effort. >> >> Yeah, we definitely should do that. And, also make sure that the old >> wiki gets replaced by appropriate redirects to prevent confusion. >> >> Thanks, >> Niels >> >> > >> > >> > [1] >> > >> > Because of the gerrit plugin issue, the commits in gerrit has not been >> > synced to github since Sep 10. However you can see the the change here >> > http://review.gluster.org/#/c/12227/ >> > >> > --Humble >> > >> > >> > On Mon, Oct 26, 2015 at 2:44 PM, Niels de Vos >> wrote: >> > >> > > On Wed, Oct 21, 2015 at 05:22:49AM -0400, Nagaprasad Sathyanarayana >> wrote: >> > > > I came across the following BZs which are still open in mainline. >> But >> > > > they are fixed and made available in a upstream release. Planning >> to >> > > > close them this week, unless there are any objections. >> > > >> > > We have a policy to close bugs when their patches land in a released >> > > version. The bugs against mainline will get closed when a release is >> > > made that contains those fixes. For many of the current mainline bugs, >> > > this would be the case when glusterfs-3.8 is released. >> > > >> > > What is the concern of having bugs against the mainline version open >> > > until a release contains that particular fix? There are many bugs that >> > > also get backports to stable versions (3.7, 3.6 and 3.5). Those bugs >> get >> > > closed with each minor releases for that stable version. >> > > >> > > Of course we can change our policy to close mainline bugs earlier. >> But, >> > > we need to be consistent in setting the rules for that, and document >> > > them well. There is an ongoing task about automatically changing the >> > > status of bugs when patches get posted/merged and releases made. >> Closing >> > > mainline bugs should be part of that process. >> > > >> > > When do you suggest that a bug against mainline should be closed, when >> > > one of the stable releases containst the fix, or when all of them do? >> > > What version with fix should we point the users at when we closed a >> > > mainline bug? >> > > >> > > Our shiny docs (or my bookmarks?) are broken again... >> > > >> > > >> http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20report%20Life%20Cycle/ >> > > >> http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20Triage/ >> > > >> > > This is the old contents: >> > > >> > > >> http://www.gluster.org/community/documentation/index.php/Bug_report_life_cycle >> > > http://www.gluster.org/community/documentation/index.php/Bug_triage >> > > >> > > I was about to suggest to send a pull request so that we can discuss >> > > your proposal during the weekly Bug Triage meeting on Tuesdays. >> > > Unfortunately I don't know where the latest documents moved to, so >> > > please send your changes by email. >> > > >> > > Could you explain what Bugzilla query you used to find these bugs? We >> > > have some keywords (like "Tracking") that should be handled with care, >> > > and probably should not get closed even when patches were merged in >> > > mainline and stable releases. >> > > >> > > Thanks, >> > > Niels >> > > >> > > >> > > > >> > > > >
Re: [Gluster-devel] Glusterfs mainline BZs to close...
On Mon, Oct 26, 2015 at 08:42:34AM -0400, Kaleb S. KEITHLEY wrote: > On 10/26/2015 05:14 AM, Niels de Vos wrote: > > On Wed, Oct 21, 2015 at 05:22:49AM -0400, Nagaprasad Sathyanarayana wrote: > >> I came across the following BZs which are still open in mainline. But > >> they are fixed and made available in a upstream release. Planning to > >> close them this week, unless there are any objections. > > > > We have a policy to close bugs when their patches land in a released > > version. The bugs against mainline will get closed when a release is > > made that contains those fixes. For many of the current mainline bugs, > > this would be the case when glusterfs-3.8 is released. > > Some of those bugs are pretty old. We haven't been good about closing > them when a 3.X.0 release has occurred. I sent email to the lists about > closing some of the older ones with a note to reopen them if they're > still valid. > > The bugs with RFE in the subject, or RFE or FutureFeature as a keyword > need to be left open after a 3.X.0 release if appropriate. > > I'm going to take a stab at guessing — based on the date the bug was > filed — at changing the version of the non-RFE bugs filed against mainline. In addition to this, I have a script that 1. checks bugzilla for a list of open bugs 2. queries Gerrit for each bug 3. checks the git repository for tags of merged changes A run earlier today, gave this as result: http://termbin.com/puiz We seem to have quite some bugs that have all their changes merged in a branch, before a tagged release was made. Those bugs should have been closed when the stable release was announced. You can identify them when you search for "Bug should be CLOSED". There are also quite some bugs that had patches posted, but may have been abandoned, or the patch does not have a "BUG: 0123456" tag or correct topic. Those bugs are marked with "No change posted, but " ... These all need some review, and either get closed as a duplicate, moved back to "NEW" or "ASSIGNED", or anything else that helps the reporter to understand the status. For example: https://bugzilla.redhat.com/show_bug.cgi?id=1213821#c4 I'll probably add my script to https://github.com/gluster/release-tools so that others can improve it where needed. But for the time being, would it be helpful to have the output emailed to gluster-devel once every week? Niels ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Glusterfs mainline BZs to close...
On Thu, Oct 29, 2015 at 05:38:28PM +0530, Bipin Kunal wrote: > Hello Niels/Humble, > > I would like to help you here and by this I can even start collaborating in > upstream. > > I will try to send first pull request very soon, late by next week. Great, thanks! Let us know if you have any questions. Niels > > Thanks, > Bipin Kunal > > On Wed, Oct 28, 2015 at 5:04 PM, Niels de Vos wrote: > > > On Wed, Oct 28, 2015 at 04:02:16PM +0530, Humble Devassy Chirammal wrote: > > > Hi Niels, > > > > > > > > > > Our shiny docs (or my bookmarks?) are broken again... > > > > > > > > http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20report%20Life%20Cycle/ > > > http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20Triage/ > > > > > > > > > > As you know, the "Developer Guide" is now part of glusterfs source code ( > > > https://github.com/gluster/glusterfs/tree/master/doc/developer-guide) > > [1]. > > > The decision to split the glusterfs documentation into three parts ( > > > developer spec/feature , Administration ) came late and it caused the > > > bookmark to break. > > > > Right, but I do not think the documentation of procedures and workflows > > should be part of the developers guide. This counts for topics related > > to bugs, releases and probably other things. Can we have a section on > > readthedocs where procedures and workflows can be placed? > > > > > Being Media Wiki READONLY, we thought this type of documents can be part > > > of Developer Guide for now. May be we need to sort the "developer guide" > > in > > > source code repo again and put it into correct buckets, but this needs > > > some time and effort. > > > > Yeah, we definitely should do that. And, also make sure that the old > > wiki gets replaced by appropriate redirects to prevent confusion. > > > > Thanks, > > Niels > > > > > > > > > > > [1] > > > > > > Because of the gerrit plugin issue, the commits in gerrit has not been > > > synced to github since Sep 10. However you can see the the change here > > > http://review.gluster.org/#/c/12227/ > > > > > > --Humble > > > > > > > > > On Mon, Oct 26, 2015 at 2:44 PM, Niels de Vos wrote: > > > > > > > On Wed, Oct 21, 2015 at 05:22:49AM -0400, Nagaprasad Sathyanarayana > > wrote: > > > > > I came across the following BZs which are still open in mainline. > > But > > > > > they are fixed and made available in a upstream release. Planning to > > > > > close them this week, unless there are any objections. > > > > > > > > We have a policy to close bugs when their patches land in a released > > > > version. The bugs against mainline will get closed when a release is > > > > made that contains those fixes. For many of the current mainline bugs, > > > > this would be the case when glusterfs-3.8 is released. > > > > > > > > What is the concern of having bugs against the mainline version open > > > > until a release contains that particular fix? There are many bugs that > > > > also get backports to stable versions (3.7, 3.6 and 3.5). Those bugs > > get > > > > closed with each minor releases for that stable version. > > > > > > > > Of course we can change our policy to close mainline bugs earlier. But, > > > > we need to be consistent in setting the rules for that, and document > > > > them well. There is an ongoing task about automatically changing the > > > > status of bugs when patches get posted/merged and releases made. > > Closing > > > > mainline bugs should be part of that process. > > > > > > > > When do you suggest that a bug against mainline should be closed, when > > > > one of the stable releases containst the fix, or when all of them do? > > > > What version with fix should we point the users at when we closed a > > > > mainline bug? > > > > > > > > Our shiny docs (or my bookmarks?) are broken again... > > > > > > > > > > http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20report%20Life%20Cycle/ > > > > > > http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20Triage/ > > > > > > > > This is the old contents: > > > > > > > > > > http://www.gluster.org/community/documentation/index.php/Bug_report_life_cycle > > > > http://www.gluster.org/community/documentation/index.php/Bug_triage > > > > > > > > I was about to suggest to send a pull request so that we can discuss > > > > your proposal during the weekly Bug Triage meeting on Tuesdays. > > > > Unfortunately I don't know where the latest documents moved to, so > > > > please send your changes by email. > > > > > > > > Could you explain what Bugzilla query you used to find these bugs? We > > > > have some keywords (like "Tracking") that should be handled with care, > > > > and probably should not get closed even when patches were merged in > > > > mainline and stable releases. > > > > > > > > Thanks, > > > > Niels > > > > > > > > > > > > > > > > > > > > > > > > 1211836,1212398,1211132,1215486,1213542,1212385,1210687,1209818,1210690,1215187,1215161,1214574,1218120,1217788,1216067,12
Re: [Gluster-devel] Glusterfs mainline BZs to close...
Hello Niels/Humble, I would like to help you here and by this I can even start collaborating in upstream. I will try to send first pull request very soon, late by next week. Thanks, Bipin Kunal On Wed, Oct 28, 2015 at 5:04 PM, Niels de Vos wrote: > On Wed, Oct 28, 2015 at 04:02:16PM +0530, Humble Devassy Chirammal wrote: > > Hi Niels, > > > > > > > Our shiny docs (or my bookmarks?) are broken again... > > > > > http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20report%20Life%20Cycle/ > > http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20Triage/ > > > > > > > As you know, the "Developer Guide" is now part of glusterfs source code ( > > https://github.com/gluster/glusterfs/tree/master/doc/developer-guide) > [1]. > > The decision to split the glusterfs documentation into three parts ( > > developer spec/feature , Administration ) came late and it caused the > > bookmark to break. > > Right, but I do not think the documentation of procedures and workflows > should be part of the developers guide. This counts for topics related > to bugs, releases and probably other things. Can we have a section on > readthedocs where procedures and workflows can be placed? > > > Being Media Wiki READONLY, we thought this type of documents can be part > > of Developer Guide for now. May be we need to sort the "developer guide" > in > > source code repo again and put it into correct buckets, but this needs > > some time and effort. > > Yeah, we definitely should do that. And, also make sure that the old > wiki gets replaced by appropriate redirects to prevent confusion. > > Thanks, > Niels > > > > > > > [1] > > > > Because of the gerrit plugin issue, the commits in gerrit has not been > > synced to github since Sep 10. However you can see the the change here > > http://review.gluster.org/#/c/12227/ > > > > --Humble > > > > > > On Mon, Oct 26, 2015 at 2:44 PM, Niels de Vos wrote: > > > > > On Wed, Oct 21, 2015 at 05:22:49AM -0400, Nagaprasad Sathyanarayana > wrote: > > > > I came across the following BZs which are still open in mainline. > But > > > > they are fixed and made available in a upstream release. Planning to > > > > close them this week, unless there are any objections. > > > > > > We have a policy to close bugs when their patches land in a released > > > version. The bugs against mainline will get closed when a release is > > > made that contains those fixes. For many of the current mainline bugs, > > > this would be the case when glusterfs-3.8 is released. > > > > > > What is the concern of having bugs against the mainline version open > > > until a release contains that particular fix? There are many bugs that > > > also get backports to stable versions (3.7, 3.6 and 3.5). Those bugs > get > > > closed with each minor releases for that stable version. > > > > > > Of course we can change our policy to close mainline bugs earlier. But, > > > we need to be consistent in setting the rules for that, and document > > > them well. There is an ongoing task about automatically changing the > > > status of bugs when patches get posted/merged and releases made. > Closing > > > mainline bugs should be part of that process. > > > > > > When do you suggest that a bug against mainline should be closed, when > > > one of the stable releases containst the fix, or when all of them do? > > > What version with fix should we point the users at when we closed a > > > mainline bug? > > > > > > Our shiny docs (or my bookmarks?) are broken again... > > > > > > > http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20report%20Life%20Cycle/ > > > > http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20Triage/ > > > > > > This is the old contents: > > > > > > > http://www.gluster.org/community/documentation/index.php/Bug_report_life_cycle > > > http://www.gluster.org/community/documentation/index.php/Bug_triage > > > > > > I was about to suggest to send a pull request so that we can discuss > > > your proposal during the weekly Bug Triage meeting on Tuesdays. > > > Unfortunately I don't know where the latest documents moved to, so > > > please send your changes by email. > > > > > > Could you explain what Bugzilla query you used to find these bugs? We > > > have some keywords (like "Tracking") that should be handled with care, > > > and probably should not get closed even when patches were merged in > > > mainline and stable releases. > > > > > > Thanks, > > > Niels > > > > > > > > > > > > > > > > > > 1211836,1212398,1211132,1215486,1213542,1212385,1210687,1209818,1210690,1215187,1215161,1214574,1218120,1217788,1216067,1213773,1210684,1209104,1217937,1200262,1204651,1211913,1211594,1163561,1176062, > > > > > > > > 1219784,1176837,1208131,1200704,1220329,1221095,1172430,1219732,1219738,1213295,1212253,1211808,1207615,1216931,1224290,1217701,1223213,1223889,1223385,1221104,1221696,1219442,1224596,1165041,1225491, > > > > > > > > 1221938,1226367,1215002,1222379,1221889,1220332,1223338
Re: [Gluster-devel] Glusterfs mainline BZs to close...
On Wed, Oct 28, 2015 at 04:02:16PM +0530, Humble Devassy Chirammal wrote: > Hi Niels, > > > > Our shiny docs (or my bookmarks?) are broken again... > > http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20report%20Life%20Cycle/ > http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20Triage/ > > > > As you know, the "Developer Guide" is now part of glusterfs source code ( > https://github.com/gluster/glusterfs/tree/master/doc/developer-guide) [1]. > The decision to split the glusterfs documentation into three parts ( > developer spec/feature , Administration ) came late and it caused the > bookmark to break. Right, but I do not think the documentation of procedures and workflows should be part of the developers guide. This counts for topics related to bugs, releases and probably other things. Can we have a section on readthedocs where procedures and workflows can be placed? > Being Media Wiki READONLY, we thought this type of documents can be part > of Developer Guide for now. May be we need to sort the "developer guide" in > source code repo again and put it into correct buckets, but this needs > some time and effort. Yeah, we definitely should do that. And, also make sure that the old wiki gets replaced by appropriate redirects to prevent confusion. Thanks, Niels > > > [1] > > Because of the gerrit plugin issue, the commits in gerrit has not been > synced to github since Sep 10. However you can see the the change here > http://review.gluster.org/#/c/12227/ > > --Humble > > > On Mon, Oct 26, 2015 at 2:44 PM, Niels de Vos wrote: > > > On Wed, Oct 21, 2015 at 05:22:49AM -0400, Nagaprasad Sathyanarayana wrote: > > > I came across the following BZs which are still open in mainline. But > > > they are fixed and made available in a upstream release. Planning to > > > close them this week, unless there are any objections. > > > > We have a policy to close bugs when their patches land in a released > > version. The bugs against mainline will get closed when a release is > > made that contains those fixes. For many of the current mainline bugs, > > this would be the case when glusterfs-3.8 is released. > > > > What is the concern of having bugs against the mainline version open > > until a release contains that particular fix? There are many bugs that > > also get backports to stable versions (3.7, 3.6 and 3.5). Those bugs get > > closed with each minor releases for that stable version. > > > > Of course we can change our policy to close mainline bugs earlier. But, > > we need to be consistent in setting the rules for that, and document > > them well. There is an ongoing task about automatically changing the > > status of bugs when patches get posted/merged and releases made. Closing > > mainline bugs should be part of that process. > > > > When do you suggest that a bug against mainline should be closed, when > > one of the stable releases containst the fix, or when all of them do? > > What version with fix should we point the users at when we closed a > > mainline bug? > > > > Our shiny docs (or my bookmarks?) are broken again... > > > > http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20report%20Life%20Cycle/ > > http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20Triage/ > > > > This is the old contents: > > > > http://www.gluster.org/community/documentation/index.php/Bug_report_life_cycle > > http://www.gluster.org/community/documentation/index.php/Bug_triage > > > > I was about to suggest to send a pull request so that we can discuss > > your proposal during the weekly Bug Triage meeting on Tuesdays. > > Unfortunately I don't know where the latest documents moved to, so > > please send your changes by email. > > > > Could you explain what Bugzilla query you used to find these bugs? We > > have some keywords (like "Tracking") that should be handled with care, > > and probably should not get closed even when patches were merged in > > mainline and stable releases. > > > > Thanks, > > Niels > > > > > > > > > > > > 1211836,1212398,1211132,1215486,1213542,1212385,1210687,1209818,1210690,1215187,1215161,1214574,1218120,1217788,1216067,1213773,1210684,1209104,1217937,1200262,1204651,1211913,1211594,1163561,1176062, > > > > > 1219784,1176837,1208131,1200704,1220329,1221095,1172430,1219732,1219738,1213295,1212253,1211808,1207615,1216931,1224290,1217701,1223213,1223889,1223385,1221104,1221696,1219442,1224596,1165041,1225491, > > > > > 1221938,1226367,1215002,1222379,1221889,1220332,1223338,1224600,1222126,1212413,1211123,1225793,1226551,1218055,1220713,1223772,1222013,1227646,1228635,1227884,1224016,1223432,1227904,1228952,1228613, > > > > > 1209461,1226507,1225572,1227449,1220670,1225564,1225424,1200267,1229825,1230121,1228696,1228680,1229609,1229134,1231425,1229172,1232729,1208482,1169317,1180545,1231197,1188242,1229658,1232686,1234842, > > > > > 1235216,1235359,1235195,1235007,1232238,1233617,1235542,1233162,1233258,1193388,1238072,1236270,12
Re: [Gluster-devel] Glusterfs mainline BZs to close...
Hi Niels, > Our shiny docs (or my bookmarks?) are broken again... http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20report%20Life%20Cycle/ http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20Triage/ > As you know, the "Developer Guide" is now part of glusterfs source code ( https://github.com/gluster/glusterfs/tree/master/doc/developer-guide) [1]. The decision to split the glusterfs documentation into three parts ( developer spec/feature , Administration ) came late and it caused the bookmark to break. Being Media Wiki READONLY, we thought this type of documents can be part of Developer Guide for now. May be we need to sort the "developer guide" in source code repo again and put it into correct buckets, but this needs some time and effort. [1] Because of the gerrit plugin issue, the commits in gerrit has not been synced to github since Sep 10. However you can see the the change here http://review.gluster.org/#/c/12227/ --Humble On Mon, Oct 26, 2015 at 2:44 PM, Niels de Vos wrote: > On Wed, Oct 21, 2015 at 05:22:49AM -0400, Nagaprasad Sathyanarayana wrote: > > I came across the following BZs which are still open in mainline. But > > they are fixed and made available in a upstream release. Planning to > > close them this week, unless there are any objections. > > We have a policy to close bugs when their patches land in a released > version. The bugs against mainline will get closed when a release is > made that contains those fixes. For many of the current mainline bugs, > this would be the case when glusterfs-3.8 is released. > > What is the concern of having bugs against the mainline version open > until a release contains that particular fix? There are many bugs that > also get backports to stable versions (3.7, 3.6 and 3.5). Those bugs get > closed with each minor releases for that stable version. > > Of course we can change our policy to close mainline bugs earlier. But, > we need to be consistent in setting the rules for that, and document > them well. There is an ongoing task about automatically changing the > status of bugs when patches get posted/merged and releases made. Closing > mainline bugs should be part of that process. > > When do you suggest that a bug against mainline should be closed, when > one of the stable releases containst the fix, or when all of them do? > What version with fix should we point the users at when we closed a > mainline bug? > > Our shiny docs (or my bookmarks?) are broken again... > > http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20report%20Life%20Cycle/ > http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20Triage/ > > This is the old contents: > > http://www.gluster.org/community/documentation/index.php/Bug_report_life_cycle > http://www.gluster.org/community/documentation/index.php/Bug_triage > > I was about to suggest to send a pull request so that we can discuss > your proposal during the weekly Bug Triage meeting on Tuesdays. > Unfortunately I don't know where the latest documents moved to, so > please send your changes by email. > > Could you explain what Bugzilla query you used to find these bugs? We > have some keywords (like "Tracking") that should be handled with care, > and probably should not get closed even when patches were merged in > mainline and stable releases. > > Thanks, > Niels > > > > > > > 1211836,1212398,1211132,1215486,1213542,1212385,1210687,1209818,1210690,1215187,1215161,1214574,1218120,1217788,1216067,1213773,1210684,1209104,1217937,1200262,1204651,1211913,1211594,1163561,1176062, > > > 1219784,1176837,1208131,1200704,1220329,1221095,1172430,1219732,1219738,1213295,1212253,1211808,1207615,1216931,1224290,1217701,1223213,1223889,1223385,1221104,1221696,1219442,1224596,1165041,1225491, > > > 1221938,1226367,1215002,1222379,1221889,1220332,1223338,1224600,1222126,1212413,1211123,1225793,1226551,1218055,1220713,1223772,1222013,1227646,1228635,1227884,1224016,1223432,1227904,1228952,1228613, > > > 1209461,1226507,1225572,1227449,1220670,1225564,1225424,1200267,1229825,1230121,1228696,1228680,1229609,1229134,1231425,1229172,1232729,1208482,1169317,1180545,1231197,1188242,1229658,1232686,1234842, > > > 1235216,1235359,1235195,1235007,1232238,1233617,1235542,1233162,1233258,1193388,1238072,1236270,1237381,1238508,1230007,1210689,1240254,1240564,1241153,1193636,1132465,1226717,1242609,1238747,1242875, > > > 1226279,1240210,1232678,1242254,1232391,1242570,1235231,1240654,1240284,1215117,1240184,1228520,1244165,1243187,1243774,1209430,1196027,1232572,1202244,1229297,1246052,1246082,1238135,1245547,1234819, > > > 1224611,1221914,1207134,1245981,1246432,1178619,1243890,1240598,1240949,1247930,1247108,1245544,1238936,1232420,1245142,1226223,1250441,1229860,1245276,1246275,1250582,1249499,1231437,1241274,1212437, > > > 1245558,1250855,1226829,1230015,1251042,1209329,1235582,1251449,1248415,1245895,1221490,1250797,1240991,1243391,1240218,1207829,1236009,1244613,1255599,1213349
Re: [Gluster-devel] Glusterfs mainline BZs to close...
On 10/26/2015 05:14 AM, Niels de Vos wrote: > On Wed, Oct 21, 2015 at 05:22:49AM -0400, Nagaprasad Sathyanarayana wrote: >> I came across the following BZs which are still open in mainline. But >> they are fixed and made available in a upstream release. Planning to >> close them this week, unless there are any objections. > > We have a policy to close bugs when their patches land in a released > version. The bugs against mainline will get closed when a release is > made that contains those fixes. For many of the current mainline bugs, > this would be the case when glusterfs-3.8 is released. Some of those bugs are pretty old. We haven't been good about closing them when a 3.X.0 release has occurred. I sent email to the lists about closing some of the older ones with a note to reopen them if they're still valid. The bugs with RFE in the subject, or RFE or FutureFeature as a keyword need to be left open after a 3.X.0 release if appropriate. I'm going to take a stab at guessing — based on the date the bug was filed — at changing the version of the non-RFE bugs filed against mainline. > > What is the concern of having bugs against the mainline version open > until a release contains that particular fix? There are many bugs that > also get backports to stable versions (3.7, 3.6 and 3.5). Those bugs get > closed with each minor releases for that stable version. > > Of course we can change our policy to close mainline bugs earlier. But, > we need to be consistent in setting the rules for that, and document > them well. There is an ongoing task about automatically changing the > status of bugs when patches get posted/merged and releases made. Closing > mainline bugs should be part of that process. > > When do you suggest that a bug against mainline should be closed, when > one of the stable releases containst the fix, or when all of them do? > What version with fix should we point the users at when we closed a > mainline bug? > > Our shiny docs (or my bookmarks?) are broken again... > > http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20report%20Life%20Cycle/ > http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20Triage/ > > This is the old contents: > > http://www.gluster.org/community/documentation/index.php/Bug_report_life_cycle > http://www.gluster.org/community/documentation/index.php/Bug_triage > > I was about to suggest to send a pull request so that we can discuss > your proposal during the weekly Bug Triage meeting on Tuesdays. > Unfortunately I don't know where the latest documents moved to, so > please send your changes by email. > > Could you explain what Bugzilla query you used to find these bugs? We > have some keywords (like "Tracking") that should be handled with care, > and probably should not get closed even when patches were merged in > mainline and stable releases. > > Thanks, > Niels > > >> >> 1211836,1212398,1211132,1215486,1213542,1212385,1210687,1209818,1210690,1215187,1215161,1214574,1218120,1217788,1216067,1213773,1210684,1209104,1217937,1200262,1204651,1211913,1211594,1163561,1176062, >> 1219784,1176837,1208131,1200704,1220329,1221095,1172430,1219732,1219738,1213295,1212253,1211808,1207615,1216931,1224290,1217701,1223213,1223889,1223385,1221104,1221696,1219442,1224596,1165041,1225491, >> 1221938,1226367,1215002,1222379,1221889,1220332,1223338,1224600,1222126,1212413,1211123,1225793,1226551,1218055,1220713,1223772,1222013,1227646,1228635,1227884,1224016,1223432,1227904,1228952,1228613, >> 1209461,1226507,1225572,1227449,1220670,1225564,1225424,1200267,1229825,1230121,1228696,1228680,1229609,1229134,1231425,1229172,1232729,1208482,1169317,1180545,1231197,1188242,1229658,1232686,1234842, >> 1235216,1235359,1235195,1235007,1232238,1233617,1235542,1233162,1233258,1193388,1238072,1236270,1237381,1238508,1230007,1210689,1240254,1240564,1241153,1193636,1132465,1226717,1242609,1238747,1242875, >> 1226279,1240210,1232678,1242254,1232391,1242570,1235231,1240654,1240284,1215117,1240184,1228520,1244165,1243187,1243774,1209430,1196027,1232572,1202244,1229297,1246052,1246082,1238135,1245547,1234819, >> 1224611,1221914,1207134,1245981,1246432,1178619,1243890,1240598,1240949,1247930,1247108,1245544,1238936,1232420,1245142,1226223,1250441,1229860,1245276,1246275,1250582,1249499,1231437,1241274,1212437, >> 1245558,1250855,1226829,1230015,1251042,1209329,1235582,1251449,1248415,1245895,1221490,1250797,1240991,1243391,1240218,1207829,1236009,1244613,1255599,1213349,1232378,1225465,1254127,1250170,1240244, >> 1245045,1254863,1242819,1242421,1256580,1251824,1252808,1251454,1258334,1205596,1242742,1205037,1212823,1209735,1210712,1229948,1232001,1234474,1242030,1241133,1241480,1242041,1252410,1232430,1231876, >> 1218573,1240952,1233544,1244109,1239269,1218164,1218060,1211640,1204641,1230090,1225571,1231205,1232666,1234882,1235292,1234694,1233411,1231789,1240229,1239044,1247529,1207735,1251346,1200254,1200265, >> 1251857,1241895,1233246,1238054,1233624,1221131,1
Re: [Gluster-devel] Glusterfs mainline BZs to close...
On Wed, Oct 21, 2015 at 05:22:49AM -0400, Nagaprasad Sathyanarayana wrote: > I came across the following BZs which are still open in mainline. But > they are fixed and made available in a upstream release. Planning to > close them this week, unless there are any objections. We have a policy to close bugs when their patches land in a released version. The bugs against mainline will get closed when a release is made that contains those fixes. For many of the current mainline bugs, this would be the case when glusterfs-3.8 is released. What is the concern of having bugs against the mainline version open until a release contains that particular fix? There are many bugs that also get backports to stable versions (3.7, 3.6 and 3.5). Those bugs get closed with each minor releases for that stable version. Of course we can change our policy to close mainline bugs earlier. But, we need to be consistent in setting the rules for that, and document them well. There is an ongoing task about automatically changing the status of bugs when patches get posted/merged and releases made. Closing mainline bugs should be part of that process. When do you suggest that a bug against mainline should be closed, when one of the stable releases containst the fix, or when all of them do? What version with fix should we point the users at when we closed a mainline bug? Our shiny docs (or my bookmarks?) are broken again... http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20report%20Life%20Cycle/ http://gluster.readthedocs.org/en/latest/Developer-guide/Bug%20Triage/ This is the old contents: http://www.gluster.org/community/documentation/index.php/Bug_report_life_cycle http://www.gluster.org/community/documentation/index.php/Bug_triage I was about to suggest to send a pull request so that we can discuss your proposal during the weekly Bug Triage meeting on Tuesdays. Unfortunately I don't know where the latest documents moved to, so please send your changes by email. Could you explain what Bugzilla query you used to find these bugs? We have some keywords (like "Tracking") that should be handled with care, and probably should not get closed even when patches were merged in mainline and stable releases. Thanks, Niels > > 1211836,1212398,1211132,1215486,1213542,1212385,1210687,1209818,1210690,1215187,1215161,1214574,1218120,1217788,1216067,1213773,1210684,1209104,1217937,1200262,1204651,1211913,1211594,1163561,1176062, > 1219784,1176837,1208131,1200704,1220329,1221095,1172430,1219732,1219738,1213295,1212253,1211808,1207615,1216931,1224290,1217701,1223213,1223889,1223385,1221104,1221696,1219442,1224596,1165041,1225491, > 1221938,1226367,1215002,1222379,1221889,1220332,1223338,1224600,1222126,1212413,1211123,1225793,1226551,1218055,1220713,1223772,1222013,1227646,1228635,1227884,1224016,1223432,1227904,1228952,1228613, > 1209461,1226507,1225572,1227449,1220670,1225564,1225424,1200267,1229825,1230121,1228696,1228680,1229609,1229134,1231425,1229172,1232729,1208482,1169317,1180545,1231197,1188242,1229658,1232686,1234842, > 1235216,1235359,1235195,1235007,1232238,1233617,1235542,1233162,1233258,1193388,1238072,1236270,1237381,1238508,1230007,1210689,1240254,1240564,1241153,1193636,1132465,1226717,1242609,1238747,1242875, > 1226279,1240210,1232678,1242254,1232391,1242570,1235231,1240654,1240284,1215117,1240184,1228520,1244165,1243187,1243774,1209430,1196027,1232572,1202244,1229297,1246052,1246082,1238135,1245547,1234819, > 1224611,1221914,1207134,1245981,1246432,1178619,1243890,1240598,1240949,1247930,1247108,1245544,1238936,1232420,1245142,1226223,1250441,1229860,1245276,1246275,1250582,1249499,1231437,1241274,1212437, > 1245558,1250855,1226829,1230015,1251042,1209329,1235582,1251449,1248415,1245895,1221490,1250797,1240991,1243391,1240218,1207829,1236009,1244613,1255599,1213349,1232378,1225465,1254127,1250170,1240244, > 1245045,1254863,1242819,1242421,1256580,1251824,1252808,1251454,1258334,1205596,1242742,1205037,1212823,1209735,1210712,1229948,1232001,1234474,1242030,1241133,1241480,1242041,1252410,1232430,1231876, > 1218573,1240952,1233544,1244109,1239269,1218164,1218060,1211640,1204641,1230090,1225571,1231205,1232666,1234882,1235292,1234694,1233411,1231789,1240229,1239044,1247529,1207735,1251346,1200254,1200265, > 1251857,1241895,1233246,1238054,1233624,1221131,1213752,1218854,1231738,1231257,1236561,1228415,1202758,1238188,1229139,1225328,1254167,1252825,1253309,1255310,1248298,1248521,1199985,1219637,1200082, > 1210344,1260730,1231268,1218287,1216898,1217786,1205540,1214048,1213125,1240621,1214219,1213063,1215571,1240970,1236212,1245935,1254451,1248306,1238593,1218717,1250828,1215896,1235269,1211562,1206546, > 1215660,1222840,1216960,1205624,1241054,1211570,1228112,1227803,1251121,1214222,1219032,1252121,1215122,1211264,1205545,1221270,1236128,1226881,1240577,1225330,1207029,1226005,1226307,1243753 > > Regards > Naga > ___ > Gluster-devel mailing list > Gluste
[Gluster-devel] Glusterfs mainline BZs to close...
I came across the following BZs which are still open in mainline. But they are fixed and made available in a upstream release. Planning to close them this week, unless there are any objections. 1211836,1212398,1211132,1215486,1213542,1212385,1210687,1209818,1210690,1215187,1215161,1214574,1218120,1217788,1216067,1213773,1210684,1209104,1217937,1200262,1204651,1211913,1211594,1163561,1176062, 1219784,1176837,1208131,1200704,1220329,1221095,1172430,1219732,1219738,1213295,1212253,1211808,1207615,1216931,1224290,1217701,1223213,1223889,1223385,1221104,1221696,1219442,1224596,1165041,1225491, 1221938,1226367,1215002,1222379,1221889,1220332,1223338,1224600,1222126,1212413,1211123,1225793,1226551,1218055,1220713,1223772,1222013,1227646,1228635,1227884,1224016,1223432,1227904,1228952,1228613, 1209461,1226507,1225572,1227449,1220670,1225564,1225424,1200267,1229825,1230121,1228696,1228680,1229609,1229134,1231425,1229172,1232729,1208482,1169317,1180545,1231197,1188242,1229658,1232686,1234842, 1235216,1235359,1235195,1235007,1232238,1233617,1235542,1233162,1233258,1193388,1238072,1236270,1237381,1238508,1230007,1210689,1240254,1240564,1241153,1193636,1132465,1226717,1242609,1238747,1242875, 1226279,1240210,1232678,1242254,1232391,1242570,1235231,1240654,1240284,1215117,1240184,1228520,1244165,1243187,1243774,1209430,1196027,1232572,1202244,1229297,1246052,1246082,1238135,1245547,1234819, 1224611,1221914,1207134,1245981,1246432,1178619,1243890,1240598,1240949,1247930,1247108,1245544,1238936,1232420,1245142,1226223,1250441,1229860,1245276,1246275,1250582,1249499,1231437,1241274,1212437, 1245558,1250855,1226829,1230015,1251042,1209329,1235582,1251449,1248415,1245895,1221490,1250797,1240991,1243391,1240218,1207829,1236009,1244613,1255599,1213349,1232378,1225465,1254127,1250170,1240244, 1245045,1254863,1242819,1242421,1256580,1251824,1252808,1251454,1258334,1205596,1242742,1205037,1212823,1209735,1210712,1229948,1232001,1234474,1242030,1241133,1241480,1242041,1252410,1232430,1231876, 1218573,1240952,1233544,1244109,1239269,1218164,1218060,1211640,1204641,1230090,1225571,1231205,1232666,1234882,1235292,1234694,1233411,1231789,1240229,1239044,1247529,1207735,1251346,1200254,1200265, 1251857,1241895,1233246,1238054,1233624,1221131,1213752,1218854,1231738,1231257,1236561,1228415,1202758,1238188,1229139,1225328,1254167,1252825,1253309,1255310,1248298,1248521,1199985,1219637,1200082, 1210344,1260730,1231268,1218287,1216898,1217786,1205540,1214048,1213125,1240621,1214219,1213063,1215571,1240970,1236212,1245935,1254451,1248306,1238593,1218717,1250828,1215896,1235269,1211562,1206546, 1215660,1222840,1216960,1205624,1241054,1211570,1228112,1227803,1251121,1214222,1219032,1252121,1215122,1211264,1205545,1221270,1236128,1226881,1240577,1225330,1207029,1226005,1226307,1243753 Regards Naga ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
