I agree, the manual tagging of "stable" is certainly a drain on developers.
Given WIAB involves both a server and a Web client, the best solution would be the use of an automatic build system that uses "webdriver", "selenium" or any type of system test, which launches WIAB and automatically verifies that some trivial conditions. Finding the "stable" build would be a matter of looking up on a dash board for the last green version. The proposal of a "stable" tag was an intermediate solution. If Appache supports webdriver or selenium, that would be fantastic. On Sat, Nov 27, 2010 at 10:41 AM, Michael MacFadden < [email protected]> wrote: > 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%[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]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > -- 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]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
