Hey Dieter, On 03 Apr 12:35, Dieter Plaetinck wrote:

anyway, nice to see the process. some more finetuning and bugfixing and as soon as we have a functional version I want to put it live :) Do you still want to do everything on your own? Because we could try to find more people who are into django who could help you out, it would make your life easier and it might help us getting this out quicker.

I haven't completely read your list, but I will when I work on it again, I wasn't able this weekend since I was stuck working on my day job all weekend. I will try and work on it tomorrow (monday). You're the boss, so if you want go and find as many people as you want of course, I don't want to be in your way in any way. Having said that I really enjoy working on it and getting both your and Dan's feed back and there isn't a single part yet that I'd like to get rid of (as in, pass along to the next person). So I would enjoy continuing on my own, but of course collaboration with others can also be a lot of fun, so you decide what you think is best. Tom

* Rollback section -> let's remove the select button, it's a bit redundant. Instead you can put the text "If you did a rollback followed by a new attempt to setup your blockdevices/filesystems, select which option you took here" * make it more clear users should fill in the "rollback modules" section only if they did a rollback. you can then also remove the (useless?) rollback part that has yes/no but no dates, on the main page. Did this, and placed some help text underneath the 2 rollback option

Hey guys, I thought I might send another status report. lists (rollback_filesystem and rollback_modules)

* "success" -> clearly tell users only to flag this if everything worked fine, and they can fill in comments if anything specific failed. Added some help text to it, hope that's ok.

* "modules" -> let's also add ext, swap, xfs, jfs and reiserFS. Added these, though I used ext2, ext3, ext4, hope that's ok (and the other of course).

* the two modules checklists should come before success/comments. i.e. success/comments should be the last thing on the page. Also done.

* after i hit submit, i saw again the http://localhost:8000/isotests/ page, but everything was still "never failed" / "never succeeded". then i reloaded the page and saw the results of my input? either way, it would be useful to tell the user, after submitting "thanks, submission worked", or the same form again with the reasons why the submission failed (i believe they call this form validation [feedback]) I've never run into this, and I did try. But hopefully now it won't matter, when someone fills the form in completely they're redirected to a 'thanks' page and from there they can click go back to results or give more feedback.

* I didn't select any modules in the rollback modules part, but the mainpage shows successes for the same modules as the ones I flagged in the regular "modules" checklist. Yeah there is something going on here. I (apparently) forgot to include a function for getting the rollback modules and filesystems instead of the regular ones. Now I did, but I'm being plagued by the form not updating the values correctly. Since the Test class has 2 references to the Filesystem and Modules classes each it uses the related_name property to distinguish them, but using this in a form seems troublesome, when I click some options they don't get saved, I've been looking into this, but so far no luck except, maybe the problem is that I customize the rollback_filesystem and rollback_modules and it forgets to use its related_name this way, I don't know.

* add some links between all the pages. I know you said you would like it to be nicely themed and everything, and I think that's a good idea, but that shouldn't be a blocking factor, for all I care you can make the links as ugly as they can get [for now], as long as they work. Did this, and even though I didn't do anything to them I almost like the way they look.

* in the success/failed colums of /isotests/, if they are filled in (with an isoname) I want that isoname to be a link, so that when I click on it, I see a list of all feedbacks from users of this specific point. For example it would look like: I'm still working on this, I was thinking though, wouldn't you prefer the iso name to take you to a list of the results of that iso and the names of the properties to take you to a list of results for that property (as described below)?

Results for : image boot: optical

iso - nickname - success? 2011.03.23 - Dieterbe - Y 2011.03.13 - Tom - N (...)

I still need to get that wiki page up, need to read the style rules first, I'll do that tomorrow and I'll work on the points left as well. Tom

Hey Dieter, Yay finally, another update.

* clock : default -> maybe make this "unchanged" * filesystem: (check the installed system, incl fstab) <-- these instructions are valid for all entries under filesystem, not just "autoprepare" * Rollback section -> let's remove the select button, it's a bit redundant. Instead you can put the text "If you did a rollback followed by a new attempt to setup your blockdevices/filesystems, select which option you took here" * "success" -> clearly tell users only to flag this if everything worked fine, and they can fill in comments if anything specific failed. * "modules" -> let's also add ext, swap, xfs, jfs and reiserFS. * make it more clear users should fill in the "rollback modules" section only if they did a rollback. you can then also remove the (useless?) rollback part that has yes/no but no dates, on the main page. * the two modules checklists should come before success/comments. i.e. success/comments should be the last thing on the page.

