Re: Bugzilla flow (Re: Add 2.2.4 to bugzilla)
Hi, What I'm most unhappy about is that we have 783 bugs in New, Assigned, Reopened, NeedInfo... that seems like quite a lot. Perhaps Then let's start and solve two of the 783 so we can these cross off the list +---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | |19182|New|Blk|2003-04-20|SSLMutex field in ssl.conf needs to be updated. | |28923|New|Nor|2004-05-12|Invalid argument for SSLMutex in ./docs/conf/ssl-s| It is my understanding that 'default' is the right choose, and the platform for what Apache2 gets compiled should choose the right default - probably with defines in the code. If this is not appropriate then please make a decision and close both bugs, and tell me that its required to patch the build process so that it can be fixed by the time when the final httpd-ssl.conf gets created from httpd-ssl.conf.in ... Currently with the 2.2.4 release on Win32 I see that it gets now fixed during build process generation of httpd-ssl.conf; Makefile.win line 686 - file date from 07-Dec-2006: gsub( /SSLMutex file:@[EMAIL PROTECTED]/ssl_mutex/, SSLMutex default ); so if that is now the right way to go let me know, and I will look for a patch for NetWare so that we can do same there too, and close those bugs finally. Nevertheless I believe this should get fixed on the Unix side so that every platform is happy with 'default' rather than doing substitutions during the generation of the conf. Currently there are two platforms (Win32 and NetWare) which are only happy with 'SSLMutex default'. Also it seems that anyway there happens substitution on Unix/Linux to replace @exp_runtimedir@ with a valid directory - so I would tend to do the substitution only on these platforms where its anyway required already, and let the other two just copy the 'SSLMutex default' unchanged; with current new approach we have to substitute on every platform. thanks, Guenter.
Re: Bugzilla flow (Re: Add 2.2.4 to bugzilla)
Hi, What I'm most unhappy about is that we have 783 bugs in New, Assigned, Reopened, NeedInfo... that seems like quite a lot. Perhaps Then let's start and solve two of the 783 so we can these cross off the list +---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | |19182|New|Blk|2003-04-20|SSLMutex field in ssl.conf needs to be updated. | |28923|New|Nor|2004-05-12|Invalid argument for SSLMutex in ./docs/conf/ssl-s| It is my understanding that 'default' is the right choose, and the platform for what Apache2 gets compiled should choose the right default - probably with defines in the code. If this is not appropriate then please make a decision and close both bugs, and tell me that its required to patch the build process so that it can be fixed by the time when the final httpd-ssl.conf gets created from httpd-ssl.conf.in ... On Win32 I see that it gets now fixed during build process generation of httpd-ssl.conf http://svn.apache.org/viewvc/httpd/httpd/trunk/Makefile.win?r1=397647r2=398284 so if that is now the right way to go let me know - I've already created a patch for NetWare so that we can do same there too - see attachment (the patch fixes also some other issues with NetWare httpd-ssl.conf). I've just closed #19182 cause I believe with above mentioned commit its now fixed for Win32. If Brad agrees and commits my patch then we can also close #28923 finally. Nevertheless I believe this should get fixed on the Unix side so that every platform is happy with 'default' rather than doing substitutions during the generation of the conf. Currently there are two platforms (Win32 and NetWare) which are only happy with 'SSLMutex default'. Also it seems that anyway there happens substitution on Unix/Linux to replace @exp_runtimedir@ with a valid directory - so I would tend to do the substitution only on these platforms where its anyway required already, and let the other two just copy the 'SSLMutex default' unchanged; with current new approach we have to substitute on every platform. Another question: why differ the placeholders for the log file directories between httpd.conf.in and extra/httpd-ssl.conf.in ? httpd.conf.in line 184: ErrorLog @rel_logfiledir@/error_log httpd-ssl.conf.in line 80: ErrorLog @exp_logfiledir@/error_log TransferLog @exp_logfiledir@/access_log shouldnt this be same directory also on Unix? thanks, Guenter. mkconfNW.awk.diff Description: Binary data
Re: Add 2.2.4 to bugzilla
On Thu, Jan 11, 2007 at 10:11:18PM -0800, Sander Temme wrote: On Jan 11, 2007, at 1:40 PM, Ruediger Pluem wrote: A week sounds good to me. I guess some of them are my fault as I only set them to resolved fixed and never visited them again as I thought that they reached their final state. Now I found out that you only have the option to close it once it has moved to a 'resolved' state and 'closed' should be the final state. I will take better care of this in the future. Is there any chance to close all the ones in resolved state that have not been touched for a week in one blow? Absolutely. You can operate on the entire contents of a query result... which gets the job done and will send lots of e-mail. Yes, Closed should be the final resting place for bug reports, for good or for bad. What is the difference between a RESOLVED bug and a CLOSED one? Is it not possible to re-open/add comments to CLOSED reports or something? It's always seemed like a meaningless distinction to me, going through marking stuff CLOSED seems like a spam generation exercise. joe
Re: Add 2.2.4 to bugzilla
On Jan 12, 2007, at 3:33 AM, Joe Orton wrote: What is the difference between a RESOLVED bug and a CLOSED one? Is it not possible to re-open/add comments to CLOSED reports or something? It's always seemed like a meaningless distinction to me, going through marking stuff CLOSED seems like a spam generation exercise. Theoretically, issues are resolved when they are fixed on trunk and closed when the fix is included in any release. Roy
Re: Add 2.2.4 to bugzilla
Joe Orton wrote: On Thu, Jan 11, 2007 at 10:11:18PM -0800, Sander Temme wrote: Yes, Closed should be the final resting place for bug reports, for good or for bad. What is the difference between a RESOLVED bug and a CLOSED one? Is it not possible to re-open/add comments to CLOSED reports or something? It's always seemed like a meaningless distinction to me, going through marking stuff CLOSED seems like a spam generation exercise. Unless we provide real post mortem processes in the transition of the various resolutions into a CLOSED state, I agree. They are functionally equivalent for our process and we could probably lose the 'CLOSED' class all together.
Re: Add 2.2.4 to bugzilla
On Jan 12, 2007, at 1:04 PM, Roy T. Fielding wrote: On Jan 12, 2007, at 3:33 AM, Joe Orton wrote: What is the difference between a RESOLVED bug and a CLOSED one? Is it not possible to re-open/add comments to CLOSED reports or something? It's always seemed like a meaningless distinction to me, going through marking stuff CLOSED seems like a spam generation exercise. Theoretically, issues are resolved when they are fixed on trunk and closed when the fix is included in any release. I like this because it imposes branch management where Bugzilla itself has none. S. -- [EMAIL PROTECTED]http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: Add 2.2.4 to bugzilla
On 01/12/2007 11:14 PM, Sander Temme wrote: On Jan 12, 2007, at 1:04 PM, Roy T. Fielding wrote: On Jan 12, 2007, at 3:33 AM, Joe Orton wrote: What is the difference between a RESOLVED bug and a CLOSED one? Is it not possible to re-open/add comments to CLOSED reports or something? It's always seemed like a meaningless distinction to me, going through marking stuff CLOSED seems like a spam generation exercise. Theoretically, issues are resolved when they are fixed on trunk and closed when the fix is included in any release. I like this because it imposes branch management where Bugzilla itself has none. Sounds good to me. So far I used the following process for myself: 1. Fix on trunk = Leave state in Needinfo and add a comment with revision of fix. 2. Proposed for backport = Leave state in Needinfo and add a comment with revision of backport proposal (STATUS file) 3. Backported = Change state to Resolved, fixed and add a comment with revision of backport. This could be modified to: 1. Fix on trunk = Change state in Resolved, fixed and add a comment with revision of fix. 2. Proposed for backport = Leave state in Resolved, fixed and add a comment with revision of backport proposal (STATUS file) 3. Backported = Change state to Closed and add a comment with revision of backport. From my personal point of view I think it is important to add the revision number of the fix / backport to the comment because: 1. People who are interested / have the know how can easily cross check what has been changed. 2. People who only want a specific fix either because there is no newer stable version, or because they cannot do an upgrade to a later stable version for whatever reason can easily find the needed patch. Regards Rüdiger
Re: Add 2.2.4 to bugzilla
lör 2007-01-13 klockan 01:06 +0100 skrev Ruediger Pluem: This could be modified to: 1. Fix on trunk = Change state in Resolved, fixed and add a comment with revision of fix. 2. Proposed for backport = Leave state in Resolved, fixed and add a comment with revision of backport proposal (STATUS file) 3. Backported = Change state to Closed and add a comment with revision of backport. Another alternative is ignoring Bugzilla for backport status, only using the STATUS file with references to Bugzilla entries needing to get backported to the release. I.e. something like 1. Fix on trunk - Resolved, Fixed. Reference to revision in bugzilla (preferably automatic) 2. Audited by a release maintainer for the main release to judge if backport needed, added to STATUS file if backport needed. - Closed. 3. Backported - cleared in STATUS file. Reference to revision in Bugzilla (preferably automatic). Another alternative which is more in line with normal release management is using the target milestone feature builtin to Bugzilla. 1. Fix on trunk - Resolved, Fixed. Reference to revision in bugzilla (preferably automatic). No target milestone assigned yet. 2. Audited by release maintainer for the main release. If backport needed added to STATUS and - New with target milestone of the release. Else closed. 3. Backported. - Resolved, Fixed. 4. Audited by next older release maintainer if any, as in 2. Repeat until all maintained releases has been covered. the beauty of the above is that it's easy to query Bugzilla for the list of bugs in various states, and that it pans out quite well when you keep maintaining older releases. Same process all the way. From my personal point of view I think it is important to add the revision number of the fix / backport to the comment because: 1. People who are interested / have the know how can easily cross check what has been changed. 2. People who only want a specific fix either because there is no newer stable version, or because they cannot do an upgrade to a later stable version for whatever reason can easily find the needed patch. Note: If you properly reference bugzilla entries in the changelog messages when committing changes then there is automated tools which can both resolve bugzilla entries and add references.. Could save you some headache but requires a bit of setup.. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: Add 2.2.4 to bugzilla
On Jan 11, 2007, at 12:42 PM, Ruediger Pluem wrote: could someone please add version 2.2.4 to the product Apache httpd-2 in bugzilla? Done. Are there any ideas how we can document / automate this as part of the release process? This issue pops up regulary after each release. Hard to automate... but we could include it in the release checklist: Ask Bugzilla admin to add new version. I am one, and will be happy to do this ahead of the release. However, I usually space on it. The combined 2.2.x versions have 198 bugs in (New, Assigned, Reopened, NeedInfo): http://issues.apache.org/bugzilla/buglist.cgi?product=Apache +httpd-2version=2.2- HEADversion=2.2.0version=2.2.2version=2.2.3version=2.2.4bug_status= NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=NEEDINFO ...and 183 in Resolved or Verified: http://issues.apache.org/bugzilla/buglist.cgi?product=Apache% 20httpd-2version=2.2- HEADversion=2.2.0version=2.2.2version=2.2.3version=2.2.4bug_status= RESOLVEDbug_status=VERIFIED Of the latter: 60 are Resolved, Invalid 7 are Resolved, Wontfix 1 is Resolved, Later 37 are Resolved, Duplicate 70 are Resolved, Fixed 8 are Resolved, Worksforme 0 are Verified These can probably be closed in some way, shape or form. What do you think is sufficient inactivity to amount to lazy verification of a Resolution transition? A week? Can I get a hum on that? If any of the former still exist in 2.2.4, they should be moved to 2.2-HEAD. S. -- [EMAIL PROTECTED]http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: Add 2.2.4 to bugzilla
Ruediger Pluem wrote: Hi, could someone please add version 2.2.4 to the product Apache httpd-2 in bugzilla? Are there any ideas how we can document / automate this as part of the release process? This issue pops up regulary after each release. My bad, sorry, it's already been done. http://httpd.apache.org/dev/release.html from http://svn.apache.org/repos/asf/httpd/site/trunk/xdocs/dev/ knock yourself out :)
Re: Add 2.2.4 to bugzilla
On 01/11/2007 10:12 PM, Sander Temme wrote: On Jan 11, 2007, at 12:42 PM, Ruediger Pluem wrote: could someone please add version 2.2.4 to the product Apache httpd-2 in bugzilla? Done. Thanks. Are there any ideas how we can document / automate this as part of the release process? This issue pops up regulary after each release. Hard to automate... but we could include it in the release checklist: Ask Bugzilla admin to add new version. I am one, and will be happy to I am happy to add it to this list once somebody gives me a pointer where to find it. I only found the shell scripts for creating the tar balls. ...and 183 in Resolved or Verified: http://issues.apache.org/bugzilla/buglist.cgi?product=Apache% 20httpd-2version=2.2- HEADversion=2.2.0version=2.2.2version=2.2.3version=2.2.4bug_status= RESOLVEDbug_status=VERIFIED Of the latter: 60 are Resolved, Invalid 7 are Resolved, Wontfix 1 is Resolved, Later 37 are Resolved, Duplicate 70 are Resolved, Fixed 8 are Resolved, Worksforme 0 are Verified These can probably be closed in some way, shape or form. What do you think is sufficient inactivity to amount to lazy verification of a Resolution transition? A week? Can I get a hum on that? A week sounds good to me. I guess some of them are my fault as I only set them to resolved fixed and never visited them again as I thought that they reached their final state. Now I found out that you only have the option to close it once it has moved to a 'resolved' state and 'closed' should be the final state. I will take better care of this in the future. Is there any chance to close all the ones in resolved state that have not been touched for a week in one blow? Regards Rüdiger
Re: Add 2.2.4 to bugzilla
On 01/11/2007 10:22 PM, William A. Rowe, Jr. wrote: Ruediger Pluem wrote: Hi, could someone please add version 2.2.4 to the product Apache httpd-2 in bugzilla? Are there any ideas how we can document / automate this as part of the release process? This issue pops up regulary after each release. My bad, sorry, it's already been done. http://httpd.apache.org/dev/release.html from http://svn.apache.org/repos/asf/httpd/site/trunk/xdocs/dev/ Thanks for the pointers. I tweaked release.xml a little bit. If there are no objections I will update the site in 24 hours. Regards Rüdiger
Re: Add 2.2.4 to bugzilla
On Jan 11, 2007, at 1:40 PM, Ruediger Pluem wrote: A week sounds good to me. I guess some of them are my fault as I only set them to resolved fixed and never visited them again as I thought that they reached their final state. Now I found out that you only have the option to close it once it has moved to a 'resolved' state and 'closed' should be the final state. I will take better care of this in the future. Is there any chance to close all the ones in resolved state that have not been touched for a week in one blow? Absolutely. You can operate on the entire contents of a query result... which gets the job done and will send lots of e-mail. Yes, Closed should be the final resting place for bug reports, for good or for bad. Any interest in trying to codify the life cycle of PRs in Bugzilla and their dance around releases? I can see if I have time to throw something in svn but then I'd want to hear from the folks who actually spend a lot of time in the system. S. -- [EMAIL PROTECTED]http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
