Re: [Server-devel] Squid tuning recommendations for OLPC School Server tuning...
On ons, 2008-09-24 at 14:14 +1200, Martin Langhoff wrote: Good hint, thanks! If we did have such a control, what is the wired memory that squid will use for each entry? In an email earlier I wrote... For on-disk objects about 100 bytes. In-memory objects obviously uses a lot more. Probably something like 1kb + the object size rounded up to 4k pages. Also disable the client db unless you need to use the maxconn acl client_db off And don't configure with too many filedescriptors. The default 1024 is probably reasonable for the environment. (Note: configure flag in squid-3, squid.conf option in 2.7) Regards Henrik signature.asc Description: This is a digitally signed message part
Re: /bzr/squid3/trunk/ r9220: Added Comm close handler for the data channel of FtpStateData
Alex Rousskov wrote: On Wed, 2008-09-24 at 13:37 +1200, Amos Jeffries wrote: revno: 9220 committer: Alex Rousskov [EMAIL PROTECTED] branch nick: trunk timestamp: Tue 2008-09-23 08:49:50 -0600 message: Added Comm close handler for the data channel of FtpStateData transaction in preparation for officially dropping connect callbacks for closing descriptors. The data channel can be opened and closed a few times and the descriptor must be kept in sync with the close handler. I factored out the open/closing code into a simple FtpChannel class. That class is now used for both FTP control and data channels. The changes resolve one XXX discussion regarding FTP not having a close handler for the data channel. On the other hand, adding a second close handler attached to the same transaction is not a trivial change as the side-effects of Squid cleanup code are often illusive. For example, I suspect that FTP cleanup code does not close or even check the control channel. I added a DBG_IMPORTANT statement to test whether the control channel remains open. Or should that be an assert()? I think that only one out of the two callbacks can be dialed because the close handler executed first will invalidate the transaction object. FTP data channel can open close any time. Agreed. It's close handler needs to only handle the fd, with no implications on the other FTP state. Yes if the close handler purpose is to handle planned closing of the data channel. Not so sure if the handler purpose is to handle unexpected data channel closures only. Before the above change, there were no close handler for the data channel at all, so we can say that the old code did not want to cleanup during planned data channel closing or that the cleanup code was called before comm_close. Currently, the close handler for the data channel should only deal with unexpected closures. When the closure is unexpected, the current code will abort the entire FTP transaction. For planned closures, we remove the handler before closing so it is not involved, just like before. I've checked the RFC 959, I had it slightly wrong. ABOR is for data unexpected closure, not control unexpected closure. (NP: what you have committed will work, so ignore the following if you want to save time). So... For expected closures of data fd, the close handler needs to be removed before closure. If the server closes data fd from that end. I *think*, without checking, that is expected closure the existing code already handles. For unexpected closures of data fd (from squid end), we SHOULD send ABOR down the _control_ fd if that is still open. Leaving the control fd otherwise alone to keep state running. (Or since squid has no use for an unused open ctrl.fd, leaving failed() to close it properly.) ref RFC 959 section 3.2 pg 18 - The server MUST close the data connection under the following conditions: 1. The server has completed sending data in a transfer mode that requires a close to indicate EOF. 2. The server receives an ABORT command from the user. 4. The control connection is closed legally or otherwise. (non-relevant conditions elided) It is possible that a different overall design would be better, but I tried not to disturb the exiting code when addressing a specific issue (lack of a closing handler for comm connect). What you committed is valid, just not a nice transfer closure. There is no failover or recovery on the current design. I'll make a doc comment about what should be done there when its eventually cleaned up... snip I am not sure I follow. I was just waffling and confusing myself. Sorry. Not relevant at this stage. My commit comment mentions that the cleanup code does not seem to check whether the control channel is closed, which seems odd to me, but I could easily overlook something. Normally, the cleanup code should close all still-open descriptors owned by the transaction. You have good instincts, the behavior there has possibilities of failure recovery which are currently missing. Worth looking at One Day (tm) FWIW, I tried not to change the normal shutdown procedure in FTP. If correct, my changes should affect unexpected data channel closures only. However, this would not play nicely on shutdown right now. Just on regular connection closes. FTP still needs a re-work cleanup at some later date which can do this sequence checking and fixup. Also to get rid of many global functions and do translations of generated pages properly from templates. I agree that we need to clean it up. IMO, it is not as bad as the client side though, so we may want to concentrate on that first if we cannot do it in parallel. Yes. Just getting the state of the new handler to fit and work right for now. Amos -- Please use Squid 2.7.STABLE4 or 3.0.STABLE9
Re: [Server-devel] Squid tuning recommendations for OLPC School Server tuning...
Henrik Nordstrom wrote: On ons, 2008-09-24 at 10:18 +0200, Henrik Nordstrom wrote: For on-disk objects about 100 bytes. In-memory objects obviously uses a lot more. Probably something like 1kb + the object size rounded up to 4k pages. Also disable the client db unless you need to use the maxconn acl client_db off And don't configure with too many filedescriptors. The default 1024 is probably reasonable for the environment. (Note: configure flag in squid-3, squid.conf option in 2.7) A quick inspection using nm also reveals that there is some data elements which can easily be trimmed down size type name 131072 b queried_keys 131072 b queried_addr 131072 b queried_keys 262144 B server_pconn_hist 262144 B client_pconn_hist The first three is used by ICP and can be ripped out if you do not need to support ICP. But if you need ICP then they are needed (but can be shrunk down a bit by limiting the ICP id range). The second two histograms is purely informational statistics. Should be fine to set PCONN_HIST_SZ to something much smaller such as 64, or disable this part of the code entirely as not used other than for statistical information available via cachemgr. There probably is a lot more junk being allocated runtime which can be trimmed, especially if you build with ssl support. But the fd_table seems to be the only big one and can not be significantly trimmed by other means than limiting the number of concurrent connections (filedescriptors). Regards Henrik I've had a suspicion since I first heard Squid was in use for OLPC, that we would be needing to soon provide configure options to remove features such as ICP which they and perhapse others in the *WRT mini-device areas don't need. On that train --disable-htcp and --disable-wccp may be useful if you don't use those features. Theres a small project for someone, adding default-enabled configure macros back into squid ;-) Maybe an overall option like --disable-peering, to wholesale drop cache_peer and all its related features for slimline stand-along Squid. Theres a good (estimated) 15% of the app footprint gone. One feature I'm uncertain of utility-wise is the netdb cache (--enable-icmp). It may be beneficial for schools on flakey links which need to ensure fast retrieval of data from a set of stable peers before the link dies. Though that does add more memory for the NetDB itself and some baseline ICMP load to the link. Amos -- Please use Squid 2.7.STABLE4 or 3.0.STABLE9
Re: /bzr/squid3/trunk/ r9223: Fix build breakage caused by r9216.
Benno Rice wrote: revno: 9223 committer: Benno Rice [EMAIL PROTECTED] branch nick: trunk timestamp: Wed 2008-09-24 10:29:50 +1000 message: Fix build breakage caused by r9216. There were a number of problems in r9216: - Unterminated blocks in if () statements. - Use of a struct to refer to an enum declared within the struct. - Use of incorrect enum values after the originals were renamed. - References to enum values from within the struct without the struct name. Note that these changes have not been tested, but they do allow the tree to build again. Thanks Benno. No idea why the branch merged so badly after testing out okay. :-( And its zapped now so I can't track it down. bah. Amos -- Please use Squid 2.7.STABLE4 or 3.0.STABLE9
Re: [RFC] 3.1 branching
Henrik Nordstrom wrote: On tis, 2008-09-23 at 23:30 -0600, Alex Rousskov wrote: PRE, to me, means we think it is stable, what do you think?. A development release, to me, means we are done adding features, please help us with testing and polishing. And yes, I know that the definitions at http://www.squid-cache.org/Versions/ are somewhat different. IIRC, I failed to convince others that mine are better :-) You are off-by-one from what we normally use DEVEL - We are still adding features, but this release is beleived to be reasonably stable suitable for evaluating what has been done so far. PRE - We are done adding features. Please help us hunting down the last bugs. RC - No more known bugs to fix. We think it's stable. Please verify. STABLE - We think it's stable production release. DEVEL releases is rarely needed as the nightly snapshot releases serves this purpose well. Came to light during the very extended Squid-3.0 development cycle with lots of major restructuring and destabilization taking place.. The non-major but important bugs can be fixed during DEVEL and PRE cycles. Branching is about features not bugs. Agreed, except I do not think we should have any known important bugs when doing the first PRE (if we do PRE at all). Yes. It's not much use in releaseing a PRE with known major blockers. Well, we all seem to agree on no bugs above a certain level, but differ as to what the maximum rating should be :-) I've been basing my standards on the bugzilla importance labels. PRE requiring: 0 'blocker', 'critical', 'major' judgement call on those labeled 'normal' or lower (few as possible) My PRE list is the one linked from RoadMap under bugzapping. (all bugs minor, either existing in or targeted at a fix 3.1) My RC list extends that to include the 3.0 bugs, so 3.1.RC1 won't go out until there are no big bugs inherited from 3.0. Maybe we should call a bug sprint with PRE1 release. Amos -- Please use Squid 2.7.STABLE4 or 3.0.STABLE9
Re: [RFC] 3.1 branching
On Wed, 2008-09-24 at 12:21 +0200, Henrik Nordstrom wrote: On tis, 2008-09-23 at 23:30 -0600, Alex Rousskov wrote: PRE, to me, means we think it is stable, what do you think?. A development release, to me, means we are done adding features, please help us with testing and polishing. And yes, I know that the definitions at http://www.squid-cache.org/Versions/ are somewhat different. IIRC, I failed to convince others that mine are better :-) You are off-by-one from what we normally use DEVEL - We are still adding features, but this release is beleived to be reasonably stable suitable for evaluating what has been done so far. PRE - We are done adding features. Please help us hunting down the last bugs. RC - No more known bugs to fix. We think it's stable. Please verify. STABLE - We think it's stable production release. Oh boy, I forgot about yet another undocumented stage -- RC! I wonder what PRE stands for then. Pre-RC?! This is just plain wrong. DEVEL releases is rarely needed as the nightly snapshot releases serves this purpose well. Came to light during the very extended Squid-3.0 development cycle with lots of major restructuring and destabilization taking place.. The DEVEL label is not needed indeed, but I was talking about code states. I understand now that you use the PRE state for a different purpose. Please note that your definitions of DEVEL and PRE differ from the ones on the web site. The most annoying thing, IMO, is that the official and your definitions above have two fuzzy lines for DEVEL and PRE states: stability and features. One fuzzy line is tolerable, but two make things really confusing. The non-major but important bugs can be fixed during DEVEL and PRE cycles. Branching is about features not bugs. Agreed, except I do not think we should have any known important bugs when doing the first PRE (if we do PRE at all). Yes. It's not much use in releaseing a PRE with known major blockers. But your definition above says we are still hunting down some bugs. It does not say there are no major bugs left. How about this: Trunk: Experimental code and new major features are being added. Use daily snapshots (e.g., HEAD-MMDD). No label. ... time passes, more features are added ... Branching point (e.g., 3.1): All major features are in. Use daily snapshots (e.g., 3.1-MMDD). No label. ... time passes, all known major bugs get fixed ... First numbered release (e.g., 3.1.0): All known major bugs fixed. Could be labeled a beta or development release if needed. ... time passes, more beta releases are made, with fewer bugs ... Branch first marked as stable (e.g., 3.1.5): The last numbered release turned out to be stable! ... time passes, the stable branch is maintained ... Branch marked as end of life or no longer supported. Cheers, Alex.
Re: [RFC] 3.1 branching
On Wed, Sep 24, 2008 at 4:45 PM, Alex Rousskov [EMAIL PROTECTED] wrote: On Wed, 2008-09-24 at 12:21 +0200, Henrik Nordstrom wrote: On tis, 2008-09-23 at 23:30 -0600, Alex Rousskov wrote: The DEVEL label is not needed indeed, but I was talking about code states. I understand now that you use the PRE state for a different purpose. Please note that your definitions of DEVEL and PRE differ from the ones on the web site. The most annoying thing, IMO, is that the official and your definitions above have two fuzzy lines for DEVEL and PRE states: stability and features. One fuzzy line is tolerable, but two make things really confusing. The non-major but important bugs can be fixed during DEVEL and PRE cycles. Branching is about features not bugs. Agreed, except I do not think we should have any known important bugs when doing the first PRE (if we do PRE at all). Yes. It's not much use in releaseing a PRE with known major blockers. But your definition above says we are still hunting down some bugs. It does not say there are no major bugs left. How about this: Trunk: Experimental code and new major features are being added. Use daily snapshots (e.g., HEAD-MMDD). No label. ... time passes, more features are added ... Branching point (e.g., 3.1): All major features are in. Use daily snapshots (e.g., 3.1-MMDD). No label. ... time passes, all known major bugs get fixed ... First numbered release (e.g., 3.1.0): All known major bugs fixed. Could be labeled a beta or development release if needed. ... time passes, more beta releases are made, with fewer bugs ... Branch first marked as stable (e.g., 3.1.5): The last numbered release turned out to be stable! ... time passes, the stable branch is maintained ... Branch marked as end of life or no longer supported. This is a bit like rehashing an old discussion, I'll however give it a shot but not discuss it further. I'm not a particular fan of DEVEL/PRE/RC/STABLE labels. I like your idea about labelling the branching point and keeping timestamps around for the head and post-branching stabilization phase. I don't like much not having a fixed stable marker much tho, what I'd do is: - when major bugs are fixed, a .0 release point is taken. After that during the stabilization phase, milestones are marked with an additional numeral (e.g. 3.2.0.5) - when STABLE level is reached, then a .1 release is taken (3.2.1). After that, it's maintainance mode and new releases are marked by incrementing the third numeral (e.g. 3.2.5). Advantages: - it's fully-numeral - it has a fixed stable marker (the .1 release). - it doesn't change much the current numbering approach My 2c; I won't waste more of anyone's time (re-re-re-re-re-re)resurrecting this discussion. -- /kinkie
Re: [RFC] 3.1 branching
I only have one question: how well does that release numbering model match the other OSS projects using the same numbering system? We don't want to set our own method and meaning when there is already a common way to get confused with. No standard that I know of - timestamps are quite common for prerelease, and some projects also use them for post-release. The closest thing, having been adopted by some other projets, has been Linux's (now abandoned) odd minor releases are devel, even minor releases are stable. -- /kinkie
Re: [RFC] 3.1 branching
On Thu, 2008-09-25 at 03:32 +1200, Amos Jeffries wrote: Alex Rousskov wrote: On Wed, 2008-09-24 at 12:21 +0200, Henrik Nordstrom wrote: On tis, 2008-09-23 at 23:30 -0600, Alex Rousskov wrote: PRE, to me, means we think it is stable, what do you think?. A development release, to me, means we are done adding features, please help us with testing and polishing. And yes, I know that the definitions at http://www.squid-cache.org/Versions/ are somewhat different. IIRC, I failed to convince others that mine are better :-) You are off-by-one from what we normally use DEVEL - We are still adding features, but this release is beleived to be reasonably stable suitable for evaluating what has been done so far. PRE - We are done adding features. Please help us hunting down the last bugs. RC - No more known bugs to fix. We think it's stable. Please verify. STABLE - We think it's stable production release. Oh boy, I forgot about yet another undocumented stage -- RC! I wonder what PRE stands for then. Pre-RC?! This is just plain wrong. 'tis documented: http://www.squid-cache.org/Devel/release-process.html Sorry, I should have looked there too. I was talking about http://www.squid-cache.org/Versions/ Although.. from 3.1 - step 1 and 4 are joined, so step 2+ happens parallel to HEAD without locking other new features. and I have not exactly been closely following step7 for 3.0. To pump through the biggest bug fixes faster. I will need a flow chart tool to grok this :-) Trunk: Experimental code and new major features are being added. Use daily snapshots (e.g., HEAD-MMDD). No label. ... time passes, more features are added ... Branching point (e.g., 3.1): All major features are in. Use daily snapshots (e.g., 3.1-MMDD). No label. ... time passes, all known major bugs get fixed ... First numbered release (e.g., 3.1.0): All known major bugs fixed. Could be labeled a beta or development release if needed. ... time passes, more beta releases are made, with fewer bugs ... Branch first marked as stable (e.g., 3.1.5): The last numbered release turned out to be stable! ... time passes, the stable branch is maintained ... Branch marked as end of life or no longer supported. Suites me either way. Some of the users at AusMeet commented on the confusion of calling a release 3.0.STABLEx when a month later it obviously wasn't. I only have one question: how well does that release numbering model match the other OSS projects using the same numbering system? We don't want to set our own method and meaning when there is already a common way to get confused with. I am not an expert on this, but AFAIK, there are several popular models including odd/even, devel/stable, current/release. Some do release candidates, but it is often just an informal announcement (e.g., snapshot such and such is a release candidate). Many offer VCS access and, hence, can do snapshots (as a convenience for the user). But the main theme seems to be a simple single threshold (if you do not count VCS). The above scheme is pretty much the same as devel/stable approach many projects use. It should be familiar to users and developers alike. The key here is to make it as simple and well defined as possible. I think our scheme is too complex and confusing because we are trying to piggyback too many things onto a version label and make it too fine-grained. This hurts both users and developers. Personally, I have never seen other projects stuffing version numbers with STABLE. It is strange to look at, it is longer to type, and harder to auto-process. IMHO, version should only contain version numbers. Everything else is metadata that does not belong there. I am sure there are projects out there that do similar silly stuff though. Cheers, Alex.
Re: [RFC] 3.1 branching
On Wed, 2008-09-24 at 17:43 +0200, Kinkie wrote: I only have one question: how well does that release numbering model match the other OSS projects using the same numbering system? We don't want to set our own method and meaning when there is already a common way to get confused with. The closest thing, having been adopted by some other projets, has been Linux's (now abandoned) odd minor releases are devel, even minor releases are stable. See, even Linux managed to abandon an odd naming scheme! We can do it too. :-) BTW, you may notice that we, ourselves, usually use devel/stable terms when talking about releases (ours and others). We rarely tell somebody Oh, just wait for a PRE release or perhaps RC... Alex.
Re: [RFC] 3.1 branching
On Wed, 2008-09-24 at 17:28 +0200, Kinkie wrote: I don't like much not having a fixed stable marker much tho, what I'd do is: - when major bugs are fixed, a .0 release point is taken. After that during the stabilization phase, milestones are marked with an additional numeral (e.g. 3.2.0.5) - when STABLE level is reached, then a .1 release is taken (3.2.1). After that, it's maintainance mode and new releases are marked by incrementing the third numeral (e.g. 3.2.5). Advantages: - it's fully-numeral - it has a fixed stable marker (the .1 release). - it doesn't change much the current numbering approach I like your proposal a lot more than the current scheme, but what is the value of a fixed stable marker? What a fixed marker like that would allow us to do that we cannot do by saying stable or first stable? The only use I can think of is that it would allow us to detect a stable release in a version number that was assigned 5 years ago (e.g., we will know that 3.1.3 was a stable release even 5 years from now). Since that old branch will no longer be supported by then, we should not need that information often. What other uses are there? Thank you, Alex.
Re: [RFC] 3.1 branching
Alex Rousskov wrote: On Thu, 2008-09-25 at 03:32 +1200, Amos Jeffries wrote: Alex Rousskov wrote: On Wed, 2008-09-24 at 12:21 +0200, Henrik Nordstrom wrote: On tis, 2008-09-23 at 23:30 -0600, Alex Rousskov wrote: PRE, to me, means we think it is stable, what do you think?. A development release, to me, means we are done adding features, please help us with testing and polishing. And yes, I know that the definitions at http://www.squid-cache.org/Versions/ are somewhat different. IIRC, I failed to convince others that mine are better :-) You are off-by-one from what we normally use DEVEL - We are still adding features, but this release is beleived to be reasonably stable suitable for evaluating what has been done so far. PRE - We are done adding features. Please help us hunting down the last bugs. RC - No more known bugs to fix. We think it's stable. Please verify. STABLE - We think it's stable production release. Oh boy, I forgot about yet another undocumented stage -- RC! I wonder what PRE stands for then. Pre-RC?! This is just plain wrong. 'tis documented: http://www.squid-cache.org/Devel/release-process.html Sorry, I should have looked there too. I was talking about http://www.squid-cache.org/Versions/ Although.. from 3.1 - step 1 and 4 are joined, so step 2+ happens parallel to HEAD without locking other new features. and I have not exactly been closely following step7 for 3.0. To pump through the biggest bug fixes faster. I will need a flow chart tool to grok this :-) Trunk: Experimental code and new major features are being added. Use daily snapshots (e.g., HEAD-MMDD). No label. ... time passes, more features are added ... Branching point (e.g., 3.1): All major features are in. Use daily snapshots (e.g., 3.1-MMDD). No label. ... time passes, all known major bugs get fixed ... First numbered release (e.g., 3.1.0): All known major bugs fixed. Could be labeled a beta or development release if needed. ... time passes, more beta releases are made, with fewer bugs ... Branch first marked as stable (e.g., 3.1.5): The last numbered release turned out to be stable! ... time passes, the stable branch is maintained ... Branch marked as end of life or no longer supported. Suites me either way. Some of the users at AusMeet commented on the confusion of calling a release 3.0.STABLEx when a month later it obviously wasn't. I only have one question: how well does that release numbering model match the other OSS projects using the same numbering system? We don't want to set our own method and meaning when there is already a common way to get confused with. I am not an expert on this, but AFAIK, there are several popular models including odd/even, devel/stable, current/release. Some do release candidates, but it is often just an informal announcement (e.g., snapshot such and such is a release candidate). Many offer VCS access and, hence, can do snapshots (as a convenience for the user). But the main theme seems to be a simple single threshold (if you do not count VCS). The above scheme is pretty much the same as devel/stable approach many projects use. It should be familiar to users and developers alike. The key here is to make it as simple and well defined as possible. I think our scheme is too complex and confusing because we are trying to piggyback too many things onto a version label and make it too fine-grained. This hurts both users and developers. Personally, I have never seen other projects stuffing version numbers with STABLE. It is strange to look at, it is longer to type, and harder to auto-process. IMHO, version should only contain version numbers. Everything else is metadata that does not belong there. I am sure there are projects out there that do similar silly stuff though. Just brain dumping at 4am, but, how about this: stuff goes into HEAD (3-) ... after a period we branch (3.1) with features from HEAD ... fix all known bugs and release 3.1.0-rc1 ... if confirmed stable gets officially released as 3.1.1 ... any critical bug found, or large accumulation of minor ones causes 3.1.2 etc ... work continues on HEAD for next branching point of (3.2). Amos -- Please use Squid 2.7.STABLE4 or 3.0.STABLE9
Re: [RFC] 3.1 branching
On Thu, 2008-09-25 at 05:00 +1200, Amos Jeffries wrote: Just brain dumping at 4am, but, how about this: stuff goes into HEAD (3-) ... after a period we branch (3.1) with features from HEAD ... fix all known bugs and release 3.1.0-rc1 ... if confirmed stable gets officially released as 3.1.1 ... any critical bug found, or large accumulation of minor ones causes 3.1.2 etc ... work continues on HEAD for next branching point of (3.2). This is much better than the current scheme and is similar to what Kinkie proposed. The three schemes differ in when pre-stable releases of a branch are made and how they are numbered: Alex (release development versions early and until no bugs left; keep metadata elsewhere): 3.1.0, 3.1.1, 3.1.2, ... 3.1.27, 3.1.28, ... Kinkie (release development versions early and until no bugs left; x.y.0.z means devel or beta; x.y.1 and later are stable): 3.1.0.0, 3.1.0.1, 3.1.0.2, ... 3.1.1, 3.1.2, ... Amos: (use BZR snapshots for development, release first numbered version when all bugs are fixed; x.y.0-rcZ means release candidate): ... 3.1.0-rc1, 3.1.0-rc2, 3.1.0-rc3, ... 3.1.1, 3.1.2, ... Is this summary correct? Alex.
Re: [RFC] 3.1 branching
On Wed, 2008-09-24 at 21:26 +0200, Kinkie wrote: It's only a psychological thing. .0 sounds prerelease. Also the fact that devel will not bump the patchlevel release feels like slowing down and checking things out for the first number, 1. Understood, thank you. None of this has (or should have) any effect on the actual development cycle, it's just conventions. Right. If we were machines, only the rules for branching and releasing would matter. Cheers, Alex.
Re: [RFC] 3.1 branching
On Wed, 2008-09-24 at 20:56 +0200, Henrik Nordstrom wrote: On tor, 2008-09-25 at 03:32 +1200, Amos Jeffries wrote: I only have one question: how well does that release numbering model match the other OSS projects using the same numbering system? We don't want to set our own method and meaning when there is already a common way to get confused with. Numeric numbering with 0 as beta is used by many packaging schemes, and would not confuse anyone. I am positive on getting rid of the labels and use the scheme proposed by Kinkie. Cool. So, if there are no objections, we have: 0) Trunk is usually open for new stuff. Make daily snapshots. 1) Branch X.Y when major features are committed. Snapshots. 2a) Release X.Y.0.0 when all major bugs are fixed. 2b) Release X.Y.0.w as code gets better, w = 1. 3a) Release X.Y.1 when the last X.Y.0.w was stable. Mark branch as stable. 3b) Release X.Y.z as bugs get fixed, z 1. If needed, flag any snapshot or numbered version as Release Candidate. These flags do not affect the version number. To answer Alex regarding the RC (Release Candidate) this is not a release tag in itself. It's more of a temporary flag. It has also used between STABLE releases if there has been large or packaging changes, and those releases is not announced outside squid-dev or visible on the web site. Sounds good. Thank you, Alex.
bzr upgraded on squid-cache.org
suqid-cache.org bzr has been upgraded to 1.6.1 (was 1.5) Regards Henrik signature.asc Description: This is a digitally signed message part
Re: [RFC] 3.1 branching
On ons, 2008-09-24 at 13:56 -0600, Alex Rousskov wrote: Cool. So, if there are no objections, we have: 0) Trunk is usually open for new stuff. Make daily snapshots. 1) Branch X.Y when major features are committed. Snapshots. 2a) Release X.Y.0.0 when all major bugs are fixed. 2b) Release X.Y.0.w as code gets better, w = 1. 3a) Release X.Y.1 when the last X.Y.0.w was stable. Mark branch as stable. 3b) Release X.Y.z as bugs get fixed, z 1. Sounds good to me, but see below for a minor adjustment and reasoning. If needed, flag any snapshot or numbered version as Release Candidate. These flags do not affect the version number. Correct. With this scheme labels is outside the revision numbers and only a human concept in the text describing the releases (i.e. website and announces). Also allows us to revoke the stable label from any version known to have issues by simply updating the description, Only comment is that 1 is a little fuzzier than described above 1 should take place when the tree is in a state the release manager and others involved in the process considers a good startingpoint for getting to 3. May still be major features missing, or there may even be too many features at that time. During 2 there is a significant flow of changes from trunk to the branch, and also stuff getting revoked from the branch and deferred to trunk waiting for the next release. But if there is a major feature pending for trunk which is not targeted for the branch then it's better to branch before that gets merged, even if waiting on other major items which may get into trunk after. But both ways are doable. It's also important to keep good quality of the changes going into trunk. The intention is that from a quality perspective trunk should always be in shape for 1, with 2 being a fairly short process (a month or so). The .0.w releases should mainly take place at the near end of 2. Before that the nightly snapshots serves the purpose well I think. To get the snapshot numbering right and some other similar tasks the .0.0 release should be the branch point, and will most often be skipped as a release as such. For cosmetic reasons using just .0 may be better. So we have 1. Branch when trunk is considered a suitable startingpoint for getting to stable, and tag a x.y.0 release at the branchpoint (or at least set this version in configure.in). 2a. Release X.Y.0.1 when ready for testing 2b. Release X.Y.0.w as code gets better, w 1 Regards Henrik signature.asc Description: This is a digitally signed message part
[PATCH] Check half-closed descriptors at most once per second.
Performance fix: Check half-closed descriptors at most once per second.
A few revisions back, comm checked half-closed descriptors once per
second, but the code was buggy. I replaced it with a simpler code that
checked each half-closed descriptor whenever the OS would mark it as
ready for reading. That was a bad idea: The checks wasted a lot of CPU
cycles because half-closed descriptors are usually ready for reading all
the time.
This revision resurrects 1 check/sec limit, but hopefully with fewer
bugs. In my limited tests, CPU usage seems to be back to normal.
Added a DescriptorSet class to manage an unordered collection of unique
descriptors. The class might be useful for deferred reads as well, but
that remains to be seen.
The DescriptorSet class has O(1) complexity for search, insertion,
and deletion. It uses about 2*sizeof(int)*MaxFD bytes. Splay tree that
used to store half-closed descriptors previously uses less RAM for small
number of descriptors but has O(log n) complexity.
The DescriptorSet code should probably get its own .h and .cc files,
especially if it is going to be used by deferred reads.
Thank you,
Alex.
Performance fix: Check half-closed descriptors at most once per second.
A few revisions back, comm checked half-closed descriptors once per second,
but the code was buggy. I replaced it with a simpler code that checked each
half-closed descriptor whenever the OS would mark it as ready for reading.
That was a bad idea: The checks wasted a lot of CPU cycles because half-closed
descriptors are usually ready for reading all the time.
This revision resurrects 1 check/sec limit, but hopefully with fewer bugs. In
my limited tests CPU usage seems to be back to normal.
Added a DescriptorSet class to manage an unordered collection of unique
descriptors. The class might be useful for deferred reads as well, but that
remains to be seen.
The DescriptorSet class has O(1) complexity for search, insertion,
and deletion. It uses about 2*sizeof(int)*MaxFD bytes. Splay tree that used to
store half-closed descriptors previously uses less RAM for small number of
descriptors but has O(log n) complexity.
=== modified file 'src/comm.cc'
--- src/comm.cc 2008-09-22 21:56:44 +
+++ src/comm.cc 2008-09-24 23:09:33 +
@@ -224,6 +224,144 @@
CBDATA_CLASS(ConnectStateData);
};
+/// an unordered collection of unique descriptors with O(1) complexity
+class DescriptorSet {
+// \todo: Should we use std::setint with its flexibility? Our implementation
+// has constant overhead, which is smaller than log(n) of std::set.
+public:
+// for STL compatibility, should we decide to switch to std::set or similar
+typedef const int *const_iterator;
+
+DescriptorSet();
+~DescriptorSet();
+
+/// checks whether fd is in the set
+bool has(const int fd) const { return 0 = fd fd capacity_
+index_[fd] = 0; }
+
+bool add(int fd); /// adds if unique; returns true if added
+bool del(int fd); /// deletes if there; returns true if deleted
+int pop(); /// deletes and returns one descriptor, in unspecified order
+
+bool empty() const { return !size_; } /// number of descriptors in the set
+
+/// begin iterator a la STL; may become invalid if the object is modified
+const_iterator begin() const { return descriptors_; }
+/// end iterator a la STL; may become invalid if the object is modified
+const_iterator end() const { return begin() + size_; }
+
+void print(std::ostream os) const;
+
+private:
+// these would be easy to support when needed; prohibit for now
+DescriptorSet(const DescriptorSet s); // declared but undefined
+DescriptorSet operator =(const DescriptorSet s); // declared, undefined
+
+int *descriptors_; /// descriptor values in random order
+int *index_; /// descriptor:position index into descriptors_
+int capacity_; /// number of available descriptor slots
+int size_; /// number of descriptors in the set
+};
+
+inline std::ostream
+operator (std::ostream os, const DescriptorSet ds)
+{
+ds.print(os);
+return os;
+}
+
+static DescriptorSet *TheHalfClosed = NULL; /// the set of half-closed FDs
+static bool WillCheckHalfClosed = false; /// true if check is scheduled
+static EVH commHalfClosedCheck;
+static void commPlanHalfClosedCheck();
+
+DescriptorSet::DescriptorSet(): descriptors_(NULL), index_(NULL),
+capacity_(0), size_(0)
+{
+// we allocate once and never realloc, at least for now
+capacity_ = Squid_MaxFD;
+descriptors_ = new int[capacity_];
+index_ = new int[capacity_];
+
+// fill index with -1s to be able to say whether a descriptor is present
+// it is not essential to fill the descriptors, but it enables more checks
+for (int i = 0; i capacity_; ++i)
+index_[i] = descriptors_[i] = -1;
+}
+
+DescriptorSet::~DescriptorSet()
+{
+delete[] descriptors_;
+delete[] index_;
+}
+
+/// adds if unique; returns true if added
+bool
+DescriptorSet::add(int fd)
Re: [PATCH] Check half-closed descriptors at most once per second.
Bundle Buggy has detected this merge request. For details, see: http://bundlebuggy.aaronbentley.com/project/squid/request/%3C198571.8721.395.camel%40pail%3E Project: Squid
Re: [RFC] 3.1 branching
On Thu, 2008-09-25 at 01:21 +0200, Henrik Nordstrom wrote: On ons, 2008-09-24 at 13:56 -0600, Alex Rousskov wrote: Cool. So, if there are no objections, we have: 0) Trunk is usually open for new stuff. Make daily snapshots. 1) Branch X.Y when major features are committed. Snapshots. 2a) Release X.Y.0.0 when all major bugs are fixed. 2b) Release X.Y.0.w as code gets better, w = 1. 3a) Release X.Y.1 when the last X.Y.0.w was stable. Mark branch as stable. 3b) Release X.Y.z as bugs get fixed, z 1. Sounds good to me, but see below for a minor adjustment and reasoning. good stuff snipped So we have 1. Branch when trunk is considered a suitable startingpoint for getting to stable, and tag a x.y.0 release at the branchpoint (or at least set this version in configure.in). 2a. Release X.Y.0.1 when ready for testing 2b. Release X.Y.0.w as code gets better, w 1 +1 Alex.
Re: [RFC] 3.1 branching
On ons, 2008-09-24 at 21:26 +0200, Kinkie wrote: The version X.Y.Z for all Z W approach means that it's not easy to tell what the state of a release is without knowing what W is for each X,Y. Even then you don't know as the notion of something being stable is very temporal in nature and often gets revoked as bugs is found. None of this has (or should have) any effect on the actual development cycle, it's just conventions. Correct. Only the rules around when branching or merges to trunk may take place has significant impact on development cycle. And I think we are all leaning towards a more open approach there based on branch early without blocking trunk. Regards Henrik signature.asc Description: This is a digitally signed message part
Re: [RFC] 3.1 branching
On Wed, 2008-09-24 at 20:56 +0200, Henrik Nordstrom wrote: On tor, 2008-09-25 at 03:32 +1200, Amos Jeffries wrote: I only have one question: how well does that release numbering model match the other OSS projects using the same numbering system? We don't want to set our own method and meaning when there is already a common way to get confused with. Numeric numbering with 0 as beta is used by many packaging schemes, and would not confuse anyone. I am positive on getting rid of the labels and use the scheme proposed by Kinkie. Cool. So, if there are no objections, we have: 0) Trunk is usually open for new stuff. Make daily snapshots. 1) Branch X.Y when major features are committed. Snapshots. 2a) Release X.Y.0.0 when all major bugs are fixed. 2b) Release X.Y.0.w as code gets better, w = 1. 3a) Release X.Y.1 when the last X.Y.0.w was stable. Mark branch as stable. 3b) Release X.Y.z as bugs get fixed, z 1. Well, They way I'm thinking of the numbers your sequence is 1-off. We are not stopping the daily snapshots, I think. So your 4-th place digit is the same as the snapshot date. We have NO new features added after X.Y.0, NO non-bug changes at all. Stability seems to be taking the same length of time as a new Y release. Which means we end up with 3.1.1, 3.2.1, 3.3.1 with possibly many smaller 4-place releases for each day or bugfix patch. 3-levels should be sufficient. It's also not a major change from current practice, only dropping the name 'STABLE' from packages. We don't really need the RC flag-days in my scheme either. I just thought it would be slightly more descriptive for people to understand the .0 code in those bundles is still not proven trustworthy for production. Also leaves the option if a major bug fix went in (rare) we could -rc a few test bundles before declaring it fixed). If needed, flag any snapshot or numbered version as Release Candidate. These flags do not affect the version number. To answer Alex regarding the RC (Release Candidate) this is not a release tag in itself. It's more of a temporary flag. It has also used between STABLE releases if there has been large or packaging changes, and those releases is not announced outside squid-dev or visible on the web site. Sounds good. Thank you, Alex.
Re: [RFC] 3.1 branching
On ons, 2008-09-24 at 13:56 -0600, Alex Rousskov wrote: Cool. So, if there are no objections, we have: 0) Trunk is usually open for new stuff. Make daily snapshots. 1) Branch X.Y when major features are committed. Snapshots. 2a) Release X.Y.0.0 when all major bugs are fixed. 2b) Release X.Y.0.w as code gets better, w = 1. 3a) Release X.Y.1 when the last X.Y.0.w was stable. Mark branch as stable. 3b) Release X.Y.z as bugs get fixed, z 1. Sounds good to me, but see below for a minor adjustment and reasoning. If needed, flag any snapshot or numbered version as Release Candidate. These flags do not affect the version number. Correct. With this scheme labels is outside the revision numbers and only a human concept in the text describing the releases (i.e. website and announces). Also allows us to revoke the stable label from any version known to have issues by simply updating the description, Only comment is that 1 is a little fuzzier than described above 1 should take place when the tree is in a state the release manager and others involved in the process considers a good startingpoint for getting to 3. May still be major features missing, or there may even be too many features at that time. During 2 there is a significant flow of changes from trunk to the branch, and also stuff getting revoked from the branch and deferred to trunk waiting for the next release. But if there is a major feature pending for trunk which is not targeted for the branch then it's better to branch before that gets merged, even if waiting on other major items which may get into trunk after. But both ways are doable. It's also important to keep good quality of the changes going into trunk. The intention is that from a quality perspective trunk should always be in shape for 1, with 2 being a fairly short process (a month or so). The .0.w releases should mainly take place at the near end of 2. Before that the nightly snapshots serves the purpose well I think. To get the snapshot numbering right and some other similar tasks the .0.0 release should be the branch point, and will most often be skipped as a release as such. For cosmetic reasons using just .0 may be better. So we have 1. Branch when trunk is considered a suitable startingpoint for getting to stable, and tag a x.y.0 release at the branchpoint (or at least set this version in configure.in). 2a. Release X.Y.0.1 when ready for testing 2b. Release X.Y.0.w as code gets better, w 1 Don't forget the next step after (w1 w12) is: Branch X.Z.0 So why do we really need an extra .0 sitting on the end wasting space? I have no intentions of maintaining anything other than: trunk + latest X.Z.n + most stable X.Y (if X.Z.n X.Z.1) The back-port workload becomes just too much for the few of us doing it. Things won't get tested well, and stability goes backwards. Lets just make STABLE release the highest of X.Y.W, .0 of that sequence the pre-release beta code. And flag anything we *really* need sub-releases of with a temporary text or even just the snapshot datestamp. Preferrably leaving those type of changes for a later X.Z release with testing time in trunk. Keep in mind the whole W-level release cycle is going to be in the order of months, with people who need long-term stability staying with high-numbered older versions. Amos
Re: [RFC] 3.1 branching
On Thu, 2008-09-25 at 15:15 +1200, Amos Jeffries wrote: On ons, 2008-09-24 at 13:56 -0600, Alex Rousskov wrote: Cool. So, if there are no objections, we have: 0) Trunk is usually open for new stuff. Make daily snapshots. 1) Branch X.Y when major features are committed. Snapshots. 2a) Release X.Y.0.0 when all major bugs are fixed. 2b) Release X.Y.0.w as code gets better, w = 1. 3a) Release X.Y.1 when the last X.Y.0.w was stable. Mark branch as stable. 3b) Release X.Y.z as bugs get fixed, z 1. Sounds good to me, but see below for a minor adjustment and reasoning. If needed, flag any snapshot or numbered version as Release Candidate. These flags do not affect the version number. Correct. With this scheme labels is outside the revision numbers and only a human concept in the text describing the releases (i.e. website and announces). Also allows us to revoke the stable label from any version known to have issues by simply updating the description, Only comment is that 1 is a little fuzzier than described above 1 should take place when the tree is in a state the release manager and others involved in the process considers a good startingpoint for getting to 3. May still be major features missing, or there may even be too many features at that time. During 2 there is a significant flow of changes from trunk to the branch, and also stuff getting revoked from the branch and deferred to trunk waiting for the next release. But if there is a major feature pending for trunk which is not targeted for the branch then it's better to branch before that gets merged, even if waiting on other major items which may get into trunk after. But both ways are doable. It's also important to keep good quality of the changes going into trunk. The intention is that from a quality perspective trunk should always be in shape for 1, with 2 being a fairly short process (a month or so). The .0.w releases should mainly take place at the near end of 2. Before that the nightly snapshots serves the purpose well I think. To get the snapshot numbering right and some other similar tasks the .0.0 release should be the branch point, and will most often be skipped as a release as such. For cosmetic reasons using just .0 may be better. So we have 1. Branch when trunk is considered a suitable startingpoint for getting to stable, and tag a x.y.0 release at the branchpoint (or at least set this version in configure.in). 2a. Release X.Y.0.1 when ready for testing 2b. Release X.Y.0.w as code gets better, w 1 Don't forget the next step after (w1 w12) is: Branch X.Z.0 So why do we really need an extra .0 sitting on the end wasting space? I have no intentions of maintaining anything other than: trunk + latest X.Z.n + most stable X.Y (if X.Z.n X.Z.1) The back-port workload becomes just too much for the few of us doing it. Things won't get tested well, and stability goes backwards. Lets just make STABLE release the highest of X.Y.W, .0 of that sequence the pre-release beta code. And flag anything we *really* need sub-releases of with a temporary text or even just the snapshot datestamp. Preferrably leaving those type of changes for a later X.Z release with testing time in trunk. Keep in mind the whole W-level release cycle is going to be in the order of months, with people who need long-term stability staying with high-numbered older versions. Amos, I am sorry, but I honestly do not understand this and the previous your sequence is 1-off email. Perhaps the dancing Xs, Ys, and Zs with some implied meaning confuse me. It feels like there is some basic misunderstanding, especially since yours and Kinkie's earlier suggestions were very similar (or so I thought!). Could you please restate your proposal in a concise step-by-step form, as opposed to explaining why the above plan would not work? This may put us back on the same page again. Thank you, Alex.
Re: [RFC] 3.1 branching
On Thu, 2008-09-25 at 15:15 +1200, Amos Jeffries wrote: On ons, 2008-09-24 at 13:56 -0600, Alex Rousskov wrote: Cool. So, if there are no objections, we have: 0) Trunk is usually open for new stuff. Make daily snapshots. 1) Branch X.Y when major features are committed. Snapshots. 2a) Release X.Y.0.0 when all major bugs are fixed. 2b) Release X.Y.0.w as code gets better, w = 1. 3a) Release X.Y.1 when the last X.Y.0.w was stable. Mark branch as stable. 3b) Release X.Y.z as bugs get fixed, z 1. Sounds good to me, but see below for a minor adjustment and reasoning. If needed, flag any snapshot or numbered version as Release Candidate. These flags do not affect the version number. Correct. With this scheme labels is outside the revision numbers and only a human concept in the text describing the releases (i.e. website and announces). Also allows us to revoke the stable label from any version known to have issues by simply updating the description, Only comment is that 1 is a little fuzzier than described above 1 should take place when the tree is in a state the release manager and others involved in the process considers a good startingpoint for getting to 3. May still be major features missing, or there may even be too many features at that time. During 2 there is a significant flow of changes from trunk to the branch, and also stuff getting revoked from the branch and deferred to trunk waiting for the next release. But if there is a major feature pending for trunk which is not targeted for the branch then it's better to branch before that gets merged, even if waiting on other major items which may get into trunk after. But both ways are doable. It's also important to keep good quality of the changes going into trunk. The intention is that from a quality perspective trunk should always be in shape for 1, with 2 being a fairly short process (a month or so). The .0.w releases should mainly take place at the near end of 2. Before that the nightly snapshots serves the purpose well I think. To get the snapshot numbering right and some other similar tasks the .0.0 release should be the branch point, and will most often be skipped as a release as such. For cosmetic reasons using just .0 may be better. So we have 1. Branch when trunk is considered a suitable startingpoint for getting to stable, and tag a x.y.0 release at the branchpoint (or at least set this version in configure.in). 2a. Release X.Y.0.1 when ready for testing 2b. Release X.Y.0.w as code gets better, w 1 Don't forget the next step after (w1 w12) is: Branch X.Z.0 So why do we really need an extra .0 sitting on the end wasting space? I have no intentions of maintaining anything other than: trunk + latest X.Z.n + most stable X.Y (if X.Z.n X.Z.1) The back-port workload becomes just too much for the few of us doing it. Things won't get tested well, and stability goes backwards. Lets just make STABLE release the highest of X.Y.W, .0 of that sequence the pre-release beta code. And flag anything we *really* need sub-releases of with a temporary text or even just the snapshot datestamp. Preferrably leaving those type of changes for a later X.Z release with testing time in trunk. Keep in mind the whole W-level release cycle is going to be in the order of months, with people who need long-term stability staying with high-numbered older versions. Amos, I am sorry, but I honestly do not understand this and the previous your sequence is 1-off email. Perhaps the dancing Xs, Ys, and Zs with some implied meaning confuse me. It feels like there is some basic misunderstanding, especially since yours and Kinkie's earlier suggestions were very similar (or so I thought!). They are, very similar. I just don't see any need for 4-numbers in Kinkies Scheme. Could you please restate your proposal in a concise step-by-step form, as opposed to explaining why the above plan would not work? This may put us back on the same page again. Okay, using actual numbers and timelines of 3.1/3.2 to make it clearer than the abstract. Dates are mostly fictional but based on reasonable guesses. trunk (3.1.0) - sept 30: branch with 10 new features release 3.1.0 (makes trunk now 3.2.0) - oct 30: everything found 'stable' release 3.1.1 - nov 30: 10 new major+ bugs fixed :-( release 3.1.2 (move 3.1.1 down to obsolete list) - dec 30: 2 new major+ bugs found release 3.1.3 - jan 1 : branch with 9 new features release 3.2.0 (makes trunk now 3.3.0) - feb 1: everything found 'stable' release 3.2.1 release 3.1.4 final bug fixes. - ... trunk continues its merry way getting new features the whole time as 3.*.0 without any flag points. grok? Nothing implies a guaranteed STABLE. Merely the highest number (ie 3.1.4) is most bug-free for all fixable problems of 3.1
Re: [RFC] 3.1 branching
On Thu, 2008-09-25 at 16:20 +1200, Amos Jeffries wrote: trunk (3.1.0) - sept 30: branch with 10 new features release 3.1.0 (makes trunk now 3.2.0) - oct 30: everything found 'stable' release 3.1.1 - nov 30: 10 new major+ bugs fixed :-( release 3.1.2 (move 3.1.1 down to obsolete list) - dec 30: 2 new major+ bugs found release 3.1.3 - jan 1 : branch with 9 new features release 3.2.0 (makes trunk now 3.3.0) - feb 1: everything found 'stable' release 3.2.1 release 3.1.4 final bug fixes. - ... trunk continues its merry way getting new features the whole time as 3.*.0 without any flag points. So how do we tell users to try something between 3.1.0 and 3.1.1? Refer to some specific daily snapshot? Kinkie+ scheme would use numbered beta releases: 3.1.0.1, 3.1.0.2, etc. I think numbered releases are better than daily snapshots for asking users to try something: Argh! Somebody committed a bug 5 minutes before the snapshot we thought we would recommend to the user. Let's wait another day and hope that it does not happen again. People! Please do not commit anything because we need a clean daily snapshot!. (makes trunk now 3.2.0) (makes trunk now 3.3.0) I am not sure what those mean. Trunk is a trunk. 3.2.0 is the first release on a 3.2 branch, right? I am ignoring those for now. We may reach 3.1.6 if things go badly, or if new features get developed really slowly. But I don't think we will get enough checkpoints in the devel cycle to warrant two layers of .0.1 - .6.2 The extra development release layer in Kinkie+ scheme is only used for 3.1.0, never for 3.1.6 or other non-zero releases. People seem happy with the release approach and timelines, just not the current bad naming scheme which implies releases are guaranteed STABLE when in fact only a bug fix improvement. Well, there are several problems with the current scheme, but I think we should preserve the notion of a stable state of the branch. It is not a guarantee, but it allows users to select the right branch/version to deploy. In Kinkie+ scheme and in your scheme, the branch is considered stable when 3.1.1 is released. Before that, there are big known bugs. After that, there should not be any and those that appear should get higher fixing priority. The only significant difference I see is that you want folks to use daily snapshots during development stage of the branch and Kinkie wants sub-numbered releases. Thank you, Alex.
Re: [RFC] 3.1 branching
On Thu, 2008-09-25 at 16:20 +1200, Amos Jeffries wrote: trunk (3.1.0) - sept 30: branch with 10 new features release 3.1.0 (makes trunk now 3.2.0) - oct 30: everything found 'stable' release 3.1.1 - nov 30: 10 new major+ bugs fixed :-( release 3.1.2 (move 3.1.1 down to obsolete list) - dec 30: 2 new major+ bugs found release 3.1.3 - jan 1 : branch with 9 new features release 3.2.0 (makes trunk now 3.3.0) - feb 1: everything found 'stable' release 3.2.1 release 3.1.4 final bug fixes. - ... trunk continues its merry way getting new features the whole time as 3.*.0 without any flag points. So how do we tell users to try something between 3.1.0 and 3.1.1? Refer to some specific daily snapshot? Kinkie+ scheme would use numbered beta releases: 3.1.0.1, 3.1.0.2, etc. I think numbered releases are better than daily snapshots for asking users to try something: Argh! Somebody committed a bug 5 minutes before the snapshot we thought we would recommend to the user. Let's wait another day and hope that it does not happen again. People! Please do not commit anything because we need a clean daily snapshot!. Thats all in trunk. We are talking numbering systems for the branches. To which the only commiter should be the branch maintainer. We can make a new clean snapshot at any point if its really warranted, even to the point of calling it a 3.1.0.1 'release' 3 times in one day. That said, maintainers can do the same for trunk too if convinced its worth the trouble. (makes trunk now 3.2.0) (makes trunk now 3.3.0) I am not sure what those mean. Trunk is a trunk. 3.2.0 is the first release on a 3.2 branch, right? I am ignoring those for now. We may reach 3.1.6 if things go badly, or if new features get developed really slowly. But I don't think we will get enough checkpoints in the devel cycle to warrant two layers of .0.1 - .6.2 The extra development release layer in Kinkie+ scheme is only used for 3.1.0, never for 3.1.6 or other non-zero releases. This is a contradiction of your earlier how do we tell users to try something between 3.1.0 and 3.1.1? The 'please try X' request is done as often after 3.1.1 as before. We come back to the problem of until squid is 100% major bug free for all users (now and in future) it never actually qualifies for that 3.1.1 rating. Under my scheme, we would not grant such development test points a full version number, they can get a rc1, rc2, etc (or as at present a '20080912') if needed. People seem happy with the release approach and timelines, just not the current bad naming scheme which implies releases are guaranteed STABLE when in fact only a bug fix improvement. Well, there are several problems with the current scheme, but I think we should preserve the notion of a stable state of the branch. It is not a guarantee, but it allows users to select the right branch/version to deploy. In Kinkie+ scheme and in your scheme, the branch is considered stable when 3.1.1 is released. Before that, there are big known bugs. After that, there should not be any and those that appear should get higher fixing priority. The only significant difference I see is that you want folks to use daily snapshots during development stage of the branch and Kinkie wants sub-numbered releases. Yes, pretty much. If you look at the changeset pages for each 3.0 release so far, there are fixes for some very major bugs in there as far as 3.0.STABLE7. If we had run a whole cycle of 3.0.0.N (aka 4 years of testing PRE1 - RC2), we would have still probably have released 3.0.1 (aka 3.0.STABLE1) with those bugs in. Or maybe gone straight from 3.0.0.16 to 3.1.0.1 this month I don't realistically expect 3.1 to be perfect either. I'd rather have fixed point releases (3.0.1) based on some known workable code, and a pile of sequentially tagged bundles of 'maybe dodgy code' on top for new un-tested bug fixes. Amos
