Summary of meeting 20031119-1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Participants: Frantz Dhin (theDevil-), Andreas Pokorny (DieMumiee),
Low Zhen Lin (zhenlin)
Advisors: Geert Bevin (Bevin)
Place: #zynot-xeta

Items pending:
* Xeta security model, James Harlow (hythloday)
* XBuild tagging, Low Z. L.

Items partially completed:
* XBuild specification, Low Z. L.

Items announced:
* XBuild IDE, A. Pokorny

Due dates:
* January 2004, ComponentKit
* January 2004, XBuild specification
* January 2004, Local Xeta

Ideas brought up:

* Advanced slots mechanism.
Slot identifiers are currently defined as a single value. This is very
limiting.

The new slot identifiers will be an attribute list, listing which
attributes makes the package mutually exclusive. For example:

apache-1.3.29 : "1;"
apache-2.0.48 : "2;"
apache-2.0.49 : "2; prefix: /pkg/testing/apache-2.0.49;"

Another example:

gcc-2.9.5: "2; target: sparc-unknown-linux-gnu;"
gcc-3.2.3: "3.2; target: i686-pc-linux-gnu;"
gcc-3.2.3: "3.2; target: powerpc-unknown-linux-gnu;"
gcc-3.3: "3.3;"

Obviously, those with exactly matching attributes are mutually exclusive.

* XBuild tagging.
F. Dhin expressed a need to be able to mark XBuilds as being part of a
certain distribution version.

This concept is analogous to branching in a version control system. A
branch selector will cause the version control system to return the
file, with the latest changes that belongs in that branch.

Example:

gcc-3.2.3 is in of the zynot-i386-linux-e1.0, zynot-i386-linux-c1.4,
and trunk branches.
gcc-3.3 is in of the zynot-i386-linux-e2.0, zynot-i386-linux-c2.0, and
trunk branches.
gcc-3.4 is in of the trunk branch.

Users will have a branch selector in their Xeta configurations. A user
with the branch selector set to zynot-i386-linux-e1.0 will only see
gcc-3.2.3, a user with a branch selector set to zynot-i386-linux-e2.0
will see only gcc-3.3, and a user with a branch selector set to trunk
will see gcc-3.2.3, gcc-3.3 and gcc-3.4.

Note that this mechanism does not replace the stability level system -
it merely complements it.

* Visualisations for level attributes in XBuilds

http://jupiter.zynot.org/~zllow/XBuilds/Visualisations.png

That diagram shows how to visualise the various level attributes of an
XBuild. It can be taken as a recommendation for how to visually
represent, in a GUI, something like 'Stability level: 30%, your
treshold is 75%'.

I also inadvertently created an abstract for an XBuild trust model.
The model is based on cryptographically signed votes for each XBuild.

* XBuild trust model.
Each XBuild is associated with a votes file. The votes file will
contain records, with these fields: key ID, vote, salt, cryptographic
signature for vote and salt, crytographic signature for XBuild.

A user-defined policy will then determine the trustability score of an
XBuild. This score goes in two directions: -infinity: trusted to be
bad, 0, not trusted to be good or bad, +infinity, trusted to be good.

Votes that don't validate (wrong signature) are ignored by default, a
user may choose to terminate with a fatal error instead.

The user defines a ruleset that gives each vote a certain score
modifier, based on criteria like:

Whose key was used to sign the vote.
Whether the vote indicates good or bad.
How many votes have qualified in this category.

An explanation of the report described in the picture.

First, the votes:

3 votes for good from core developers.
7 votes for good from developers.
1 vote for good from a trusted user.
13 votes for good from an unclassifed person.
1 vote for bad from an unclassified person.

The ruleset used to generate the score:
#1 +3 for a vote for good from a core developer.
#2 +2 for a vote for good from a developer, maximum +6 from this category.
#3 +2 for a vote for good from a trusted user, minimum +6 from this
category.
#4 +1 for a vote for good from an unclassified person, maximum 10% of
the total score.
#5 -1 for a vote for bad from an unclassified person.

Also, there are bonuses that can be awarded:
#6 +2 for >75% signed votes for good.
#7 +2 for >75% unsigned votes for good, from stats.zynot.org.

So, the raw score, before limits are applied:

#1 +9
#2 +14
#3 +2
#4 +13
#5 -1
#6 +2
#7 +2

After applying hard limits:

#1 +9
#2 +6
#3 +0
#4 (13)
#5 -1
#6 +2
#7 +2

Now, a quick walkthrough on how to compute soft limits. The
hard-limited scores are summed up, producing score h. The total limit
for soft limits is fraction s. Score h is then treated as (100% - s)
of the total score. If the prelimited score is greater than the
maximum, its value becomes the maximum.

So:

h = 18
s = 10%
#4/(18 + 10%) = 13/20 (85%)
85% > 10%, #4 = 10%.

Final scores:

#1 +9
#2 +6
#3 +0
#4 +2 (10%)
#5 -1
#6 +2
#7 +2

Various other decisions

* XML parser.
libxml2, from xmlsoft.org, of the GNOME Project, will be used, as it
has been shown to be the fastest XML parser, both using DOM and SAX,
as well as its own native interface.

libxml2 is a C library. A C++ wrapper is likely to cause some
slowdowns. XML documents should only be used at the input and output
stages.

* XBuild repository format.
XML XBuilds will be used as the transport language. Developers can
choose to either modify and write new XBuilds directly into a
database, or as XML files manually imported into the database.

Full logs will be posted to jupiter upon request.

- -- Low Zhen Lin.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQE/vJmfv+6a/MPcjnERAp4oAJ9oC3eapa4vaEaHCsGjdnE5o3/EugCdGLv0
jRTNxGG/MF6p+IIO7LtmRnc=
=hTnV
-----END PGP SIGNATURE-----