smolt-devel May 2008

smolt-devel@lists.fedorahosted.org

4 participants
3 discussions

running smoon with python 2.4
by Thomas Schmidt 04 Jun '08

04 Jun '08

Hi, I wrote a little patch that allows running the smoon server in a python 2.4 environment. Greetings -- Thomas Schmidt (tschmidt [at] suse.de) SUSE Linux Products GmbH :: Research & Development :: Tools "Don't Panic", Douglas Adams (1952 - 11.05.2001)

4 5

Some changes to Smolt infrastructure
by Yaakov Nemoy 21 May '08

21 May '08

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?

2 1

Fwd: Smolt GSoC: Planning Stage 1
by Yaakov Nemoy 16 May '08

16 May '08

I'm going to forward this to the Smolt development list, so they can comment. ---------- Forwarded message ---------- From: Pavel Khardikov <pavel.khardikov(a)gmail.com> Date: Thu, May 15, 2008 at 4:00 PM Subject: Re: Smolt GSoC: Planning Stage 1 To: Yaakov Nemoy <loupgaroublond(a)gmail.com> Hi Yaakov, If you don't mind, I would like to write about how I see the process work on the project this summer. I do not know how it will be correct but it would be easier for me to work that way. So It will be very important to know what do you think about this. 1 -- We'll choose AJAX components, JS libraries and widgets that will be used to presentation data on pages. 2 -- Then I will make sketches of all pages in a vector editor like the one that I showed you with my GSoC proposal. You'll look at them and say your opinion about them on the basis of which we'll continue to work on. At the design stage of the WebUI I must know exactly what AJAX components, JS libraries and widgets, I'll use, so that my sketches will be most similar to how web pages will look then. To build different types of schedules, I would like to use Flash Chart. If you are not against it. IMHO Flash allows to provide datum more convenient and clear to user. In addition, there is confidence that Flash sites will be properly displayed in all browsers and on different platforms. I think this is an important moment. There are a lot of videos (Flash Video) in the network, it's difficult to imagine a user without flash plug-in in his browser. I tried to look on site http://smolts.org with different browsers, namely: Safari 3.0.4 and opera 9.26 win32 - screens are in the attachment to the letter. As I understand all the libraries and components which I'll use must be open source? Or am I wrong? There are 2 version of Flash Chart that I liked: * http://teethgrinder.co.uk/open-flash-chart/ - open source * http://www.amcharts.com/ - commercial license I would like to hear what do you think about this? 3 -- After all the sketches are created I turn to creating templates of web pages (HTML + JS + CSS + Flash). The most important thing at this stage will be writing valid HTML + CSS code which will be equally and properly displayed in different browsers and on different platforms. Therefore, It would be very convenient and useful to have deployed locally Smoon server to have an opportunity, quickly and easily modify HTML and CSS code and view the results in different browsers and on different platforms. 4 -- I don't think that would need to change the structure or design of your database. My task is to make a pretty Web 2.0 Interface that is to create a new View (UI). That is, in my opinion amount of datum provided to the user will not change and will change only the format of their presentation. 5 -- At this stage I would fill html templates with necessary datum, make and build a tag cloud charts based on data from the database. At this stage I have learned the TurboGears, Genshi, SQLAlchemy, etc ... 6 -- When most of these tasks will be done I will make my server public via the Internet so you can look at the results and evaluate it. Then we can begin to add new features, documentation for users, etc ... After I run the server Smoon locally and get any part of the database from you I'll immediately begin to do this consistently. As my work, I will give you all my changes compared with the current version smoon. -- Best regards. Pavel Khardikov

1 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

smolt-devel May 2008