Thanks ... Lukas
Danek Duvall wrote:
> On Thu, Oct 25, 2007 at 04:17:18PM +0200, Lukas Rovensky wrote:
>
>> You are right, I asked about something different and maybe I was just
>> thinking too much the 'patch way'. The scenario I had in mind is like the
>> following -- a customer has a problem, a fix is implemented and needs to be
>> verified. In such situation it is now possible to create a restricted
>> patch, which the customer can install but no additional patch can be
>> installed on top of it. Once the fix is verified then a regular patch can
>> be created (the restricted patch is uninstalled and the regular patch can
>> be applied).
>
> Ah, okay. Yeah, if you want to do something like that, you can, except
> that it'd still be up to the customer to freeze it manually. You'd
> increment the branch version (probably adding another component from the
> version to which the fix was being applied), and have the customer freeze
> the package to that branch version. You could then actually improve the
> "patch" along that branch until you and the customer were satisfied,
> allowing the customer to apply the updates freely along that branch.
>
> Once you decided it was okay to bring out of testing, you can apply the
> fixes to the main source tree, and release a new version as you normally
> would, and the customer would unfreeze that package.
>
> Think of it as a stream of change whose lifetime is the testing of the fix
> to a particular problem, and possibly directed and/or available to only one
> customer.
>
> You could do this with multiple packages in synchrony by specifying an
> incorporation (possibly unique to this problem) that incorporated all the
> packages participating in the process.
>
> Danek
