[oi-dev] current process for architectural decisions OI

[Thomas Wagner]

Hi Alexander
On Thu, Aug 15, 2013 at 09:44:36AM +0400, Alexander Pyhalov wrote:
>  Hello, Thomas.
> 
>  Thomas Wagner писал 14.08.2013 22:28:
> > What is currenty the process / method / agreement for
> > architectural decisions in OI?
> > Is there any? If not, I take it that a single person
> > who gained write access to the repositories, can put
> > any change into the gates, right?
> 
>  I'm afraid you are right... There is no any formal process.
>  However, I think we try to discuss.
> 
>  What do you suggest? I think the main problem with public discussion or
>  formal process is that there is no enough developers
>  for constructive discussions.

I don't think we have too few developers to comment or hold
discussions, in my view, it's more that we don't bring to
attention what is currently developed. As a side effect
I believe making development more public attracts people
to comment on topics, even if they do not necessarily
do active OI development.
But their view, needs, knowledge, experience, concerns
should really be used to keep the quailty high in the
long term.

So I would suggest that there are two kinds of processes.
One for quick and simple changes, to primarily inform
the others about a planned change with little to no
risk or impact. That would be a little form to fill in.
Example would be "updating libz from 1.1 to 1.2,
comments, prolems solved, CVE-numbers, planned target
devel release".
In case others have cncerns they could ask for making
that a full case, as described next. Else, it is
just closed and approved.

Another process would be for large scale changes or
such changes where incompatibilites are introduced
or are expected.
That may be impact on OI's own code, for example
large changes to the Gnome Desktop. Or changes in
OI which affect external Projects using OI as a
building block.
Example would be chaning default perl version or
a major change to the gcc compiler.

If a concern is raised, then this should be discussed
and come to a decision that the change is not ready
to be commited, or it is ready to be commited with
or without some described changes.
There are common ways to get such votes, say there
are no "-1" and at least two or three "+1" to get
the case approved.
If there is a "-1", this needs to be described why.
Additionally there should be said what needs to be
done to remove that "-1".

Those two processes could be very similar to what has
helped to get the Solaris ON code to the quality level
it has today: Fasttracks and full PSARC cases.
(Others can comment on that methods in more detail,
possibly they have a description of the Solaris change
process)

Or we could use what illumos currently uses, I belive
it supports similar targets.

I don't know if there is a public description of the
illumos way and the old Solaris change process.

Main target should be that the whole process thing
is not overly complicated and keeps paperwork at a
minimum.

It *should* help asking other smart developers and
add their experience to get to decisions which are
good for long term quality.

Regards,
Thomas