I agree with Alex. Typically with projects like this commits should be fairly atomic chunks of code that move the tip from one "working state" to another. It's perfectly reasonable to push change that are not completely baked as long as the functionality that is "not done, unstable, etc" is isolated to the new functional area, not a regression, and doesn't prevent normal operation of other areas of the project.
For example if you wanted to add a new tool bar button for private replies. It would be fine to check in the code that adds the button and creates the private reply, but have the private reply be hard coded to only include the replier as the only participant. The remaining functionality could be added later without harming the rest of the coe base. This encourages early and often committing, rather than holding out until everything is done and perfect (which results in large unwieldy codereviews). Obviously code that causes the build to fail, or to prevent start up would be a code yellow. But so would the case where some one was implementing a new log in screen. We wouldn't want them to check that in half baked, since if it was broken, you would not be able to use the product at all. During the development cycle we can and should periodically tag the repo at snapshots we feel are significant. For example if we know we are going to undertake a major effort that will have large refactoring or wide spread api changes, its good to do a tag before and after so that people can be isolated from that if they want to be. This could be viewed as milestone releases / tags along the development tip. On Nov 26, 10:50 am, Alex North <[email protected]> wrote: > I had a bit of a think about this. > > I think we should strive to keep the tip in a working state at all times. > We'll screw up sometimes and break compilation or usage, and in those cases > I agree it should be announced to the list and we should enter some kind of > "code yellow" where we restrict further code changes until everything's > working again. > > I don't think the stable tag mechanism will help, though. The stable tag has > the same requirements we should demand of tip. Having a stable tag implies > that it's ok for tip to be less stable, and I fear that will have the exact > opposite effect to what we want. The testing that a developer should do > before updating the stable tag is the same as they should be doing before > pushing a significant change anyway. Updating the tag will simply involve > more work. If committers were to habitually update the tag when pushing > because they've run tests, etc, then it would be providing no benefit. > > Having said that, tip doesn't need to be in a state where all features are > fully working. It's ok for code to be built incrementally. While there > should be no regressions, partial features are ok. To ensure people who want > to deploy WIAB can use a coherent version we should probably adopt the > common convention of tagging "releases". But we can discuss that later. > > Alex > > On 26 November 2010 01:30, David Wang <[email protected]> wrote: > > > > > > > > > Hi Folks, > > > During the creation of the Apache proposal, it became evident that having a > > good build at all times is not only for your own work, but also good for > > publicity. See > >https://wave.google.com/wave/waveref/googlewave.com/w+nv8cf8_TD/~/con... > > > I'd like to make the following proposal in sites page ( > >https://sites.google.com/a/waveprotocol.org/wave-protocol/code/workin...) > > and copied in this email. Please comment. This proposal relies on the > > responsibility of all the committers to honour this. > > > Working with a stable build (Proposal) > > > *The exact details of this proposal may change when the project is > > moved into Apache.* > > This is an active open source project with contributors from all parts > > of the world working in many different time zones. Unavoidably at rare > > occurrences, the tip of the code may not be in perfect condition. This > > can > > be frustrating for everyone. The purpose of this proposal is to create a > > good etiquette/rule for the community on how to react when his happens > > and > > in turn keeping the code healthy. > > > Code Yellow (Tip Broken)This happens when one of the following occurs > > to the tip of the code base. All committers should not allowing the > > commit > > of any additional code, unless absolutely necessary, and work to take > > ourselves out of code yellow. > > > - Wave In a Box does not start > > - Wave In a Box crashes on first use > > - Wave In a Box does not compiling > > > How to communicate code yellow Anyone can send a message to the wave > > protocol mailing list ([email protected]) stating that the > > tip is broken, preferable with notes of the state, and requesting > > everyone > > not to check in any code until we are out of code yellow. > > > Hopefully this will start a live discussion and a fix will be forth > > comming very soon. > > > How do I keep working even when the tip is broken? There will be a tag > > named "stable" that is placed on the code base. Code at this tag will be > > OK, > > i.e. not broken. But please, don't check in the code if the tip is broken > > (code yellow). > > > hg pull -r stable > > hg update stable --clean > > > Anyone can update this tag provided you've done some basic testing to > > make sure that we won't be in code yellow at the time of the tagging. You > > can set the label with > > > hg tag stable -f > > > hg push > > > Kind Regards > > > -- > > David Wang > > > -- > > You received this message because you are subscribed to the Google Groups > > "Wave Protocol" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<wave-protocol%2bunsubscr...@goog > > legroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/wave-protocol?hl=en. -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