* after i hit submit, i saw again the http://localhost:8000/isotests/ page, but everything was still "never failed" / "never succeeded". then i reloaded the page and saw the results of my input? either way, it would be useful to tell the user, after submitting "thanks, submission worked", or the same form again with the reasons why the submission failed (i believe they call this form validation [feedback]) * I didn't select any modules in the rollback modules part, but the mainpage shows successes for the same modules as the ones I flagged in the regular "modules" checklist. * add some links between all the pages. I know you said you would like it to be nicely themed and everything, and I think that's a good idea, but that shouldn't be a blocking factor, for all I care you can make the links as ugly as they can get [for now], as long as they work. * in the success/failed colums of /isotests/, if they are filled in (with an isoname) I want that isoname to be a link, so that when I click on it, I see a list of all feedbacks from users of this specific point. For example it would look like:

Results for : image boot: optical

iso - nickname - success? 2011.03.23 - Dieterbe - Y 2011.03.13 - Tom - N (...)

Everything on this list should now be done and checked in to gitorious. The database has to be re-generated of course. The main page now shows a link for releng-testbuild-feedback under community (didn't know where to put it really) and at the top of the results page there is a link 'Give feedback', at the top of the add page there is a link 'Go back to results' and at the top of the lists with failed/succeeded results and the thanks page there are both. Let me know if I've forgotten (to mention) anything. I did notice that, when trying out conkeror again, the results page may not show results immediately, but I don't get that in luakit, so I don't know if it's conkeror that's loading its own cached pages (only shows me after a refresh) or if it's luakit not loading anything cached. Oh yeah, also the lists show the property and value that has been selected, but not yet the name for the value, that's because I haven't figured out how to change a string into an object instance yet :) (or generate an object instance from a string, really) Tom

On Tue, Apr 19, 2011 at 2:51 AM, Dieter Plaetinck wrote:

On Tue, 19 Apr 2011 00:50:44 +0200 Tom Willemsen wrote:

...

Everything on this list should now be done and checked in to gitorious. The database has to be re-generated of course.

nice to hear, I'll try it out as soon as I have time. unfortunately, my free time has decreased a bit as of late. So I encourage anyone who is interested in releng stuff and/or knows his way around in python/django to have a good look at Toms app and try it out.

...

I did notice that, when trying out conkeror again, the results page may not show results immediately, but I don't get that in luakit, so I don't know if it's conkeror that's loading its own cached pages (only shows me after a refresh) or if it's luakit not loading anything cached.

weird. or maybe some kind of race condition, you do return the next page only when you're sure all the queries are committed, right? It's not something like this, Django doesn't let you shoot yourself in

Sorry I haven't had time to look at this yet. I will do so soon, hopefully. Tom, two things- I'd like all new parts to use South migrations, so if you could go ahead and generate the initial migration for this new app, that would be awesome. Take a look at the docs if you aren't sure what I'm talking about. Second thing is- wondering if you could rebase your work on the latest code. You branched quite a while ago and I'd prefer one line of clean code that applies nicely, as it is a lot easier to follow. Something like "git rebase master <mybranch>" should do the trick. It would also be great if you could use "git rebase -i" or any other tricks to squash fixup commits into the proper commit where that work originally belonged. My quick review since just pulled it down anyway: * rtf ? I like this even less than isotests as far as WTF naming; I had NO idea what that meant until I saw your commit. Why not just "releng"? * vim modeline on all files, like all existing files please. * import statements: I try to do the following, with a blank line between each, in this order: python, django, our app * http://releng.archlinux.org/isos/ needs to be in the config file- default in settings.py is fine, but it can't be hardcoded. * "class(foo): pass" doesn't fly with me, I don't care how compact it is. Just use the normal three lines so changing it later isn't a P in the A. the foot like that unless you really try hard. It is probably just due to some of the pages being cached in your browser, but without looking closer I'm not sure. -Dan

On Thu, 21 Apr 2011 09:57:37 +0200 Tom Willemsen wrote:

...

Second thing is- wondering if you could rebase your work on the latest code. You branched quite a while ago and I'd prefer one line of clean code that applies nicely, as it is a lot easier to follow. Something like "git rebase master <mybranch>" should do the trick. It would also be great if you could use "git rebase -i" or any other tricks to squash fixup commits into the proper commit where that work originally belonged.

I'll try, never used rebase before.

it's very cool stuff that allows you to clean your history nicely. there are some good tutorials on `git rebase -i`, but if it's your first time, i would suggest to make a backup first, it could get confusing if there are merge conflicts during the rebase.

...

* rtf ? I like this even less than isotests as far as WTF naming; I had NO idea what that meant until I saw your commit. Why not just "releng"?

Just "releng"? Seems too generic, this app only deals with a small part of releng, the "releng-testbuild-feedback". Wouldn't that be preferable?

I'ld say: "rtf" in the url (foo.bar/rtf/) and "Releng Testbuild Feedback" as title on the page. If/when we link to this app from other pages, we could use "releng testbuild feedback" for the links. Clear enough imho. Dieter

On Wed, Apr 27, 2011 at 3:54 PM, Tom Willemsen wrote:

Hey Guys,

On 20 Apr 20:32, Dan McGee wrote:

...

Second thing is- wondering if you could rebase your work on the latest code. You branched quite a while ago and I'd prefer one line of clean code that applies nicely, as it is a lot easier to follow. Something like "git rebase master <mybranch>" should do the trick. It would also be great if you could use "git rebase -i" or any other tricks to squash fixup commits into the proper commit where that work originally belonged.

Another one of git's nice features, it was interesting to work with "git rebase -i", I did have to "git push --force" afterwards, though, so I don't exactly know how that will affect repositories that have been cloned before I did that, but I imagine it will make a big mess of things.

It looks like you did a rebase which made it a straight line history, but didn't actually rebase it onto master. The common base is still f1e476373 (use gitk/qgit/git log -g/tig/etc. to see this), way back from February 1st. Given that your public repository master branch is still pointing at an old commit, I'm guessing you need to take just a few more steps. 1. Check in or git-stash all uncommitted changes to your branch. 2. git fetch origin (or whatever the remote name is for the main projects.archlinux.org remote) 3. git branch -f master origin/master (once again, use the right branch name, but I highly recommend making origin the upstream repository) 4. git rebase master testresults 5. git push -f <yourremote> testresults The force push has no ill effects for working branches unless other people are basing work off of it. force push is discouraged highly if you are a project maintainer on something like the master/maint branches, but forcing a push to a work branch is rarely frowned upon. -Dan

On Wed, Apr 27, 2011 at 5:17 PM, Tom Willemsen wrote:

...

It looks like you did a rebase which made it a straight line history, but didn't actually rebase it onto master. The common base is still f1e476373 (use gitk/qgit/git log -g/tig/etc. to see this), way back from February 1st. Given that your public repository master branch is still pointing at an old commit, I'm guessing you need to take just a few more steps.

I think I understand what you mean, but could you please explain how this could happen or why your steps fix this.

It likely happened because you did a rebase -i, but since your local master branch "pointer" hadn't kept up with the actual master branch, it wasn't based off the current master branch. Not sure how to explain it more other than what I said before- look at the visual and read 'man git-rebase' which is pretty extensive, and/or find some tutorials on what rebase is and how it works on the interwebs.

...

1. Check in or git-stash all uncommitted changes to your branch. 2. git fetch origin (or whatever the remote name is for the main projects.archlinux.org remote) 3. git branch -f master origin/master (once again, use the right branch name, but I highly recommend making origin the upstream repository)

Why do you recommend against this? This is where I think git hosting services confuse the original intent. Before one click forks, you would clone a project's repo which automatically sets up the origin remote and the remote tracking branch master. Just think about the definition of "origin"- unless you have commit access to a project, you will probably never be pushing to the origin, in a sense.

I've confused myself before this way, I'm so used to doing `git pull origin master` and `git push origin master` and everything origin master on my own projects that I barely think about what I'm doing most of the time (I know, this is terrible, but I've never really used git in a way that other people are involved as well so everything is almost always only origin) and just put origin master everywhere automatically. The first thing you should do is take a step back so you don't have to do "origin master" ever again. When I `git pull`, it pulls origin/master automatically into master. When I `git push`, it automatically pushes master to origin for me. This little bit in .git/config does that for me, but you can set it up, it looks like, by doing `git branch --set-upstream master origin/master`.

