[12:01] :) [12:01] hey, what's this: Failed to fetch http://de.archive.ubuntu.com/ubuntu/dists/breezy/main/binary-amd64/Packages.gz MD5Sum mismatch [12:01] Failed to fetch http://de.archive.ubuntu.com/ubuntu/dists/breezy/universe/binary-amd64/Packages.gz MD5Sum mismatch [12:01] broken mirror? [12:02] run again [12:02] maybe it's syncing === Mez [~mez@82-36-228-130.cable.ubr01.perr.blueyonder.co.uk] has joined #ubuntu-motu [12:02] ivoks: eh [12:02] ivoks: wouldnt it update Packages.gz last? [12:02] hm. perhaps.. [12:02] to avoid that [12:02] or at least, that would make sense [12:03] oh nevermind [12:03] that was packages.gz :P [12:03] tseng: that depends on the mirroring software. debmirror does this. rsync not [12:03] read: plain rsync not [12:03] yes [12:05] doh.. [12:05] ivoks.blog.hr isn't working :( [12:06] whiprush on puc!!!!!!!ONE [12:07] siretart: https://bob.kdz13.net/test.txt is the backend code to that page [12:07] siretart: the rest you can see in view source, its < 100 lines i think [12:07] lol tseng: [12:07] Developers: Microsoft to Release AJAX Framework [12:08] thats such bollocks, i dont need a "framework" [12:08] look at how simple this code is [12:08] i guess its for all their wussie VB hackers [12:08] tseng: also available for pyhton? ;) [12:08] victoria bitter ? [12:09] ogra: :) [12:09] hrhr [12:09] ;) [12:09] siretart: it doesnt matter [12:09] siretart: i did it in php [12:09] siretart: look at the code [12:09] the javascript just does a GET on your backend page [12:09] and returns the results [12:09] it can be any page really [12:09] time to leave you guys... [12:09] till tomorrow [12:09] bye ivoks === siretart also urgently needs sleep. [12:10] gn8 folks! [12:10] siretart: i cant think of anything cool to do with REVU and ajax. [12:10] or, at least cool *and* useful [12:10] in my app at work i sort things by column if you click on the header [12:10] but we have not much stuff [12:11] I'll think about it. gn8 [12:11] I'm going to bed as well... bye together [12:11] bye [12:11] siretart: hey one second [12:11] ja? [12:11] why do you say "together" [12:11] er, sistpoty [12:11] siretart: sleep :) [12:11] I had a thought regarding revu [12:11] ah. ok - on my way:) [12:11] Burgundavia: tell me [12:12] weird... maybe i'm too tired too write good english [12:12] is it useful to have seperate tables for things that received no reviews and things we have received only positive reviews? [12:12] no? [12:12] that was really sick "german english" [12:12] ie, something that has just been uploaded and not been looked by anyone [12:12] they could be sorted that way [12:12] or colored [12:12] is it useful? [12:12] they are already colored [12:13] its useful to quickly see [12:13] i dont see why it makes a difference if you split the table [12:13] because I was thinking about the UI [12:13] current my design was 4 tables [12:13] 1 for unreview/only positive reviews and 1 for downchecks, with one of each for both new and updated packages [12:14] the order would be: [12:14] new packages: Un [12:14] and Prob === sistpoty [~stefan@DSL01.212.114.239.158.NEFkom.net] has left #ubuntu-motu [] [12:14] and then Changed [12:14] un and prob [12:14] prob? [12:14] problems [12:15] morning all [12:15] hi ajmitch [12:15] Burgundavia: hang on [12:15] what if it was views [12:15] not all on the page at once, but possible [12:15] the main page has just the first table that we see now [12:15] but with links across the top to adjust the query [12:15] in the ways you just specified [12:15] it would redraw the table acordingly [12:16] the "current" current uploaders would be divided into 4 tables [12:16] no, it wouldnt [12:16] think about it this way [12:16] its one table [12:16] in the database [12:16] yes [12:16] right now we view the entire thing as is [12:16] which is "correct" [12:16] you want custom views on it [12:17] true [12:17] which we can do in real time [12:17] ok [12:17] would that suit? [12:17] id love to start hacking on that [12:17] let me draw you a mockup of what I imagined [12:17] ok [12:17] but i think it makes the page too heavy [12:17] ill draw mine too [12:17] and we can compromise [12:17] :D [12:17] so what do the different colours in revu mean now? [12:18] ajmitch: its based on review/no reviw it looks like [12:18] ajmitch, its written above [12:18] ah, NEW vs changes [12:18] ogra: that's assuming I read it :) [12:18] :) [12:19] herve was asking about a list of packages to merge? [12:19] I've got a list that I can generate daily here if you want [12:20] http://img129.echo.cx/my.php?image=revumockup4yx.png [12:21] ok [12:21] do you have an issue with new/updated being reflected by color or sort order in the same table? [12:21] not really [12:22] I was actually designing icons for new and updated [12:22] up arrow for new [12:22] here's what I am thinking [12:22] and circle for updated [12:22] New [12:22] Needs Work [12:22] Ready for Upload [12:22] 3 views [12:22] ok [12:22] all on the main page [12:22] yes [12:22] live updating with ajax [12:22] that works [12:22] not on the screen at once [12:23] the main page has everything listed [12:23] and color coded [12:23] (i think) [12:23] who here has the database setup and is still awake? [12:23] and wants to hack with me [12:24] and table should have the alternating colours [12:24] that makes it easy to read [12:24] yes [12:24] definately [12:24] all the way across, not like the current setup [12:24] Burgundavia: it should be sortable [12:24] by clicking column headers [12:24] yes [12:24] would that be 3 tables? [12:24] each sortable? [12:24] or one big? [12:24] well [12:24] do you understand what im saying? [12:25] there is on table on the page at a time [12:25] one table? [12:25] as you click links the table is replaced [12:25] by the view you want [12:25] it might be easier if you think of it as 4 html pages [12:25] so clicking on New hides Needs Work and Read? [12:25] yes [12:25] gotcha [12:25] it totally replaces the div with new content [12:26] i wish this was php/mysql :( [12:26] or id already be done [12:26] doing to do that with tabs? [12:26] yeah, its like tabs in a gtk app [12:26] ok [12:26] sortof [12:26] another thing [12:26] it will be regular hyperlinks [12:26] with javascript actions [12:27] would be nice if instead of email addys, you saw the this [12:27] the this? [12:27] Brandon Hale (tseng) [12:27] yep, sure [12:27] blah@blah.org [12:27] maybe leave off the email [12:27] but make the name a mailto link? [12:28] the table needs a bit of padding too [12:28] no [12:28] inside the td's [12:28] scratch that [12:28] its bugging me [12:28] and wth is actions [12:28] that should go away [12:28] and make comments and advocates clearer [12:28] well [12:29] advocates is dumb [12:29] there is + and - [12:29] I had another thought regarding how packages move through the system [12:29] right now i dont see a way to tell if there was a problem [12:29] if a package ends up in needs work, and new upload should move it back into new [12:29] you like? [12:29] SQL doesnt understand textual comments as positive or negative based on natural language :) [12:29] Burgundavia: no [12:29] hrm [12:29] sure [12:30] how will that work, programmatically [12:30] if there is an upload since the last comment? [12:30] date stamps [12:30] sure [12:30] if upload date stamp is newer than advocate downcheck datestamp [12:30] thats my other question [12:30] where is the downcheck [12:30] oh [12:31] advocating -> no [12:31] ? [12:31] yes [12:31] No and Yes should turn into an icon as well [12:31] can it be neutral? [12:31] just adding to the discussion? [12:31] that is a comment [12:31] i see [12:31] ok [12:31] No turns in X and Yes into a check [12:32] I also have an idea for the package page [12:32] across the top [12:32] Icon for if new/updated [12:32] package name, version # and uploader [12:32] and the the upper right, the current status [12:32] um [12:33] what if we make a comment when there is an upload [12:33] what do you mean? [12:33] i upload a package [12:33] it makes a comment on my page automatically [12:33] new package uploaded $datastamp [12:34] with the changelog even [12:34] you can even add an icon if you are really into that [12:34] why clutter comments? [12:34] why add icons? [12:34] :) [12:34] comments should be about the package, not that there is a new version [12:35] i dont consider it clutter to notify of a new package as part of the thread [12:35] maybe a history section? [12:35] showing new uploads [12:35] we can just look at the changelog for that [12:35] no one should be making uploads w/o updating it [12:35] not a new upload [12:35] but a new upload to REVU [12:36] eh? [12:36] im thinking about breezy changes [12:36] every time i upload something, it posts the relevant bits from changelog [12:36] yes [12:36] its very useful [12:36] (imo) [12:36] I am talking about the packages fixes that happen on REVU before it even hits the archives [12:37] whats the difference [12:37] each of those "uploads" are the same version, no? [12:37] im thinking of this as like a bug tracker [12:37] for a private archive [12:37] ok [12:37] we are probably approaching this from different backgrounds :) [12:37] but the package version number is not going to change for say http://siretart.tauware.de/revu/details.py?upid=24 [12:38] when the uploader pushes the fixes, as it is has not yet hit the archive [12:38] hm i guess you got me [12:38] he doesnt update the revision in revu [12:38] its all 0ubuntu1 [12:38] yes [12:38] so REVU needs to track that [12:38] apt doesn't care [12:38] bwar [12:39] all we need is to know that the uploader has pushed a new version into REVU for reviewing [12:39] and the date stamp will give us that [12:39] we should not be printing: [12:39] tesseracttrainer_0.1.4-1_i386.changes1k [12:39] thats ass [12:39] it should just say changelog [12:39] and [12:40] hm [12:40] on packages that stuff is at the bottom, not the top [12:40] i guess it is the first class object in our case [12:40] im not sure we need the filesize on most of it either [12:40] at least not so prominately [12:40] yes [12:40] i wish i had dreamweaver or something [12:41] i could mock up faster than vim [12:41] (is anyone logging this?) [12:41] i talk very fast [12:41] why shouldn't the person who uploads to REVU change the version? [12:41] sure [12:41] irssi is loggin it all [12:41] ajmitch: because when we upload to breezy [12:41] I log as well [12:41] ajmitch: it shouldnt be 0ubuntu4 [12:41] why not? [12:41] there was no 1-2-3 in the archive [12:41] so? [12:41] it just.. we dont do that :) [12:42] we could start, I dont mind [12:42] i would love to have revisions and changelogs in between for revu [12:42] and [12:42] it doesn't look clean, but there's nothing stopping it from happening :) [12:42] that enforces good habits for the real tree [12:42] it would also mean that new changelog thing would not have to be developed for revu [12:42] well [12:42] when I was getting packages reviewed for debian I was asked to make changes & make the version -2 instead of -1 [12:43] it would be nice to diff changelogs [12:43] and show the most recent upload [12:43] i still like showing uploads in comments [12:43] so 0.6.4-2 would get uploaded to debian without 0.6.4-1 being in the archive [12:43] i see it like a thread on bugzilla [12:43] what about having an ajax thing for the changelog [12:43] "package foo uploaded fixes the bug, here is changelog" [12:43] Burgundavia: how do you mean? [12:44] show the changelog in the page, but not open, that opens when clicked on [12:44] that could be just plain JS [12:44] put the changelog in an invisible div [12:44] and toggle visibility [12:44] sure [12:44] but um [12:44] you can just click it atm like all the other related files [12:44] not sure its a big add [12:44] true [12:45] ok, on the package page itself [12:45] yep im there [12:45] we should seperate the linda/lintian stuff, the orig and the diff/dsc stuff into three distinct sections [12:45] yes [12:45] rows in a table [12:46] with a tiny row underneath each one with filesize in a small font [12:46] if we really need it [12:46] and date stamp them all [12:46] gah i need dreamweaver so bad [12:46] tried nvu? [12:46] no [12:46] is it in breezy? [12:46] yes [12:46] i need to mockup as im thinking [12:46] coding it would be too slow [12:46] the way its written.. i really dont like [12:47] it has templates [12:47] and code seperate [12:48] http://img127.echo.cx/my.php?image=revumockup25tg.png [12:48] that is my top bar idea for the package pag [12:48] e [12:49] thats good [12:49] but [12:49] whats the difference in icons [12:49] (and why icons) [12:49] icons are easy and clear [12:49] no thinking involved [12:50] should be New/Updated [12:50] showing whether or not the package is already in the archives [12:50] if its in the archive [12:50] we should drop it [12:50] i see no reason to maintain that data once 3 motus approve [12:50] I thought REVU was also for non-MOTU's to upload changes to existing packages? [12:50] is it? [12:50] yes [12:50] thats bollocks [12:51] unless you wanted a separate review process just for those? [12:51] i wouldnt want them on the same page? [12:51] why not? [12:51] since the only difference is whether they need 3 MOTU thumbs up [12:51] not to hurt anyones feelings, but i dont care if a 15 year old kid can run uupdate -u [12:51] what about people like me [12:51] part of the new package process is assessing a *persons* skills [12:52] to join motu [12:52] I plan on doing some work with existing packages [12:52] that's great, but we're talking about fixing bugs in packages, not just new upstream versions [12:52] those changes will need to be reviewed somwhere [12:52] I am not 15 year old kid [12:52] i guess they do [12:52] but its more of a once-off thing [12:52] revu is fine === tseng debitters [12:53] REVU will work great [12:53] like all the Cxx transition - we needed some way to review people's work [12:53] as this will mean that people like me don't have to go find webspace [12:53] that was the biggest thing that held me back [12:53] ah good point [12:53] yes, my debian sponsor didn;t like grabbing packages at 16K/sec from my box [12:54] getting source from mentors.debian.net was far more convenient for him [12:54] can we put that in a seperate page? [12:54] or something [12:54] i dunno [12:54] you said mark them with an icon [12:54] if they are NEW [12:54] especially as this will be hosted at a DC, with plenty of bandwidth [12:54] capitol NEW meaning not in the archive [12:55] ok so tell me one more time why we need Archived Uploads [12:55] hm i know [12:55] but lets make it another tab [12:56] I have no idea [12:56] i dog [12:56] do! [12:56] so someone can have 2 packages uploaded [12:56] when they are doing their 3rd [12:56] we can be like, hey, here are the other 2 [12:56] they look awesome [12:56] because the MOTUToReview pacge quickly filled up with out-of-date stuff [12:56] lets approve him to TB as a maintainer [12:56] so [12:56] now on the main page we have one table [12:57] everything that is not yet uploaded [12:57] then [12:57] archived uploads mainly applies to changes to existing packages, imho [12:57] we have links across the top, tabs if you will [12:57] New / Needs Work / Ready for Upload / Archived [12:57] sounds good [12:57] will adjust the query [12:57] and redraw the table [12:57] so we need 4 icons for the status [12:57] yes [12:58] ajmitch: thirded? [12:58]