Call for rpm5.org architectural decision.

On Saturday, 28. July 2007 at 10:49 pm, "Thomas Lotterer" wrote:
> I want to suggest we create and maintain a document describing
> architectural decisions of rpm5.org. [...]
> - one decision I'd like to see is whether rpm5.org
>   is going to support BDB, SQLite, both, others etc.
> 
Ralf and I like SQLite for various reasons not to be discussed here. We
were delighted to see SQLite being available for use with RPM and wanted
to use it for OpenPKG, which was at that time way behind using RPM
4.2.1. Now we are able to upgrade OpenPKG to the new RPM5. But we found
out the SQLite implementation is very rudimentarily from a technical
point of view. The existing database abstraction inside RPM may be able
to use any database as key+value store, an approach that cannot unleash
the power of any RDBMS and SQL. While posting several issues with SQLite
we found out that the number of SQLite protagonists in the team is
actually very, very, small. In fact, many inquiries did not lead to
discussions but more to database fights. Facing the tremendous work
which would need to be done to leverage true SQL(ite) power with the
available manpower to actually do it and also taking the acceptance of
the existing team members into account, my conclusion, which could lead
to our first architectural decision, is the following proposal:

Issue:
- database support in rpm

Decision:
- exclusively use Berkeley DB

Reason:
- marginal support for alternatives from rpm-team developers
- key+value approach cannot unleash RDBMS power anyway
- existing schema not suitable to create complex SQL queries
- abstraction layer incomplete and focused on BDB features
- no use case found which requires a BDB alternative

Consequences:
- rip out other database support from concept, code, build, docs, ...
- discontinue any attempts to establish a DB abstraction layer

I prefer to have one DB supported well and with enthusiasm over
fruitless discussions about improving incomplete concepts and
maintaining zombie code which is impractical to use.

Now comes the interesting part. How do we actually make a decision?
Feedback to the actual topic and decision making much appreciated. 

-- 
http://thomas.lotterer.net