Martin's work should be checked in. I really want to see it, to comment and contribute. I also believe the work on ReleaseLocksOnSave should be under CM, and also the work Rafael and I have been doing on ModPerlize, and also the work on the ParameterizedVariables and ParameterizedIncludes. They are all waiting to be shared (note: not waiting for testing, though that is essential; they are waiting to be shared so more people can contribute).

However I am prepared to wait. The only checkins I have done for nearly a month now have been bugfixes and minor tweaks to DEVELOP. This is in recognition of the fact that we are undergoing a major cultural shift, and we need to make sure that whatever we do is carefully thought through. It has taken a long time to get this far; let's not lose our heads at this stage in the game. I would rather be ultra-cautious than throw away hard-won ground.

The original concept of the DEVELOP branch was that any contributor would be able to check in and demo their code there, and code would be selected for merge to MAIN by labels. After working with it for a while, it's clear this model won't work. I think it's agreed that several branches will be required simultaneously. I think the DEVELOP model would work if we were in "maintenance mode", but there is such a vast backup of input to TWiki that it will not settle to that state for some time to come. WillNorris correctly pointed out that there are at least 13 major changes in the DEVELOP branch, and it should never have been all in one branch.

So, given that the single branch methodology isn't going to work for us, we need an alternative. However, I don't see one here; no-one has even bothered to define what ScratchBranch actually means. If you are proposing something, I beg you to do it properly. Document what you are proposing, carefully consider the pros and cons, and answer issues that are raised against the proposal. Don't just get huffy because people don't understand what you haven't explained to them.

-- CrawfordCurrie - 10 Nov 2004

There were a number of solutions to these problems discussed in the text of this topic before I refactored. I present them here for more focused analysis.

Note that I deliberately removed the COMMENT box to try and encourage you to factor input directly into the list.

1. Stick with DEVELOP: try and give it a chance to succeed
   • Pros:
     • My take on this is firstly that it has all been blown out of proportion because of the way that the ideas have been presented. I do not think we need to adopt a Formal MultiBranchDevelopmentModel. At least not yet. While I agree that slowing down the commits of new work right now may be a good idea from the cultural aspect, I would be interested to see us not waiting, but rather just forging ahead with DEVELOP. I created SCRATCH so that it would be possible for DEVELOP'ers to try out something risky or immaturely thought out, or complex, but personally I see Martin's Register re-write as something to commit now (even though i dissagree with a detail i just noticed (don't rename the Impl class - you may use it to get the User info without passwords being involved)). We will need to work out the dynamics as we go, but to me, MultiBranchDevelopmentModel is premature. -- SvenDowideit - 10 Nov 2004
       • while i'd like martin's changes checked in, i'm very nervous about checking lots of big changes into DEVELOP until LocationLocationLocation is better vetted. alternatively, if a proper subset of TWikiTestingInfrastructure were in place (which we're all still working on), it would be better, but we're not there yet. i don't want DEVELOP to become unusable because too many people are simultaneously debugging it. -- WillNorris - 10 Nov 2004
       • Can you detail your comments on RegisterCgiScriptRewrite, Sven? I don't understand your Impl point. Thanks. -- MartinCleaver - 10 Nov 2004
     • I would want my own branch to develop in because I would want my work to be isolated from changes made in DevelopBranch until I was ready to incorporate them. I based my work on CairoRelease which is pre-LocationLocationLocation. So I expect some of the APIs will have moved. I want to personally handle the merge because I know what it should do and I know which edge cases are covered in the RCSR TestHarness. As much as managing multiple branches may seem complex it is as simple as the underlying problem we are trying to solve, so I believe their use is appropriate. Besides, why else was a goal for subversion to make the making branches as lightweight as possible? -- MartinCleaver - 10 Nov 2004
   • Cons:
2. Permit open checkin to "the develop area" on request
   • Pros:
     • TWiki.org "fills up" with people attaching patches. -- MartinCleaver - 10 Nov 2004
     • They are better managed by subversion than by TWiki. -- MartinCleaver - 10 Nov 2004
   • Cons:
     • Develop area will soon fill up with unloved and ill-considered code. - C.
     • We don't have the disc-space for a free-for-all - C.
     • Increased risk of an idiot trying to contribute - C.
3. Permit multiple branches, but have them created centrally.
   • Pros:
     • Good control, easy to associate input with branches - C.
   • Cons:
     • Pressure on core team to create and maintain branches - C.
4. Give branches a finite lifetime. Branches last only as long as the lifecycle of the associated ChangeProposalForm.
   • Pros:
     • Dead branches don;t just hang around - C.
   • Cons:
5. DEVELOP is just another branch, it has no special status.
   • Pros:
   • Cons:
     • More choice for CoreTeam as to what to merge to MAIN - C.
     • Harder to support the "demo twiki" concept. Which branch should be shown on ~develop? - C.
6. Support the dynamic switching of the codebase supporting ~develop between branches (for example, using a cgi script to change between branches).
   • Pros:
     • All branches are equal - C.
   • Cons:
     • Load on server, risk of a fight if not carefully coordinated - C.
7. Allow Users to dynamically designate which branch they want to run -- MartinCleaver - 10 Nov 2004
   • Pros:
     • There is no fight, people choose what they want to see. -- MartinCleaver - 10 Nov 2004
   • Cons:
     • more server resources needed
     • more admin resources needed especially when things go wrong
8. Host demo TWikis for branches on other servers. VitoMilano has volunteered server space several times.
   • Pros:
     • Theoretically at least, can have as many demos as we need - C.
   • Cons:
     • Code spread across multiple servers -- MartinCleaver - 10 Nov 2004
       • not really - all the code is in the same svn server, its jsut running on different URLs
9. Explicitly associate ChangeProposalForm topics with a branch name (MAIN being the default)
   • Pros:
     • Good process - C.
   • Cons:
10. Automate the process for granting checkin access to "the developer area"
    • Pros:
    • Cons:
      • Can be abused - C.
11. Keep DEVELOP, but like the Perl development have a "patch pumpkin" i.e. a token that allows you to check in to DEVELOP. This token can only be "owned" by one person at a time.
    • Pros:
      • Avoids conflicts - C.
    • Cons:
      • Moving the token from one person to another could be a PITA, unless it is automated - C.

Note that I deliberately removed the COMMENT box to try and encourage you to factor input directly into the list, above.