Re: [arch-releng] Iso tests
I fetched Tom's latest testresults branch, followed all instructions in the
README - all steps executed fine with the exception of
https://bugs.archlinux.org/task/23228 -, But when I go to
http://127.0.0.1:8000/isotests/
I get:
DatabaseError at /isotests/
no such column: isotests_test.architecture_id
Request Method: GET
Request URL: http://127.0.0.1:8000/isotests/
Django Version: 1.2.4
Exception Type: DatabaseError
Exception Value:
no such column: isotests_test.architecture_id
here's some more output from during the setup part:
(archweb-env)17:54:44 dieter@ws archweb testresults ? diff local_settings.py.example local_settings.py
4c4
< DEBUG = False
---
> DEBUG = True
12,13c12,13
< #DATABASE_ENGINE = 'sqlite3'
< #DATABASE_NAME = 'archweb.db'
---
> DATABASE_ENGINE = 'sqlite3'
> DATABASE_NAME = 'archweb.db'
24c24
< CACHE_BACKEND = 'memcached://127.0.0.1:11211'
---
> #CACHE_BACKEND = 'memcached://127.0.0.1:11211'
(archweb-env)17:54:47 dieter@ws archweb testresults ? ./manage.py syncdb 1 ↵
Syncing...
Creating table isotests_hardwaretype
The following content types are stale and need to be deleted:
isotests | hardware
Any objects related to these content types by a foreign key will also
be deleted. Are you sure you want to delete these content types?
If you're unsure, answer 'no'.
Type 'yes' to continue, or 'no' to cancel: yes
No fixtures found.
Synced:
> django.contrib.auth
> django.contrib.contenttypes
> django.contrib.messages
> django.contrib.sessions
> django.contrib.sites
> django.contrib.sitemaps
> django.contrib.admin
> django.contrib.markup
> devel
> public
> south
> isotests
Not synced (use migrations):
- main
- mirrors
- news
- packages
(use ./manage.py migrate to migrate these)
(archweb-env)17:55:09 dieter@ws archweb testresults ? ./manage.py migrate
Running migrations for main:
- Migrating forwards to 0042_auto__del_field_packagefile_path.
> packages:0004_auto__add_license
> packages:0005_move_license_data
> main:0038_add_depends_optional_description
> main:0039_auto__del_field_package_license
> main:0040_split_package_files
> main:0041_move_package_files_data
> main:0042_auto__del_field_packagefile_path
- Loading initial data for main.
No fixtures found.
Running migrations for mirrors:
- Nothing to migrate.
- Loading initial data for mirrors.
No fixtures found.
Running migrations for news:
- Nothing to migrate.
- Loading initial data for news.
No fixtures found.
Running migrations for packages:
- Nothing to migrate.
- Loading initial data for packages.
No fixtures found.
(archweb-env)17:55:23 dieter@ws archweb testresults ? ./manage.py loaddata main/fixtures/arches.json
Installing json fixture 'main/fixtures/arches' from absolute path.
Installed 3 object(s) from 1 fixture(s)
(archweb-env)17:55:29 dieter@ws archweb testresults ? ./manage.py loaddata main/fixtures/repos.json
Installing json fixture 'main/fixtures/repos' from absolute path.
Installed 7 object(s) from 1 fixture(s)
(archweb-env)17:55:34 dieter@ws archweb testresults ? ./manage.py loaddata main/fixtures/groups.json
Installing json fixture 'main/fixtures/groups' from absolute path.
Problem installing fixture 'main/fixtures/groups.json': Traceback (most recent call last):
File "/home/dieter/workspaces/eclipse/archweb-env/lib/python2.7/site-packages/django/core/management/commands/loaddata.py", line 169, in handle
for obj in objects:
File "/home/dieter/workspaces/eclipse/archweb-env/lib/python2.7/site-packages/django/core/serializers/json.py", line 38, in Deserializer
for obj in PythonDeserializer(simplejson.load(stream), **options):
File "/home/dieter/workspaces/eclipse/archweb-env/lib/python2.7/site-packages/django/core/serializers/python.py", line 105, in Deserializer
m2m_data[field.name] = [m2m_convert(pk) for pk in field_value]
File "/home/dieter/workspaces/eclipse/archweb-env/lib/python2.7/site-packages/django/core/serializers/python.py", line 100, in m2m_convert
return field.rel.to._default_manager.db_manager(db).get_by_natural_key(*value).pk
File "/home/dieter/workspaces/eclipse/archweb-env/lib/python2.7/site-packages/django/contrib/auth/models.py", line 50, in get_by_natural_key
content_type=ContentType.objects.get_by_natural_key(app_label, model)
File "/home/dieter/workspaces/eclipse/archweb-env/lib/python2.7/site-packages/django/contrib/contenttypes/models.py", line 15, in get_by_natural_key
ct = self.get(app_label=app_label, model=model)
File "/home/dieter/workspaces/eclipse/archweb-env/lib/python2.7/site-packages/django/db/models/manager.py", line 132, in get
return self.get_query_set().get(*args, **kwargs)
File "/home/dieter/workspaces/eclipse/archweb-env/lib/python2.7/site-packages/django/db/models/query.py", line 347, in get
% self.model._meta.object_name)
DoesNotExist: ContentType matching query does not exist.
(archweb-env)17:55:39 dieter@ws archweb testresults ? ./manage.py loaddata mirrors/fixtures/mirrorprotocols.json
Installing json fixture 'mirrors/fixtures/mirrorprotocols' from absolute path.
Installed 3 object(s) from 1 fixture(s)
Hey Dieter, On 02 Apr 18:01, Dieter Plaetinck wrote:
I fetched Tom's latest testresults branch, followed all instructions in the README - all steps executed fine with the exception of https://bugs.archlinux.org/task/23228 -, But when I go to http://127.0.0.1:8000/isotests/ I get:
DatabaseError at /isotests/
no such column: isotests_test.architecture_id
Request Method: GET Request URL: http://127.0.0.1:8000/isotests/ Django Version: 1.2.4 Exception Type: DatabaseError Exception Value:
no such column: isotests_test.architecture_id This is probably one of the places where I changed the model, so you'd need to recreate the database or manually execute a bunch of SQL commands to change the database to what it was to what it is, I usually choose the first.
(archweb-env)17:54:47 dieter@ws archweb testresults ? ./manage.py syncdb 1 ↵ Syncing... Creating table isotests_hardwaretype The following content types are stale and need to be deleted:
isotests | hardware
Any objects related to these content types by a foreign key will also be deleted. Are you sure you want to delete these content types? If you're unsure, answer 'no'.
Type 'yes' to continue, or 'no' to cancel: yes No fixtures found. Probably another place where I changed it, Dan was complaining about my names, so I changed some of them, this makes django think I deleted one and created another.
(archweb-env)17:55:34 dieter@ws archweb testresults ? ./manage.py loaddata main/fixtures/groups.json Installing json fixture 'main/fixtures/groups' from absolute path. Problem installing fixture 'main/fixtures/groups.json': Traceback (most recent call last): File "/home/dieter/workspaces/eclipse/archweb-env/lib/python2.7/site-packages/django/core/management/commands/loaddata.py", line 169, in handle for obj in objects: File "/home/dieter/workspaces/eclipse/archweb-env/lib/python2.7/site-packages/django/core/serializers/json.py", line 38, in Deserializer for obj in PythonDeserializer(simplejson.load(stream), **options): File "/home/dieter/workspaces/eclipse/archweb-env/lib/python2.7/site-packages/django/core/serializers/python.py", line 105, in Deserializer m2m_data[field.name] = [m2m_convert(pk) for pk in field_value] File "/home/dieter/workspaces/eclipse/archweb-env/lib/python2.7/site-packages/django/core/serializers/python.py", line 100, in m2m_convert return field.rel.to._default_manager.db_manager(db).get_by_natural_key(*value).pk File "/home/dieter/workspaces/eclipse/archweb-env/lib/python2.7/site-packages/django/contrib/auth/models.py", line 50, in get_by_natural_key content_type=ContentType.objects.get_by_natural_key(app_label, model) File "/home/dieter/workspaces/eclipse/archweb-env/lib/python2.7/site-packages/django/contrib/contenttypes/models.py", line 15, in get_by_natural_key ct = self.get(app_label=app_label, model=model) File "/home/dieter/workspaces/eclipse/archweb-env/lib/python2.7/site-packages/django/db/models/manager.py", line 132, in get return self.get_query_set().get(*args, **kwargs) File "/home/dieter/workspaces/eclipse/archweb-env/lib/python2.7/site-packages/django/db/models/query.py", line 347, in get % self.model._meta.object_name) DoesNotExist: ContentType matching query does not exist. No idea what this does.
I'm still not great at reading django errors like that, but I did (which I forgot to mention, I'm very sorry) change some of the database related names and fields and such, so I think you should just delete your sqlite3 database. I just did and it works fine for me, here's what I did exactly: rm archweb.db # This is the sqlite3 database I used ./manage.py syncdb ./manage.py migrate ./manage.py loaddata isotests/fixtures/* ./manage.py sync_isos ./manage.py runserver And that works for me. Again, I'm very sorry that I didn't say I changed the database, I'm already so used to throwing away all my tables that I forget I do it. Hope it helps. Tom
Okay thanks, got it working with your instructions. More points: * 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 (...) 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. Dieter
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
Hey Dieter,
* clock : default -> maybe make this "unchanged" done.
* filesystem: (check the installed system, incl fstab) <-- these instructions are valid for all entries under filesystem, not just "autoprepare" Ok, I've put this instruction together with the filesystem title. (actually, right under it)
* "success" -> clearly tell users only to flag this if everything worked fine, and they can fill in comments if anything specific failed. I'll do that
* "modules" -> let's also add ext, swap, xfs, jfs and reiserFS. I'll add them to the fixtures, but in the future when it's live you can do this through the /admin/ pages (i.e. http://localhost:8000/admin/)
* 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. I'll remove it, and on the main page as well. Those 2 fields on the main page used to show the last success or fail names, but after I changed the database around they stopped doing this, I probably didn't update their specific logic.
* the two modules checklists should come before success/comments. i.e. success/comments should be the last thing on the page. Yeah I was thinking that too, I didn't get around to doing this yet, but I will.
* 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? that's strange, I haven't had this problem so far.
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]) Form validation is already graciously provided (up to a point) by django itself, if you hit submit without filling anything in it won't accept it. The succes page is indeed a nice touch, I'll add it.
* 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. strange, I'll look into this, maybe I made a typo.
* 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. You are absolutely right, I need to stop being stopped by such silly things.
* 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 (...) Very nice, I'll get on it!
Sorry I didn't reply before, I've worked on bits and pieces, but I didn't know what to send when. Expect to hear from me again very soon. 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
On Mon, 11 Apr 2011 01:30:52 +0200 Tom Willemsen <tom.willemsen@archlinux.us> wrote:
* 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.
Maybe it was a race condition. i.e. The loading of the root page came so quickly after the submission of the form, that the queries to insert the results were still executing while the page was requested? you should make sure you only show a new page after the queries are executed.
* 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.
I also don't know, but there are enough django experts out there ;)
* 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 think that would be fine too. My main concern is that the root page, even though it gives a good overview, only gives limited insight in the amount of feedback and amount of fails/successes for [specific features on ] specific isos. Both your and mine solutions fix this, but in a slightly different way, so it's fine by me. Dieter
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, 19 Apr 2011 00:50:44 +0200 Tom Willemsen <tom.willemsen@archlinux.us> 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? Dieter
On Tue, Apr 19, 2011 at 2:51 AM, Dieter Plaetinck <dieter@plaetinck.be> wrote:
On Tue, 19 Apr 2011 00:50:44 +0200 Tom Willemsen <tom.willemsen@archlinux.us> 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
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.
Very well, I'll start reading.
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.
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"?
Just "releng"? Seems too generic, this app only deals with a small part of releng, the "releng-testbuild-feedback". Wouldn't that be preferable?
* 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
No problem.
* http://releng.archlinux.org/isos/ needs to be in the config file- default in settings.py is fine, but it can't be hardcoded.
Of course, how could I forget.
* "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.
I thought you were going to say that. I'll get to these points tonight or otherwise this weekend. Tom
On Thu, 21 Apr 2011 09:57:37 +0200 Tom Willemsen <tom.willemsen@archlinux.us> 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
Hey Guys, On 20 Apr 20:32, Dan McGee wrote:
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.
Wow, I'd heard about south and noticed you were using it, but I had no idea what it did, awesome stuff...
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.
* 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.
All done. I've also, as you (Dan) asked, removed the sgmllib.SGMLParser and replaced it with HTMLParser.HTMLParser, way easier than I had expected it to be. Let me know what should be done next, please. Tom
On Wed, Apr 27, 2011 at 3:54 PM, Tom Willemsen <tom.willemsen@archlinux.us> 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
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.
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? 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. 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').
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.
Ah thanks, that's good to know. Tom
On Wed, Apr 27, 2011 at 5:17 PM, Tom Willemsen <tom.willemsen@archlinux.us> 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
On 27 Apr 17:39, Dan McGee wrote:
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.
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.
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
Looks totally right now. And optdepends are your friend:
$ pacman -Qi git ... Optional Deps : tk: gitk and git gui
Thanks for explaining, I've started using the git part where I can and I should've checked the optdepends, thanks for pointing that out.
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, 29 Apr 2011 09:48:22 -0500 Dan McGee <dpmcgee@gmail.com> 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) either way thanks Dan and Tom. Dieter
On Fri, Apr 29, 2011 at 9:55 AM, Dieter Plaetinck <dieter@plaetinck.be> wrote:
On Fri, 29 Apr 2011 09:48:22 -0500 Dan McGee <dpmcgee@gmail.com> 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
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. I still have some remarks, I made tickets for them so they are easier to follow up: FS#24018 - {archweb} releng: not clear which helptext belongs to which option/checkbox list. https://bugs.archlinux.org/task/24018 FS#24019 - {archweb} releng: filesystem module feedback does not show https://bugs.archlinux.org/task/24019 FS#24020 - {archweb} releng: results listing breaks with multiple submissions https://bugs.archlinux.org/task/24020 FS#24021 - {archweb} releng: no way to unselect rollback option https://bugs.archlinux.org/task/24021 Dieter
On Sun, May 1, 2011 at 5:26 AM, Dieter Plaetinck <dieter@plaetinck.be> 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 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. 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.
On Fri, Apr 29, 2011 at 1:27 PM, Tom Willemsen <tom.willemsen@archlinux.us> 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 Fri, 29 Apr 2011 20:27:04 +0200 Tom Willemsen <tom.willemsen@archlinux.us> 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
On Sat, 7 May 2011 15:09:58 +0200 Dieter Plaetinck <dieter@plaetinck.be> wrote:
On Fri, 29 Apr 2011 20:27:04 +0200 Tom Willemsen <tom.willemsen@archlinux.us> 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
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 understand this problem well, it bugged me when I was writing that page too. I've found at least 2 possibilities: * Rewrite the form layout by (for example) looping over all the fields in the template, instead of using form.as_p(). * Use the label property instead of the help_text property. I haven't found a way to just specify where the help_text should be. The first option seems like a lot more work than should be necessary and possibly more likely to require change in the future. On the other hand I also think that the 2nd option is less than ideal because even though the text does seem like a good label for me, it's also inconsistent to only have an explanation (and no normal label) for certain fields, and adding the field's label manually would require you to change this property as well, although you probably need to do that anyway since you'll have changed the name and need to change it in the form as well. As you may notice, I'm not very good at making decisions... 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. 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.
* 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.
* 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?
On Sat, 14 May 2011 14:21:39 +0200 Tom Willemsen <tom.willemsen@archlinux.us> 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
On Sun, May 15, 2011 at 5:00 AM, Dieter Plaetinck <dieter@plaetinck.be> wrote:
On Sat, 14 May 2011 14:21:39 +0200 Tom Willemsen <tom.willemsen@archlinux.us> wrote:
* 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.
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... -Dan
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
On Sun, 15 May 2011 11:04:32 -0500 Dan McGee <dpmcgee@gmail.com> 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
Victory !!! http://projects.archlinux.org/archweb.git/commit/?id=7b2c16014837c0b134a7b90... On Mon, 16 May 2011 22:22:30 +0200 Dieter Plaetinck <dieter@plaetinck.be> wrote:
On Sun, 15 May 2011 11:04:32 -0500 Dan McGee <dpmcgee@gmail.com> 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
participants (3)
-
Dan McGee
-
Dieter Plaetinck
-
Tom Willemsen