Ali Lloyd wrote:
On Sat, Sep 5, 2015 at 12:02 AM Richard Gaskin wrote:
Let's not let Github's limitation impede meaningful work.
What we need is a way to ensure that the changes applied are
the changes we want.
Format is a distant second to that, merely a means to that end and
something we can overcome.
Let's brainstorm ways to fix this critical problem holding up so
much of the work we could be sharing.
...
Yes, I completely agree that this is a problem which needs a
solution. But the fact remains that we currently don't have one.
Au contraire, mon ami: We're surrounded by possible solutions, we just
haven't picked one yet.
I agree that solutions favoring Github should continue to be preferred
wherever practical.
But Github is only a means to a goal, and of course not the goal itself.
Where it helps achieve a goal that benefits LiveCode it should be
used, and where it may impeded a goal that would benefit LiveCode other
options will be needed, perhaps crafted in LiveCode itself (it's a
wonderfully flexible and efficient language). Software was produced long
before Github was born, and will continue to be produced long after
Github is replaced, so we have a long history of productive options to
inspire us as we work our way toward a solution.
Thankfully most of what we need is already handled well with the current
Github setup, including not only the engine but also docs and nearly all
libraries.
But from time to time we may have an edge-case opportunity for a
component in LiveCode's native file format, such as the one on our
plates now. For those we'll want to be able to act on community
contributions where they help add value to the LiveCode experience.
It may be helpful to separate what we *want* from what we truly *need*.
Clearly what we *want* is a Github-savvy solution, but Github was never
designed for how LiveCode works so there are edge cases like this one
where that one option isn't practical.
What we *need* is the ability to:
- IDENTIFY specific changes between a master stack file
and a modified one.
- REVIEW those changes to ensure fitness, compatibility,
and security.
- MERGE those changes into the master, if for some reason the
master has been altered since the changes were submitted. (if
the master hasn't changed of course the new stack file can
simply become the master going forward).
There are specifics of each step we could explore in more detail, but
it's worth noting here that it seems from your post that the v7 IDE is
effectively frozen in terms of LiveCode Ltd's changes, with the team's
efforts going into the dev branch for v8, and dependent on components
that require v8's Builder language and thus preclude traditional
backporting.
That the v7 IDE has few if any changes between minor release means that
a merge per se may not be needed. And since an object merge is the only
complex step not already addressed through relatively simple tools, we
have hope for a workflow that may allow the community to continue to
advance the IDE shipping with the current product while the team focuses
on the future.
I'll follow up offline to explore these details with you in our next
Community meeting, and look forward to reporting back here either a new
workflow for these rare edge cases or a solid understanding of why the
current IDE cannot be enhanced.
--
Richard Gaskin
LiveCode Community Manager
rich...@livecode.org
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
