The following comes from the #storyboard irc channel
> 18:44 < krotscheck> Ok, so we’ve had a couple of recent patches where reviewers, in particular zaro and
> rcarrillocruz, explicitly asked for both unit tests and documentation.
> 18:44 < krotscheck> I _like_ this
> 18:44 < krotscheck> So while it might slow us down, the more of this we do the better :)
Followed a while later by
> 23:21 < krotscheck> ARGH. Writing this documentation reveals bad things about the code I wrote :/
A lesson for us in Baserock I believe :)
+44 7740 351755
On 15/12/14 16:16, Mike Smith wrote:
> On 15/12/14 16:06, Justin Erenkrantz wrote:
>> On Mon, Dec 15, 2014 at 5:13 AM, Pedro Alvarez
>> <pedro.alvarez(a)codethink.co.uk> wrote:
>>> Also, can we put the ZK server and the ZK client in the same system?
>>> Can they
>>> co-exist? I think that we could avoid systems duplication if the
>>> system has the server and the client (in a zookeeper-tests stratum)
>>> and you
>>> can deploy the same system as server or as client. But this may need
>>> creation of a configuration extension I guess, so you can forget
>>> what I just said.
>> In the general case, yes, you can co-exist ZK server and ZK clients on
>> the same machine. I think that what Mike has posted is a set of
>> example apps leveraging ZK. -- justin
> Correct Justin, ZooKeeper client and server is installed in both
> cases, as the zookeeper installation as a whole has the capability for
> both. The applications are the main difference between the server and
> client version. these are split up mostly to make it as easy as
> possible for the client to install the relevant software on the
> machines that they are using to test the ZooKeeper functionality.
> during early testing stages I did have client and server co-existing
> on the same machine, however doing that really does not show of the
> distributed file system that ZooKeeper is needed for.
>> baserock-dev mailing list
Another project team at Codethink are currently trying to import a Rails
application into Baserock, so that they can build and deploy a Baserock
system that is able run their application.
The tricky problem that they need to solve is organising the different
components needed by their system - in this case the Ruby Gems - into
chunks and strata.
They have also identified a possible requirement / use case to work with
definitions files from different repos (rather than having every
definitions file in a single repo).
The UI offered by Baserock at present
a: is command line only
b: focusses on *using* definitions files, not on creating, managing
and maintaining them.
One developer working on this problem commented
> it needs a bit of thinking to make import ruby projects easier. the
> import tool works well, but i am a bit fed up with messing around
> with command line tools when i think the whole thing should have a
> yes, i personally don't want to do much more with baserock until i
> find it more usable. The underlying ideas are great need to have
> bazillions of strata for each gem in a ruby project, just makes a ux
> which was hard work, even more hard work
It seems to me that this class of task - moving and manipulating chunks
of data around in a hierarchical structure (repo - system - stratum -
chunk), then validating the changed hierarchy - is ideally suited to a
graphical rather than a command line user interface.
I believe this is a problem that is likely to be faced by any potential
users of Baserock who want to use it, for example, to get a large base
of existing software systems, tools, applications and libraries running
on Baserock systems, and to manage and maintain those systems.
The project should perhaps consider implementing such a GUI application
for manipulating definitions. An initial implementation could start with
using the information created by the import-tool for Ruby projects.
Later implementations could match the progress of the import-tool in
dealing with other package management solutions.
I realise this is not going to be a high priority for the project, at
least not any time soon. But it is perhaps something that could be put
on a wishlist or roadmap, so it could be picked up by any community
members whose skills, experience and interest is more focussed on
specifying, designing and implementing such GUI applications, and / or
whose paying customers might be interested in using such an application.
+44 7740 351755
There is a more recent version of boost available.
Patrick Darley (1):
Update boost-tarball lorry to 1.57.0
open-source-lorries/boost-tarball.lorry | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The intention of these patches is to create a new repo on gbo for
baserock-flashing-tools to home a set of tools and scripts for flashing ARM
The current script, baserock-flash, has support for a jetson-tk1, however I was
testing this with a script for a wandboard as well, so could also provide that
(after cleaning it up)
The idea is that the generic folder creation/copying/dd stuff is taken care
with by the base script, and any board specific stuff (e.g flashing u-boot) is
done in a board script
This also works baserock, and allow you to flash a jetson board from a baserock
jetson board. However I am currently creating the strata to add to baserock for
James Thomas (2):
Add baserock-flash script
Add a board flashing script for a jetson-tk1
The following parameters are referenced in morphlib/writexts.py, but do
not seem to be mentioned in any specific write extension (that I could see).
Does that mean they are applicable to *all* write extensions or to only
a subset? If the latter, what is the subset? Is it different for each
Also, can anyone point me at any instances of their use?
+44 7740 351755