[branch "master"] remote = origin merge = refs/heads/master

I've pull from the wrong remotes and tried pushing to the wrong remotes this way a couple of times and got very confused when this failed. But then I'm a total newbie in using git when other people involved.

...

4. git rebase master testresults 5. git push -f <yourremote> testresults

I've taken these steps, please let me know if it went right (I don't actually know what I'm looking at with git log -g and gitk doesn't seem to work (can't find 'wish'). Looks totally right now. And optdepends are your friend:

$ pacman -Qi git ... Optional Deps : tk: gitk and git gui -Dan

It's live, here is the direct link: http://www.archlinux.org/releng/feedback/ Things I'm allowed to say after sinking significant time into this yesterday. * Never ever rename an application halfway through again and then commit significant change after. That make for a rebase/rework hell, as the name rtf was a total no-go in my mind. * I squashed a lot of stuff together, and reworked a lot of commits. * Follow the style, please- all of your html was different indentation than our existing templates (2 vs. 4 spaces). I redid all of this. * There was no prose anywhere. I added a bunch, patches welcome if it is wrong. * If you have duplicate code in a Django template, you are doing it wrong. I'm still not totally happy with what I came up with to fix this due to the rollback vs. non-rollback stuff, but see this, noting the add/delete count: http://projects.archlinux.org/archweb.git/commit/?id=1ff9c0fc5db1aab393eed57... * If I can fuzz generated URLs and get the webapp to throw a 500, that is no good- I get emails for all of those. You need to be a lot more careful in sanity checking those things and returning 404s in most cases. http://projects.archlinux.org/archweb.git/diff/isotests/views.py?id=1ff9c0fc... * You totally misunderstood my comments regarding use of "pass"- I didn't say don't use it, I said please don't do a one-line class. So I reverted all of that backout. I'm sure this will see some more work once we get actual results. -Dan

On Fri, Apr 29, 2011 at 9:55 AM, Dieter Plaetinck wrote:

On Fri, 29 Apr 2011 09:48:22 -0500 Dan McGee wrote:

...

It's live, here is the direct link: http://www.archlinux.org/releng/feedback/

Things I'm allowed to say after sinking significant time into this yesterday. (..) I'm sure this will see some more work once we get actual results.

-Dan

whoa. already live? i haven't even had the time to further test the functionality of the application, and to check to which extent my complains/suggestions/ideas were fixed/implemented. I'll try to do that today or during the next days. I wouldn't start inviting people to use the app just yet. (it gets cumbersome when there need to be schema changes or stuff like that, when there's already useful production data) No it doesn't, that is the whole point of South and schema/data migrations.

