Re: Rant! (was) Development process in the Ada community

[Michael Erdmann <Michael.Erdmann@snafu.de>]

Marin David Condic wrote:
> "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote in message
> news:3CBC5281.1040202@snafu.de...
> 
>>Interesing, i did not know this. Is there any information about this
>>in the net? May be this formality is why most of the people in the
>>community are not taking part in the standarization process.
>>
>>
> Well think about some of the packages that are in the appendices right now.
> Things like Ada.Strings.Fixed. There is a quite detailed description of the
> behavior of each subprogram in there and I'd suspect you need some part of
> the validation suite aimed at testing compliance with that specification.
> Furthermore, all they provide is a spec and that means the vendors have to
> go out and build the bodies - which for a string package may not be that big
> a deal,
Mean while started to contact them using the ada-comments mail list. The
answer was that i should just send a proposal & rational. Maybe i will
do this asap for a basic container. Just to see what happens.


> but for something like - say - a GUI would be *waaayy* much bigger
> and would hence meet resistance from the vendors. (Do you really think
> they're just chomping at the bit to rush out and spend millions just to get
> themselves compliant with the next Ada standard? ;-)

I gues GUI's was not a good idea, only resonable small building
blocks should be standarized. I think nobody would attempt to
stndarize a complete car!

>>This is what is normally called a defacto standard. Raising initial
>>interest for a certain sloution and setting up alliences to enforce
>>the solution normally creates such standards. But if these alliences
>>breaking up, such standards start to dissolve and lot of derivates
>>of the original solution are back on the market gain. I like to
>>avoid this.
>>
>>
> Trying to do anything real formal to avoid divergence is just going to get
> too costly and difficult. What might work better is some version of
> "Standardization By Inertia" If you got some committee of vendors and users
> to agree on some libraries as the de facto standard and there was a
> reference implementation the vendors all adopted, chances are it would just
> stay the way it is because nobody is going to want to spend their own money
> to change it without a compelling reason.
I agree on this also. I think the way of establishing first a defacto
standard will be the best process. This could be done in the following
steps (i guess):

  - Raise interest
  - Setup a group producing some result for the community
  - Distribute the software as wide as possible
  - Run several itterations (event incompatebil ones)
  - After you reached stability either propose to ISO or seek alliences
    with vendors.
  - Propose to ISO to stabilize the package

I think the first 4 steps are typlical for open source software which
is developed in the net.
The two steps following have to be established by some means.May be
it is in the interest of the vendors to standarize packages of this
process in order to avoid the some body is chaging them via the
same process after they have reached stability (> step 4).
So the trick is to develope in the net in a distributed manner software
till end of step 4.

> 
>>But your second tier idea may be the right point! This second tier
>>could become some kind of public entry process for the ISO WG which
>>is in the first stage (input) less formal and at the output as formal
>>as ISO requieres.
>>Establishing such a second tier interface to the public would be
>>an interesting project for the open source community, and may
>>be some ideas of the JPC may be taken over for this purpose.
>>
>>
> I really think that once you stick the initials "ISO" on it you're asking
> for a rigid, validatable, *sloooooow* process to be put in place. It would
> be better to form something up under some less formal structure. It might
> work better to do something under the auspices of SIGAda - that's how ASIS
> got done, IIRC. You need the input and guidance of the vendors because if
> they won't sign up to include/implement whatever you come up with, the whole
> game is over. If the vendors said "We'd be interested in libraries that
> cover the following subjects...." and your working group could come up with
> an answer they'd be willing to adopt, *and* you could come up with the
> necessary resources to build a reference implementation, you might see a
> fairly quick and agile process evolve that probably wouldn't see a lot of
> divergence from the "standard".
> 
I will check out ACM!


> I really doubt that lobbying for *anything* to happen under ISO is going to
> result in any sort of process that meets the objectives you seem to be
> supporting. The less formal it is, the more likely it will be to move
> quickly and be willing to listen to what you have to say. If you got
> something that was adopted as a de facto standard, it would likely be a lot
> easier to get it included into the ISO standard after that point - if that
> seems at all important if/when that happens.

There i do agree completley, ISO will not be the driving part of
development. ISO will be the finalization of the development.

> 
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> 
> 
> 
>