Possible downside to PQM or ChangeIntegrator?

[John Arbash Meinel]

Nicholas Allen wrote:
> 
>>
>> What people are doing today with PQM is doing different features in
>> different branches, and therefore this is not a problem. This is the
>> way I would recommend doing it.
>>

Well, small changes intrinsically have a little bit of difficulty with
the definition that the test suite must pass before a commit. Because
the test suite may take 1 hr to run, it sort of over-penalizes simple
fixes (like updating documentation).

On the flip side, if you have a knob which says: Don't run the test
suite for this change. Developers might start using it, until you get to
the point that the mainline test suite breaks on one of them, and then
you have to go do surgery before anyone being *patient* can get their
commit merged.

> For major features this is what we would do. But every developer also
> maintains small changes/fixes on the trunk that aren't new features and
> having to submit a request every time to the PQM would be a hassle in
> this case. They could be given push writes to the official trunk and
> then they would have to merge the trunk if necessary, before pushing.
> The advantage here is that every developer's commit would not be
> "wrapped" by the change integrator. The disadvantage is that we cannot
> check compilation and run automated tests before allowing changes on the
> official trunk which would be nice to do.

So I might say that you could have staged branches. Sort of a stable
trunk, and then maybe an unstable one.

You could give people rights (or possibly the Change Integrator) to
merge things without testing into unstable. And having someone checkout
a copy and commit directly to it would also be fine.

And then you could have it polled by the PQM to merge into trunk, and if
it merges and passes tests, then it is merged.

This would give you a sort of "soon to be main" place, and an "official
and stable main".

And then several small fixes may get bundled into a single merge, or
might each be a merge if there isn't a lot of activity that day on the
mainline.

> 
> So I'm just wondering what would be the best solution for us for small
> changes and fixes to trunk that are not large features or anything. The
> change integrator makes this pretty easy to use without the hassle of
> submitting requests to the PQM but I guess we would also need something
> like the PQM functionality for merging feature branches (unless the
> developer merged the feature into their trunk branch but this would then
> lead to the feature being "wrapped" in 2 merge revisions which would not
> be so easy to read when scanning the trunk log).
> 
> Not only that but we want to easily allow a developer to setup their own
> integrator if they like so that this can be easily replicated for other
> branches other than the trunk. This would allow them to be the primary
> author of a given feature but to automatically integrate improvements
> and fixes from other developers. The PQM is not that easy to setup per
> developer. I think the change integrator would have to be a GUI
> application that could be configured on the fly
> (add/remove/enable/disable branches to merge from) and allow developers
> to submit requests to it that would be shown in a queue list.
> 
> We need to make this as easy to use as possible for our developers.
> Currently, many small changes are committed often to the trunk so this
> use case would have to be a smooth one.
> 
> Cheers,
> 
> Nick

Would that be smooth enough for you? You could actually allow the same
thing on the plain trunk, but in my mind that just requires your
developers to use too much self-restraint in determining what is okay to
direct commit to the truck.

It is a hurdle, but I've seen a whole lot of things that *I* thought
were a trivial change, only to uncover something when running the test
suite. Or even just a small subtle bug in what I just wrote, even though
it was only a few lines long.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20061027/47745033/attachment.pgp