> -----Original Message----- > From: James Carlson [mailto:James.D.Carlson at Sun.COM] > Sent: Friday, September 26, 2008 8:14 AM > To: Jose Borrego > Cc: 'Milan Jurik'; on-discuss at opensolaris.org > Subject: RE: [on-discuss] hg comments > > Jose Borrego writes: > > There's the problem of project gates. Currently I manage such a gate > and I push the fixes it contains to ON regularly. > > Really? > > That doesn't sound right to me. What you're describing sounds like > debugging a project into existence, which has long been discouraged in > ON. Why wouldn't a project do its work outside of ON until it's > _done_ and only _then_ push?
Well I won't get into why we putback to ON. All I'll say is when we did we knew we still had extensive modifications that had to be made. Since we didn't want to make ON instable we kept a separate gate in which we make those modifications. A test team tests thoroughly those bits before we push to ON. Since we are in ON, bugs are found by users which we fix in our gate (most of the time) to avoid a difficult merge when we push to ON. That wouldn't be a problem if we didn't have to collapse the changesets (even when no merge has to be done) and lose the history. The same thing was occurring with teamware but we could discriminate the CR comments per file. > > At most, I'd expect a very big project to have a few phases of > development for incremental delivery, and in that case, I think you'd > probably want to run separate project gates for each phase, and cease > use of a gate after collapsing the deltas and delivering that phase to > ON. > > That's rather different from pushing to ON "regularly" from a single > project gate. > > > Until I do so I have one changeset per CR, however, pushing to ON > requires collapsing the changesets. At that point you get several > unrelated CRs in one changeset. > > Yes, that's exactly what big projects end up with. > > It's what they also ended up with when using Teamware, so it's not > that much of a change, I think. (And, of course, all my other points > about testing and separability still apply.) > > -- > James Carlson, Solaris Networking > <james.d.carlson at sun.com> > Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 > 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 > 1677
