Bugs, patches and distributed systems
[1/5] from: sunandadh:aol at: 25-Mar-2002 6:20
Brett:
> I was thinking some more about the issue of bugs, patches and
> distributed systems.
A large part of the problem is that RT only release a new version once a year
or so. In the meantime, we all work round the problems or tweak'n'trade Rebol
patches.
It'd make more sense if RT adopted more regular "point-releases" to address
bugs.
But that'd have a drawback -- we'd all be forever testing the new releases to
check that the fixes don't break our applications.
Here's a suggestion that works at least for mezzanine-level system functions.
There should be something like Patches.r in my application directory. I can
download the most recent Patches.r from RT as often as I like.
Patches.r Isn't just the latest source for each function. It's cleverer than
that. If a function has been modified three times since the major release,
patches.r contains all three versions. Rebol has some start-up magic that
lets me accept or reject the patches I need, e.g.
rebol -p [layout 1.2.1 view 1.2.2 make-face original]
the -p says apply the patches according to the following block. The block is
pairs of function names and the version required.
Patches to the system object could work in the same way -- the patch would
need a symbolic name so we could select the ones we want.
In the ideal world, there would be some way of generating a bug list and
prerequisite conditions ("patch 2 to function X required patch 1 to function
Y") from the data structures in patches.r.
Native functions would be a bit harder to patch in this way. But I'm sure RT
can think of something along the same lines.
Sunanda.
[2/5] from: hallvard:ystad:helpinhand at: 25-Mar-2002 13:24
Dixit [SunandaDH--aol--com] (12.20 25.03.2002):
>It'd make more sense if RT adopted more regular "point-releases" to address
>bugs.
<<quoted lines omitted: 3>>
>There should be something like Patches.r in my application directory. I can
>download the most recent Patches.r from RT as often as I like.
Patches alone won't do, because we need to specify what version of rebol our programs
will work on. Having predefined milestone releases every 6 months and irregularly releasing
patches inbetween could be a good solution, I think. This is how the OpenBSD team works,
and in my opinion, that works fine.
~H
[3/5] from: sunandadh:aol at: 25-Mar-2002 9:51
Hallvard:
> Patches alone won't do, because we need to specify what version of rebol
our
> programs will work on.
I've run into that problem myself -- someone started telling me an
application was failing for no reason I could duplicate. It turned out they'd
accidentally gone back to using View1.2.0 rather than 1.2.1. I added these
lines at the top of the application to detect the version needed:
if "1.2.1" > copy/part to-string system/version 5
[request/ok "Sorry. We need at least Version 1.2.1 of Rebol"
quit
]
If you have concerns about running the right version, this is an easy fix --
though I agree RT could come up with something more elegant.
Distributed systems will also come across the problem where my code executes
one of your scripts but our scripts disagree on what patches/versions we
need. I don't see any easy solution for that other than one of us makes our
code compatible with the other's
Sunanda.
[4/5] from: jason:cunliffe:verizon at: 25-Mar-2002 7:46
> Here's a suggestion that works at least for mezzanine-level system functions.
> There should be something like Patches.r in my application directory. I can
<<quoted lines omitted: 4>>
> lets me accept or reject the patches I need, e.g.
> rebol -p [layout 1.2.1 view 1.2.2 make-face original]
RVS - rebol versioning system
great idea!
Recently I have been reading up on CVS [concurrent versioning system] and
wondering how to base a rebol/vanilla dynasnip extension on the idea. I have
been interested in how it might work for media content, sequences, collections,
metadata and associations.
..Kind of general purpose VCR for media-oriented metadata. The reason I
especially like to do this in rebol is because it seems to encourage a very
granular approach. Simplexity system where each little piece of rebol is just
smart enough. But a powerful whole system set of behaviors can emerge. The way
rebol treats everything as data makes this seem more 'natural'.
A fascinating article for inspiration is the new[ly] [named] science of
'Proteomics'. Check out the April issue of Scientific American Magazine for an
clear introduction.
./Jason
[5/5] from: chalz::earthlink::net at: 25-Mar-2002 23:21
> if "1.2.1" > copy/part to-string system/version 5
> [request/ok "Sorry. We need at least Version 1.2.1 of Rebol"
> quit
> ]
While initially reading about the REBOL [] block in a script a while back, I
remembered a list of 'suggested' fields to use, one of which being a Requires
block. In a perfect world, people would open up the scripts they were about to
run and give them a once-over, then verify that they have all that's required
and approve of the general operation. In a perfect world.
But yeah, that is a pretty quick and easy fix.
> Distributed systems will also come across the problem where my code executes
> one of your scripts but our scripts disagree on what patches/versions we
> need. I don't see any easy solution for that other than one of us makes our
> code compatible with the other's
Which is frequently what you have to do right now anyways, unless people
agree to use similar setups, layouts, libraries etc ahead of time. This could
be another good place for the online library - scriptA and scriptB are working
together, each one requires different patch sets, each one can just call up the
patches it needs on the fly. Again, this requires being connected or having
easy local access to a copy of the DB... oy.
-C
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted