Hey all,
First of all, most of you should be on the mailing list, but I get the
suspicion that some of you are missing. I forwarded some information
about Pavel, our new GSoC student to the list, and it was surprisingly
quiet and bikeshed-painting discussion free. (Maybe that's a good
thing....). Anyways, these changes are important, so I'm spamming all
of you to make sure it gets to the right people.
Toshio and Luke, I included you two in on this for webdev reasons.
You might be interested.
Btw, the mailing list can be found at:
https://fedorahosted.org/mailman/listinfo/smolt-devel
So i've (poorly) implemented a change we should have had 4 months ago.
Namely, I've set up a script that will patch updates into the
database only if the updates havent't already been patched in. This
means a few new rules and concepts for us to work with.
1) We will have a new version numbering scheme. The Smolt program
will continue to use the major.minor.point.subpoint scheme as before.
The database will incorporate a similar major.minor.point numbering
scheme independent of the Smolt program. Every change to the database
will get a version number bump. Period. When you make a change to
the database, be sure to use git to tag your commit with a tag such as
'db1.3.0' or 'db12.40.2'. Ideally, I would like to see every
significant release receive a full major number bump. (Significant is
probably when Mike upgrades the server :P)
2) I lied. Actually, the naming scheme should be
major.minor.point.branch.description, ie db1.3.4.main.hal.version or
db2.34.2.somebranch.experimental.optimization . The regular
expression that parses the version number is:
r'db([0-9]*)\.([0-9]*)\.([0-9]*)\.(\w*)\.(.*)sql$'
3) You will conveniently notice the 'sql$' at the end of that regex.
That's because new changes will go into a file in /databases named
accordingly. Making changes is actually quite simple. Pick a new
revision number in sequence, create a file named after it, insert your
changes, and save. The script /smoon/update-database.py should be
able to figure out the rest. (I say should, because there are still a
few bugs.) On a side note, don't leave the file empty. SQLalchemy
will complain loudly and rudely.
4) To start development anew, first import the initial DDL file. I'm
not sure what we're going to name it, but I think I see a bikeshed
that needs painting. Then run update-database.py. Magic, wow!
5) To get a partially up to date database up to speed, do not import
the initiall DDL file. Just run update-database.py.
6) One more note, don't name the branch anything but 'main'. You will
notice in an article I will post below, that there is a question of
the best way to handle branching and merging. I still need to give
this thought. I included the 'branch' field into the infrastructure
because it is very difficult to fix. Since that table needs to be
present in the database before the script can run, we would need an
older version of update-database.py to upgrade to a newer version.
For the sake of argument, any changes to the table schema_changes ar
probably bad.
The inspiration for this scheme came from this article. Sometimes it
pays to keep up with the closed source development side of things ;).
(Coding Horror is actually a really fascinating blog.)
http://www.codinghorror.com/blog/archives/001050.html
Some notes to specific people.
Ricky, Toshio, Luke, I'm not sure how useful this is to the rest of
the Infrastructure team, but please feel free to pillage. I'm sure
this needs a few more eyes going over it.
Pavel, For your summer work, I want you to feel free to consider any
additions you want to make to the database, for example metadata
tables, or user added information. As per the GSoC stuff, you can
send me SQL code that will upgrade the database, and I will include it
into the main branch. Then, you should rebase your private branch on
top of the new main branch, using git. This way, your weekly patchset
will apply directly on top of our changes.
-Yaakov
PS, should I post this to some other fedora mailing list too?