How We Can Have Nice Things

[Ali Lloyd]

I wonder if we can come up with a sort of format (maybe using yaml or
something similar) which specifies the changes, a script that formats the
changes into a diff, and a plugin that we have which applies the changes.
So imagine the following, for example:

---------------------------------------------

stack-script: &standalone-settings

on preOpenStack

   .... some code ...

end preOpenStack

 changes:

    -long id:     stack "revStandaloneSettings"

    script:       *standalone-settings


    -long id:     button "blah" of stack "revStandaloneSettings"

    showBorder:   false


---------------------------------------------

The plugin would then generate a diff (or even better - vulcanbot runs some
kind of script to make the diff) which comes out as

---------------------------------------------

stack "revStandaloneSettings"

script:
< handler preOpenStack>
-  set the cantModify of me to true
+ set the cantModify of me to false

button "blah" of stack "revStandaloneSettings"

showBorder:
- true
+ false

---------------------------------------------

When we are happy with the diff that comes out, we use the plugin stack or
whatever it is to apply the changes to the stackfile(s).

That way the whole stack doesn't have to be checked or serialised, it's
just a serialisation of the changed bits.

I think someone suggested something vaguely along these lines before -
actually in some sense it's an amalgamation of many of the previous ideas
on the list.


On Fri, Sep 11, 2015 at 5:39 AM Kay C Lan <lan.kc.macmail at gmail.com> wrote:

> I'll admit I don't fully understand all the ins and outs and the full
> ramifications of how many straws are being piled on the LC Teams back, but
> if the problem is binary vs text may not the simple solution be to shift
> some of the weight back on the contributor to make it easier for the Team,
> ie instead of just supply the amended stack, actually list out the amended
> handlers, the added handlers, the amended objects and the added objects.
>
> I'm thinking some sort of Template Form similar to what the QCC uses to
> enter bugs.
>
> A field to enter the full name of the effected script:
>
> >The stack script of stack revscripteditor.rev
>
> A field to enter the original hander,
>
> >on extractHandlerNames
> >...
> >...
> >end extractHandlerNames
>
> A field to enter your amended handler.
>
> >on extractHandlerNames
> >...
> >amended bits sprinkled throughout
> >...
> >end extractHandlerNames
>
> [Makes it easy to copy and paste into a Text Editor for diff analysis]
>
> Repeat above for as many handlers you've amended.
>
> A field for entering Added handlers.
>
> >on filterHandlerNames
> >...
> >...
> >end filterHandlerNames
>
> Repeat above for all your added handlers.
>
> A field to enter the full name of any object you've amended
>
> >Field 'handlerlist' of stack revscriptEditor.rev
>
> A field to enter the original properties:
> >height: 500
> >loc: 60,250
> [just the relevant ones]
>
> A field to enter the amended values
>
> >height: 480
> >loc: 60,240
>
> Repeat above until all amended objects are listed
>
> A field to enter the full name of any object you've Added:
>
> >Field 'filterHandlerList' of stack revscriptEditor.rev
>
> A field to enter the properties of the new object which aren't default:
>
> >height: 20
> >width: 120
> >Loc: 60, 490
> >...
> >...
>
> Repeat as above for all added objects
>
> Provide the recipe [text] for the cake, not just the cake [binary].
>
> I guess Charles would be the one to comment on how difficult it would have
> been for him to list out all the original
> scripts/handlers/objects/properties he amended, along with the actual
> amendments he made PLUS all the scripts/handlers/objects/properties he
> added. If he considers it difficult and a deterrent to community additions
> then it would certainly add weight to the comments that it is a burden for
> the LC Team. If Charles considers it easy, then maybe it would help?
>
> If the LC Team follow your recipe, but don't get the cake you sent, then
> the contribution is rejected until you identify the amendments/additions
> you made that were not correctly reported in your original submission.
> Again placing the burden on the contributor not the LC team. In fact I
> would suggest initially posting such recipes to the community:
>
> 1) so they can be checked by the community and no LC Team time is wasted.
> 2) because the community is sure to spot 1 or 2 improvements/enhancements
> that can be added prior to submission.
> 3) certain Community members could be considered Quality Assurance Reps
> (CQAR), and if they have built the recipe and confirmed it works, checked
> the amendments/additions to confirm nothing nefarious exists, then rather
> than the original author submitting the work, it's submitted by the CQAR
> (Richard, Marks, Jacque, Monte...) which would reduce the amount of
> checking the LC Team would need to do.
>
> Maybe not so much a tool as you requested but a workflow.
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>