-Dan

On Sun, May 1, 2011 at 5:26 AM, Dieter Plaetinck wrote:

Dan, I saw you wrote a `releng: auto-deactivate old ISO names` commit. from what I understand, this means when adding a testresult, you can only select an iso version listed @ http://releng.archlinux.org/isos/ ; but all other versions are still in the database, their feedbacks are still stored, etc? that seems good behaviour, but just checking. Yes, exactly what happens.

-Dan

On Fri, Apr 29, 2011 at 1:27 PM, Tom Willemsen wrote:

On 29 Apr 09:48, Dan McGee wrote:

...

It's live, here is the direct link: http://www.archlinux.org/releng/feedback/

Things I'm allowed to say after sinking significant time into this yesterday. * Never ever rename an application halfway through again and then commit significant change after. That make for a rebase/rework hell, as the name rtf was a total no-go in my mind. * I squashed a lot of stuff together, and reworked a lot of commits. * Follow the style, please- all of your html was different indentation than our existing templates (2 vs. 4 spaces). I redid all of this. * There was no prose anywhere. I added a bunch, patches welcome if it is wrong. * If you have duplicate code in a Django template, you are doing it wrong. I'm still not totally happy with what I came up with to fix this due to the rollback vs. non-rollback stuff, but see this, noting the add/delete count: http://projects.archlinux.org/archweb.git/commit/?id=1ff9c0fc5db1aab393eed57... * If I can fuzz generated URLs and get the webapp to throw a 500, that is no good- I get emails for all of those. You need to be a lot more careful in sanity checking those things and returning 404s in most cases. http://projects.archlinux.org/archweb.git/diff/isotests/views.py?id=1ff9c0fc... * You totally misunderstood my comments regarding use of "pass"- I didn't say don't use it, I said please don't do a one-line class. So I reverted all of that backout.

I'm sure this will see some more work once we get actual results.

-Dan

Wow that's massive. I've read through the commits you made after mine, you seem to have fixed pretty much everything I thought I still needed to have a look at. I'm sorry I created so much extra work for you. Don't worry about it- if I was actually mad I would have let you do it. :) I just wanted to get it to a point where I was satisfied with merging it.

So what is expected of me now? Do I work from this and send patches and such for people's (Yours, Dieter's) requests? Do you want me to butt out? No, definitely stay involved. Work from the latest master and just submit patches to the releng list, or directly to me and I'll work at getting them incorporated as quickly as necessary.

-Dan

On Sat, 7 May 2011 15:09:58 +0200 Dieter Plaetinck wrote:

On Fri, 29 Apr 2011 20:27:04 +0200 Tom Willemsen wrote:

...

So what is expected of me now? Do I work from this and send patches and such for people's (Yours, Dieter's) requests? Do you want me to butt out?

I don't really know what to do with this.

