Latest revision as of 18:29, 2 December 2010

Day 3

Last day today. We are still in room 2 (the other room has no heater, or something), so we fit around the table as before (my seating plan is still ok)! Also snow overnight meant that I didn't get in until 09:50, so I missed the first discussions anyway.

09:50 Florian RT packaging project

Lots of discussion (continued later, too). When Glyn tried to move on to Roadmap Revisit, K got us talking about packaging RT project again.

10:00 Roadmap Revisit

D was overheard saying "...web apps; JSF; JPA...press enter and get a personalized build..." Sounded good, but was still about RT packaging, I think!

Eventually the discussion got to the roadmap, and some thoughts arose about time-zode displacement, work rates, Skype contacts and general ambition. It seems that we are in some danger of biting off more than we can chew, though this doesn't deter the SAP enthusiasts. Good for them, I say.

[While this is going on I get a few pokes from Glyn about votes for committers. All of the candidates are in the room — what can I do? I vote for them. Actually, I could see nothing that would prevent me from voting for any of them.]

10:10 Virgo Tooling

Glyn noted that Bundlor and STS tooling (specific to Virgo) were being donated to Eclipse, soon. This seemed to meet with approval. However, there is little or no appetite for Bundlor in a Maven/Tycho shop, which continues to favour 'manifest first'. I'm still not clear whether this works very well, though a hybrid system could be best of all. Keeping the Eclipse dependencies in line with the other places the dependencies are recorded is still a pain. One place is best, yes, but is it better to derive the manifest, or to declare it? Even in a manifest-first culture, it must still be a pain to write the manifest file.

Despite the change of topic K is still talking about the packaging story — "How is the current scope?" (what does that mean?) Florian talked about what the RT packaging project is doing at the moment — it seems to want to avoid having any code of its own, but to act as a catalyst to making the other RT projects interoperate so that they can be easily packaged together without requiring any 'glue'. This sounds ambitious.

As the talking continued, my mind wandered.... the visitors were clearly engaged, the topics technical and varied, and the multiple discussions earnest. D G K and F all talking about this, but the intersection with Virgo is not obvious to me.

At last Glyn calls for a ...

10:33 break

10:49 Brainstorming

Glyn introduced two brainstorming sessions (for the results see the brainstorming page).

The parties present took a little while to get into the spirit of it (there is a tendency to be self- or peer-critical of suggestions) but after a while we had a lot of ideas for the future of Virgo and the possible tools and techniques we might employ in the developing of it.

On the whole the most fun I can remember in hours (well, I did arrive late and lose the thread, didn't I?).

??:?? kernel overview

At the end of the morning (I didn't note the time) Glyn gave us an overview of the kernel repository. This is by far the most complex part of the the Virgo code base, and consists of about 12 sub-projects, many of which are bundles. (Those that are not are integration test suites.) Glyn used live S101, Eclipse, OpenGrok and git to show how we get around the code base and what it looks like. Particular note was taken of the deployment pipeline, the InstallArtifact interface (and implementation classes), the abstract bundle, configuration, plan, etc, and other classes in passing. Opportunities for simplification were noted when we encountered them (some pieces of code were legacy and might be removed — provided it was checked that this was safe) and the test idioms and usage highlighted.

I felt that this was a thorough (though fast) tour of the repositories, as well as an indication of how we might go about making small changes.

After this we had lunch.

[Lunch arrived, despite the travel difficulties. Snow in the area fell to a depth of 10-25cm (about 6-9 inches), and many of the smaller roads were treacherous. I live in Hursley, for example, and spent an hour in the morning (with my daughter) shovelling snow from my front drive and the drive I share with my neighbours. It is a tribute to the staff from the cafe opposite that we got lunch at all today. Well done and thank you to them!]

14:00 Q&As

Dmitry asked about classloading. Two detailed questions which, although firmly routed in Java classloader lore, Glyn answered clearly enough for me to understand, too. These have a direct bearing on fundamental OSGi technology, so were well worth asking. I expressed a hope that the answers were placed in online (here?) where they would do the most good.

Krasi seemed to have written the answers before — I hope he puts his pages up here for us.

Although asked I do not recall if anyone else had some Q&As in this session.

14:25 breakout into groups

While K, Hristo and Georgi satisfied their insatiable desire to talk about p2 (spoilt only by others in the room having other discussions), Glyn and Borislav went to our office (next door) to have a go at making a patch contribution. This was to take Borislav through the process, and to show him the sorts of things we do when working on code. When these two returned some while later, they had not only put the patch up (still a contributor not a committer, Borislav must have seen Glyn performing the IP steps and authorship mods required of a committer putting up someone else's patch—soon he will be doing this for his colleages) but were submitting bugzillas for items spotted during the process. (I guess that's what they were.) All this diligence was most heartening.

My time was spent challenging K, G and H about the p2 integration with the kernel. I couldn't see how the deployer (in the kernel) and the p2 repository were supposed to communicate (or share knowledge about) the runtime state of the kernel. It seemed too much information for a repository to me.

After some to-ing and fro-ing (the terminology seems a hindrance rather than a help sometimes) I was convinced that there was a real requirement being met here. The ability to adjust the run-time state of a kernel instance by merely updating the configuration in a repository (which contains the configuration information along with the artifacts that make up the instance components) is attractive, and ought to be possible without the kernel actually running. It's a nice thought, and yet it requires quite a lot of information sharing between Virgo and the p2 repository — at least at first glance. How do we record things that are not known by the OSGi framework? (The answer appears to be "touchpoint"s which are how you talk about artifacts which are not bundles in the p2 repository.) By building on OSGi, Virgo has constructed run-time information (which has semantic force) unknown to a pure OSGi framework instance, and therefore makes an arbitrary repository incapable of recording it.

Along the way the mechanisms of OSGi extension used by Virgo (in the kernel and in the web layer) were criticised as not being scalable enough. Although there is yet to be hard evidence that the implementation techniques cause problems. (To give one example, the technique of listening to bundle events (start, stop etc.) to allow the kernel to intervene when appropriate, might involve a cost proportional to the number of bundles in the system, independent of the number of occasions where such intervention is required. This could be a valid criticism—are there other ways to implement listener-driven actions?)

17:00

OK we are near the end. We talk about when we shall meet again. (Twice a year seems the consensus — "in Sofia!" everybody cries — and if the Sofia chocolates are anything to go by, I heartily endorse that.) K brings out a bottle of Bulgarian red (2006) and gives it to Glyn — I'll not see it again! — and this gesture is well received. Thank you.

We suggest pgi.connect for community calls in future (like Skype but with conference facilities and hosted by SAP), and our friends depart back to their hotel.

In the morning they travel hopefully to the airport (in London). Florian had booked a flight out of Southampton airport to London, but as this was cancelled on the way in, we hold out little hope for him (or the others) getting away tomorrow. We hope their forced stay in London (if it is forced) will be a pleasant one and wish them all God speed.