I just committed the first bits to the new updates system. At the
moment it doesn't do much, but I defined an initial database model
(which will also help us see how to integrate this with the package db)
and a couple of controllers.
I also updated the UpdatesSystem wiki page with screenshots of the current system that is used to push out core package updates. Hopefully this will give people some context as to the direction this project is going in.
The code should be pretty well commented, especially in places that *need* code.
This project is going to become a top priority for me in about week, after
finals. I'll try and produce a list of tasks at some point in the near
future that people can just pick up and work on. But in the mean time,
if you would like to help out, I recommend reading over the wiki and
getting familiar with the current update process/system. From there,
checkout the code, `yum install TurboGears` and start playing around
Due to poor scheduling on my part, I will not be able to make any of the
meetings for the next 10 weeks. I just couldn't resist and had to sign
up for a class on Zen Buddhism at that time.
As far as things are going now, I've been doing much hackery on the new
UpdatesSystem, and should have a functional system shortly. Right
now I have a local tree of test builds which I am using to push out
to a test-stage. After I write up a bunch of nose tests for it, I'll
commit a package or so from the test tree as well.
I poked around at publictest2 last night, which doesn't seem to be
public at all. I also was not able to get any traffic out. If anyone
has a free second, could you take a look at this?
I received and installed a new 1950 from Dell...
What is the purpose of this machine going to be so that I can label it
= Stacy J. Brandenburg Red Hat Inc. =
= Manager, Network Operations sbranden(a)redhat.com =
= 919-754-4313 http://www.redhat.com =
On Tue, 2006-12-05 at 16:14 -0600, Jeffrey C. Ollie wrote:
> On Tue, 2006-12-05 at 12:35 -0800, Toshio Kuratomi wrote:
> > On Tue, 2006-12-05 at 13:43 -0600, Jeffrey C. Ollie wrote:
> > > On Tue, 2006-12-05 at 11:32 -0800, Toshio Kuratomi wrote:
> > > >
> > > > We could solve both concerns by having a foreign key constraint into a
> > > > table with the valid status phrases for each table that needs statuses
> > > > but that makes things more complex. This would allow us to select the
> > > > list of valid statuses from a database table which is a plus. But it
> > > > would also require a join for the common case of giving a human readable
> > > > name for the status. So I'd like to hear your justification.
> > >
> > > You could include localized versions of the status names in the database
> > > table rather than doing the localization in the front-end (of which
> > > there might be several).
> > Okay. What do you think about doing it like this:
> > create table StatusCode (
> > id serial primary key,
> > );
> > create table Translations (
> > statusCodeId integer references StatusCode(id),
> > language text not null default 'C',
> > statusName text not null,
> > primary key (statusCodeId, language)
> > );
> Yeah, that looks like what I had in mind, except that I would call the
> table "StatusCodeTranslations."
That would be fine.
> > create view CollectionStatusCode as select id from StatusCode where id = 1 or
> > id = 3 or id = 7;
> > create table Collection (
> > [...]
> > status integer references CollectionStatusCode(id)
> > );
> > Overengineered or good?
> Yeah, looks good to me.
> > (The view allows us to query which statuses are available for this
> > table. I don't know of a sane way to do that with a check constraint.)
> Why not make CollectionStatusCode a table like this:
> create table CollectionStatusCode (
> id integer primary key references StatusCode(id)
That should be fine. With a dataset as small as the possible status
codes I don't know that there would be much difference between the two