=== e-jat is now known as e-jat_ === e-jat_ is now known as e-jat [21:19] jenda, are you there? [22:28] ping hubuntu [22:29] pong Flannel [22:29] got any updates on the DIY lP team? [22:30] I am currently talking with some people @ Canonical to see if we can get some hosting [22:30] hubuntu: we *dont* want canonical hosting [22:30] Canonical hosting is the most horrible thing in the world [22:30] why? [22:31] we donæt need no spectacular modules [22:31] we will go drupal, wonæt we? [22:31] Eh? Why would we go drupal? [22:31] Why would we use drupal? [22:32] why shouldn't we go drupal, when most part of the globel community uses that and knows it [22:32] But even if we were using drupal, we don't want canonical. [22:32] and we will need the kind of bandwidht Canonical has to offer [22:32] I do not understand why... [22:32] Canonical's hosting is a headache. People have waited *years* for simple changes [22:33] have you any experience with them yourself? [22:33] Well, bzr is python, so we'll need python at least. And the website itself will be a) static and then b) mostly simple layers over SQL queries [22:33] I really don't see any reason we'd need a full blown CMS [22:33] for the DIY site we don't, but think of the future [22:33] Not personally no, but I'm close with people who have [22:34] Whats in the future? [22:34] we will eventually find ourselves needing it [22:35] honestly I believe tight integration and cooperation with the LP team and Canonical is a must for this project... But I could be wrong [22:35] Oh, I also have a pretty good idea re: how to do the repository structure with data/metadata etc. Now that we've got that list, we can actually start with technical discussions [22:35] indeed [22:35] What do we need integration for? [22:35] openID for instance [22:35] we will be a testing site for the OpenID LP plugin [22:36] open ID doesn't require integration. Assuming we do all the commits via BZR, we just pass on the credentials, and don't need to verify them whatever on our own [22:36] I have at least talked to LP people interested in that [22:36] But even with launchpad integration, we *dont* want hosting with canonical if we want to have this working before the next LTS comes out [22:37] indeed, but It is good to help the devs make it easy for other to just load up the plugin and have it integrated to LP right away, right? [22:37] hubuntu: What? [22:37] the way I see it: We set this up *somewhere* and have a goal of having a pre-release mid august [22:38] by that time we will keep working at *somewhere* and start moving what we can to Canonical hosting. I can take care of that [22:38] once we see things are working we move the whole thing to Canonical, If we do not come there weæll find a solution [22:39] If you're dead set on canonical hosting, that's fine. I don't think it's necessary, and I don't think its wise. But that's just me. [22:39] Well, plus the added benefit of separation from canonical, but thats not technical [22:39] I can set up that *somwhere* right now [22:40] devubuntu provides hosting for projects like these, and already hosted the earlier prototype [22:40] I have a LAMP place, but I cannot overloaded it with bandwidth, so It should have to be restriucted to people in the team [22:40] they still do? [22:40] Thats what their website claims. I haven't actually looked into it though [22:40] http://www.devubuntu.com/ [22:41] shal i apply right now? [22:41] And actually, we could host there permanently too. [22:41] No use applying now as we don't have much/anything to put up [22:41] And if we decide on something else later, that'll just be rude to the devubuntu guys [22:41] given we don't eat up all their bandwidht... which I doubt will happen in the sort term [22:42] It's better to just have them as a mirror anyway [22:42] and if we set up a basic drupal and the other code we have, we could go from there [22:42] sorry my English is really bad tonight--- [22:43] Again, I don't think drupal is the way to go, since we'll spend more time hacking our code to work inside of drupal than actually writing it [22:44] In a nutshell, what Im going to propose is you have a metafile for each item (an item could be multiple files) and that file just points to the data files (which also works for multiple languages, etc). And then the webserver will keep its DB updated by examining the diffs of each commit (or batches of commits) [22:44] and that'll keep load down, we don't need to sync each time, just update the DB with the changes [22:44] Its nothing fancy, but the best schemes rarely are [22:45] you are thinking of using LP for the version tracking and translations right? [22:45] And I *think* (as far as its mapped in my head) we just need three tables. [22:45] not LP, bzr [22:45] hosted @ LP [22:45] or *somewhere* [22:46] Well, bzr isn't really "hosted" any particular place, but yes, using the LP repo [22:46] I know is a DVCS [22:46] okok,plese keep on [22:46] Well, that' more or less it ;) Its fairly straight forward. [22:47] We don't actually need the diffs themselves, just a listingof files/fields that were changed [22:47] I mean, we could if we wanted, but that'd be a lot of overhead for very little gain [22:48] I *think* it'd be better to have all the data stored in the DB itself (including files) although not the versioned stuff. Since LP does go down (or at least, gets bloody slow) and we can remain unaffected that way [22:49] "not the versioned stuff" means not old versions. Just a current checkout of the bzr branch, basically (in DB form) [22:49] current mirror, I suppose is a better way of phrasing i [22:49] t [22:50] I understood ;) [22:50] ok, you have a very good idea of this [22:50] and I think you should write the spec [22:50] can you do it on the wiki or can you give it to me so I can? [22:51] I was planning on doing a proper proposal/writeup thing and email it to the list. But I could put it on the wiki too, yeah. [22:51] yo may as well send an email to the list with your ideas, but let's try to keep the discussion wikified so we can *see* the whole thing in one,organized place [22:51] yeah, we do pretty much agree [22:51] :) [22:52] well, the mailing list does have an archive, and it allows you to see actual conversations, instead of just the final product [22:52] I will send an update. I am going to send the e-mail to Canonical with a copyu to the list and ask the devubuntu guys for hosting too [22:52] So, I'll do the mailing list, and then once we've all discussed (since I'm sure there are some things that could be tweaked/etc) we'll put it up on the wiki [22:53] I can do a Writeup after your e-mail in the wiki ad invite people to expone their ideas in either way they like ;) [22:54] the problem with using the wiki for a discussion is that not everyone sees the changes/etc. Let alone being a pull medium instead of a push medium [22:55] I know I'd never be able to keep up with a discussion on a wiki page, or at least, not except once or twice a day, because I can't always browse the web, but I can check my email all over the place. [22:58] But, however we end up doing it, I'm sure it'll work out [23:01] definitely. You can always subscribe to a wiki page, but it may generate a lot of e-mail at times [23:04] Yeah, but thats still not very condusive to a conversation. no threads, or anything like that (plus the locking issues, etc). Which is why I think defacto conversation medium in FOSS (if not everywhere) is email [23:04] Flannel, are you the one always talking about the SU site as a possible whatisubuntu site? [23:05] hubuntu: I think its important to include it, yes. Like the old diagram had it laid out. I'd like a "spreadubuntu" that's an "about" site, with a DIY site underneath (diy.spreadubuntu.com, for instance). [23:05] I agree with you Flannel. I just want people to realize that writing an e-mail is not always eneough. One has to make specs, blueprints and organize their thoughts ina way that is actually implementable [23:05] I think it will serve our purposes much better. [23:05] hubuntu: No, Of course not. But email is the proper place for conversation, with (semi)permanent things elsewhere. [23:05] can you please join me in #ubuntu-website to discuss that "about ubuntu" a little further? [23:05] There's a *lot* of people out there that still don't know what Ubuntu is all about [23:06] I know [23:06] hubuntu: The ubuntu-website project doesn't cover this. That's for ... well, all the official ubuntu websites. [23:06] I meet daily Linux people (like in RHEL4 users) that donæt know about Ubuntu [23:06] not to say windows/mac users [23:07] I'm not talking about Linux users, but people who really do need to be explained what Linux/etc is. [23:08] hubuntu: I know in one email (or I think it was you), you said that ubuntu.com should be that. But Ubuntu.com *cant* reach that level of specificity. AS it has to cater to *everyone*, includingdevelopers, community teams, etc. Has to provide development announcements, release notes, etc. [23:26] I just think before we go barging into putting it at "spreadubuntu.com" we should pause and think (which we've done) and put it at diy.spreadubuntu.com, because we see the bigger picture. [23:26] Definately main objective, although doesn't necessarily have to be first priority, since we don't have to work on just one project (since we have plenty of people able to write up text who probably would be less helpful in coding the diy site) [23:27] hooray for multitasking [23:28] and thats actually spot on with what we can do, people who can/want to code can work on the code/functionality, and then the people who like to write (and may not be able to code) can work on that [23:28] and people like me (who like to see code, but not writing it) can do whatever they find suitable [23:29] hubuntu: but yeah, I'll definately write all this up. But right now I think its time for lunch. [23:29] I am glad I finally caught you on though. Glad to discuss these things with you finally. [23:30] same here [23:30] I think Iæm gonna go for a smoke , write an email and get to sleep