For everything that bugs me, I file a ticket (under the Arch Linux project, with prefix "{archweb} releng:"), and I'm telling others to do the same. So it would be very helpful if you could keep an eye on the tickets appearing on: https://bugs.archlinux.org/index.php?string=releng (and maybe https://bugs.archlinux.org/index.php?string=archweb) and provide patches / pull requests to fix them.

once the biggest gripes are fixed, I will announce the app / new approach on the forums.

Dieter

Hey Tom, how is it going? Do you have time to look at these issues? They are all pretty small things, but I believe they are showstoppers before I announce the new service to the bigger public. * FS#24018 - {archweb} releng: not clear which helptext belongs to which option/checkbox list. https://bugs.archlinux.org/task/24018 * FS#24042 - {archweb} releng: make the clock options clearer https://bugs.archlinux.org/task/24042 * This one is probably for Dan, it's just a matter of choosing where to put a simple link. FS#24022 - {archweb} releng: there should be a way to administer feedback entries https://bugs.archlinux.org/task/24022 Dieter

On Sat, 14 May 2011 14:21:39 +0200 Tom Willemsen wrote:

Hey Dieter,

...

Hey Tom, how is it going?

All is good, though always busy. You?

...

Do you have time to look at these issues? They are all pretty small things, but I believe they are showstoppers before I announce the new service to the bigger public.

* FS#24018 - {archweb} releng: not clear which helptext belongs to which option/checkbox list. https://bugs.archlinux.org/task/24018

(..) I would go for the label option anyway because that (sorry if this sounds very wrong) seems like less work now and possibly also in the future.

it seems to me with a bit of css this can be easily fixed. the helptext even has a class 'helptext'.

If I could be pointed to or given an explanation how to create / send a patch the way you want them I'll happily do this, although it seems such a minor change that anyone could do it in a few seconds.

make a commit that fixes it, then run git format-patch -s then git send-email, fill in arch-releng@archlinux.org but first you'll need to configure git to use a mailer. you can use msmtp which is very simple to setup. plenty of tutorials.

...

* FS#24042 - {archweb} releng: make the clock options clearer https://bugs.archlinux.org/task/24042

This sounds like something that should be done in the admin console, or is this a request to also change this in the fixtures? If so I'd happily do this as well of course.

yes, the changes should be in the source code. the defaults aren't optimal.

...

* This one is probably for Dan, it's just a matter of choosing where to put a simple link. FS#24022 - {archweb} releng: there should be a way to administer feedback entries https://bugs.archlinux.org/task/24022

From the comments I read it seems like you may have already found what you're looking for? Or is it about the link from devel?

actually I'm just waiting for Dan to do it. I see two options for links, I can wait for him to answer which it should be, then I would submit a patch, run the risk I missed a detail and need to redo the patch thing, but since the change is so trivial he could just do it. Dieter

Pushed a bunch of stuff live just now, so look here for what went out: http://projects.archlinux.org/archweb.git/log/?h=release_2011-05-15 -Dan

Victory !!! http://projects.archlinux.org/archweb.git/commit/?id=7b2c16014837c0b134a7b90... On Mon, 16 May 2011 22:22:30 +0200 Dieter Plaetinck wrote:

On Sun, 15 May 2011 11:04:32 -0500 Dan McGee wrote:

...

Why on earth does the one person doing admin on this app even need a link for this? The admin is always at /admin/. We don't do this anywhere else, so I see no need to do it here...

IMHO it's good practice to make these things explicit. I always expect a web application to provide links for its subpages and sections, it's mostly intuitive reasoning but I'll try to explain some arguments.

Say I do not do any Arch stuff for a year, and I forget the admin is on /admin (or forget where any page is, for that matter), and then when I get back in business, I can just look at the menu / links section to see which pages exist and what I can do. [*]. I probably won't really forget after only a year, but I like the "luxury" of not _needing_ to remember (and hence needlessly occupy space in my memory) these things.

Also, say we add $new_dev to the releng group. If the link is on the page for $new_dev to see, he can clearly explore what he can do and will need little clarifications. If it's not, we will definitely forget to mention it, and a month later $new_dev will ask "hey, how do you change this or that? I have been looking around but can't find it", then we need to reply with a link to the admin section and a mention "do not forget this". then imagine what happens if 2 more people join the releng team.

or imagine what happens if somebody - without much django knowledge - clones the project and wants to run his own archweb instance, is he supposed to "just know"? I really don't get what's wrong with a simple link to the admin section.

[*] Similarly, I know you have a stats page somewhere with network traffic and such, but i always forget the url, and I don't think there is a link to it (or at least not one clearly visible). I think individual developers should not be expected to remember the url or bookmark the page, rather a link should be made from http://www.archlinux.org/devel/

Dieter