[SAGA-RG] OGF 26 notes, errata process, and mtime...

[Andre Merzky]

Quoting [Thilo Kielmann] (Jun 02 2009):
>
> So, what are we doing with this [mtime problem]? Can we
> still smuggle this into the "errata" thingy??? 

Well, I did not send around notes from OGF26, yet, so let me
fix this right now.

Apart from the usual stuff, there have been two major
discussion points:

  - In the sessions, we discussed approaches to a workflow
    package.  The general feeling (between the 4 active
    participants :-P) has been that task dependencies are an
    excellent entry point.  Branching and looping should
    also be rendered as special task types.

    Outside the session we got good input to the topic as
    well, and a number of external pointers: Legion, Unicore
    (AJO) and iRods all are good references, and are closer
    to our scheme of things than I would have thought.

    We are actually already implementing something like this
    in C++, so you can expect an explicit proposal soonish.
    If anybody is interested in an earlier discussion, on
    the list or by phone, please let me know.


  - The GFSG discussed our errata procedure.  It was agreed
    that the errata are well motivated (because mostly
    triggered by implementation work) and mostly backward
    compatible (there are two items which are not, but all
    implementations have them implemented the same way I
    think).

    However, GFSG wants to motivate us to finally produce
    our experience document for GFD.90, to get the Core API
    from 'proposed recommendation' state into full
    'recommendation' state.  It was thus proposed to delay
    the errata until that experimental document has been
    handed in, and treat the errata as accomanying spec
    update.

    It makes sense I guess, even if I don't like the delay
    myself.  Anyway, I started to work on the experimental
    document, and will approach the individual
    implementation groups for input over the next weeks.
    Lets try to get it out by next OGF.

    So, on the up side, we are still able to fiddle around
    with the errata for a while, and should try hard to use
    that time to get our implementations in sync.

To answer Thilos question: I think mtime should go into
errata, no matter what way we decide to solve it.
Semantically, it is a small change, and it is already
imlemented in JSAGA - which makes it an errata IMHO.

The typed attributes should *not* be part of the errata, but
rather go either into an extension package, or into v2.0,
IMHO.  It was a conscious decision to go for strings in
v1.0, so now saying we need to 'fix' it makes not much
sense.  Maybe I shouldn't have brought it into the mtime
thread, sorry for mixing up issues here...

Best, Andre.



-- 
Nothing is ever easy.