Conference iosg::all-in-1_v30

I gues you noticed that my statement did not match the ACLs.  My statement
stands, I just copied the listing AFTER the customer made the change.  It
should look like:

DO_SHARE.DIR;1            1/3       OA$MANAPP             (RWE,RWE,RE,)
          (IDENTIFIER=OA$PRVAPP,ACCESS=READ)
          (IDENTIFIER=OA$PRVAPP,OPTIONS=DEFAULT,ACCESS=READ)
          (IDENTIFIER=OA$MANAPP,ACCESS=READ+WRITE+EXECUTE+DELETE)
          (IDENTIFIER=OA$MANAPP,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE+
          DELETE)
          (DEFAULT_PROTECTION,SYSTEM:RWED,OWNER:RWED,GROUP:RE,WORLD:)


I have my hardcopy in front of me now so I know this is right.

Darryl

    
    Hi Darryl,
    
    You're right. The Site (standard) TXL directories (OA$SITE_*_SHARE: &
    OA$SITE_*_<language>:) contain an ACL in which the ACE for OA$PRVAPP
    and OA$MANAPP are mixed up. They should be as in .0.
    
    The OA$PRVAPP ACE was added once it was decided that the elements in
    the TXL directory would get a higher protection and that they sould
    always be included in the TXL. However, every element which doesn't
    have W:R gets an ACE for OA$PRVAPP.
    
    > Has this been corrected yet?
    
    It is a known problem...
    
    Ciao,
    
    	Simon

    Darryl,
    
    And as you know we don't discuss futures here, hence Simon's carefully
    worded and correct response.
    
    Regards,
    
    Andrew.D.Wicks

    Andrew,
    
    I had no "obvious next reply" and I am well aware that we do not
    discuss "FUTURES" HERE!  I saw no reference to this problem, so I was
    just pointing out this BUG.
    
    As far as futures go, I would not think that asking if a BUG has been
    fixed would jeopardize the ALL-IN-1 project.  It's not like I was
    asking about what's new in the next version.  
    
    
    Regards,
    Darryl

    Well unfortunately even asking if a bug is fixed *IS*  a future. I'm
    not sure if it has happened to ALL-IN-1, but there have been cases
    where products didn't fix bugs that they'd said they would where a
    customer ended up sueing Digital, hence our caution even about bug
    fixes.
    
    More realistically, we've often fixed bugs, to later find that they
    adversely impact performance or break something else, and hence we
    don't like to say what is actually fixed until we actually ship (or are
    very close to doing so!)
    
    Sorry,
    
    Graham

    Graham,
    
    Maybe I just come over wrong in this conference.  It would seem that I
    have been slapped, so all I'm trying to do is defend/protect may honor.
    
    Without doing a detailed look, here are three other instances by the
    ALL-IN-1 Group of violating this golden rule (so please don't be so
    hard on someone for "just asking"):
    
    
        "This fix will be going into a CMS library in IOSG soon, but you can
        make it for yourself and see that it works!"
    
  
    "I've also logged the bug and fixed the problem in the CMS libraries so it
    will be included in some future release."
    
    "The CM team are aware of the problem and have fixed the bug. We are now 
    waiting for a suitable vehicle for delivery of the fix to the customer. 
    Until the bus comes along, use the fix provided in this note."
    
                       

    Actually, the fixes referred to in .6 were carried out by the CM team
    and not the ALL-IN-1 group. Graham is quite right to defend their
    stance that nothing is definite until it appears in the product. We fix
    bugs, put code into CMS libraries in IOSG, and submit the necessary
    paperwork, but it's up to IOSG to decide whether or not the code goes
    into the product.
    
    Tony (CM Team)

    So the CM team and the ALL-IN-1 Group and IOSG are not one big happy
    family???  I didn't know that.  
    
    Could you explain who do what and to whom, when, and how?
    
    Maybe my eyes will finally open and I will keep my mouth shut. ;-)
    
    
    Darrylf

    Certainly the CM team are just one big happy family with IOSG. Of
    course I have to say that, since I work for Tony sometimes, and he
    might beat me up otherwise :-)
    
    But the fixes provided by the CM team (and the other remote development
    groups) are no different to those provided by any other developer who
    just happen to be sitting in the same room as the rest of the ALL-IN-1
    Engineers in IOSG. All fixes and new functionality are provided using
    the same process, and are all equally likely to be rejected if they
    turn out to have unpleasant side effects.
    
    I try to remove, hide or edit anything that looks like a statement of
    definite commitment to fix something. Obviously this is a value
    judgement, and obviously I don't read every word of every note,
    especially once I see they are about boring things like CM :-) :-)
    
    Sorry if I appeared to be picking on you, I wasn't, I was just using
    your question as an opportunity to restate what I thought was the
    policy here, and a bit of explanation of why (often reluctantly)
    it's like that.
    
    Graham

Of course we're just one big happy team, but remote development groups have 
to comply with the directives laid down by the group responsible for the 
overall health of the product.  We do our job, they do theirs, we all have 
fun together confusing people.  The next piece of confusion is to work out 
why someone in Dublin is answering a note relating to a team based in Turin 
working for a group in Reading.

Tony

    What???  Me get picked on...  Never!  ;-)
    
    No problem here. I'm not one to lay take it!  I know that I open my
    mouth about things that some people might think be best left alone. 
    But then again I expect answers.  I have no problem with anyone picking
    on me as long as I get to pick back.  ;-)
    
    Have a good day!!
    
    Darryl