From ianb at colorstudy.com Wed Mar 1 21:22:54 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Wed, 1 Mar 2006 14:22:54 -0600 Subject: [Catalog-sig] Adding trove categories Message-ID: <5b79f7651a6dc1e604221be1f25a1eb0@colorstudy.com> We want to add Cheese Shop categories for frameworks, so people can register things. These are the ones we (Kevin and I) would like: Framework :: Paste Framework :: TurboGears Framework :: TurboGears :: Widgets Framework :: TruboGears :: Applications Topic :: Internet :: WWW/HTTP :: WSGI Topic :: Internet :: WWW/HTTP :: WSGI :: Application Topic :: Internet :: WWW/HTTP :: WSGI :: Server Topic :: Internet :: WWW/HTTP :: WSGI :: Middleware That's just the ones we want, and we have packages that could go in there right now. I'm not that happy about putting WSGI under Topic :: ..., but it's not really a "Framework" either. Though putting it under framework would be okay too. Also, I think a link to this should go in the sidebar: http://wiki.python.org/moin/CheeseShopDev Some process for asking for new categories should be described on that page. I think that process should be: Python frameworks with plugins or packages that target the framework can get their own category. The category should only be added *after* such packages exist. Complimentary packages can link to each other from their descriptions, they do not need a category to link them together; only when packages are provided by different people does a category need to be created. To ask for a category email catalog-sig at python.org. Also, if there's no response on catalog-sig, we should probably figure out a backup person who someone on the list can forward the request to. -- Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org From richardjones at optushome.com.au Thu Mar 2 06:59:16 2006 From: richardjones at optushome.com.au (Richard Jones) Date: Thu, 2 Mar 2006 16:59:16 +1100 Subject: [Catalog-sig] Adding trove categories In-Reply-To: <5b79f7651a6dc1e604221be1f25a1eb0@colorstudy.com> References: <5b79f7651a6dc1e604221be1f25a1eb0@colorstudy.com> Message-ID: <200603021659.17116.richardjones@optushome.com.au> On Thursday 02 March 2006 07:22, Ian Bicking wrote: > We want to add Cheese Shop categories for frameworks, so people can > register things. > > These are the ones we (Kevin and I) would like: > > Framework :: Paste > Framework :: TurboGears > Framework :: TurboGears :: Widgets > Framework :: TruboGears :: Applications > Topic :: Internet :: WWW/HTTP :: WSGI > Topic :: Internet :: WWW/HTTP :: WSGI :: Application > Topic :: Internet :: WWW/HTTP :: WSGI :: Server > Topic :: Internet :: WWW/HTTP :: WSGI :: Middleware Hurm. At the moment there's no top-level "Framework" grouping in the Trove stuff. I'm not sure what will happen if one is added. I (or someone else who possibly has more time) will need to test things out to make sure it won't fall about laughing. > That's just the ones we want, and we have packages that could go in > there right now. I'm not that happy about putting WSGI under Topic :: > ..., but it's not really a "Framework" either. Though putting it under > framework would be okay too. Er, I assume that means you'd prefer it to be under Topic, or do you not care. I'd prefer that you make the call, to be honest. Would "Topic :: Internet :: WWW/HTTP :: Framework :: ..." be too cubmersome? Currently under "WWW/HTTP" we have: Topic :: Internet :: WWW/HTTP :: Browsers Topic :: Internet :: WWW/HTTP :: Dynamic Content Topic :: Internet :: WWW/HTTP :: Dynamic Content :: CGI Tools/Libraries Topic :: Internet :: WWW/HTTP :: Dynamic Content :: Message Boards Topic :: Internet :: WWW/HTTP :: Dynamic Content :: News/Diary Topic :: Internet :: WWW/HTTP :: Dynamic Content :: Page Counters Topic :: Internet :: WWW/HTTP :: HTTP Servers Topic :: Internet :: WWW/HTTP :: Indexing/Search Topic :: Internet :: WWW/HTTP :: Site Management Topic :: Internet :: WWW/HTTP :: Site Management :: Link Checking Consider browsing - I'd think that people are more likely to go into the WWW/HTTP topic to discover web stuff than a separate top-level Framework grouping. Richard From ianb at colorstudy.com Thu Mar 2 21:54:23 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Thu, 2 Mar 2006 14:54:23 -0600 Subject: [Catalog-sig] Adding trove categories In-Reply-To: <200603021659.17116.richardjones@optushome.com.au> References: <5b79f7651a6dc1e604221be1f25a1eb0@colorstudy.com> <200603021659.17116.richardjones@optushome.com.au> Message-ID: On Mar 1, 2006, at 11:59 PM, Richard Jones wrote: > On Thursday 02 March 2006 07:22, Ian Bicking wrote: >> We want to add Cheese Shop categories for frameworks, so people can >> register things. >> >> These are the ones we (Kevin and I) would like: >> >> Framework :: Paste >> Framework :: TurboGears >> Framework :: TurboGears :: Widgets >> Framework :: TruboGears :: Applications >> Topic :: Internet :: WWW/HTTP :: WSGI >> Topic :: Internet :: WWW/HTTP :: WSGI :: Application >> Topic :: Internet :: WWW/HTTP :: WSGI :: Server >> Topic :: Internet :: WWW/HTTP :: WSGI :: Middleware > > Hurm. At the moment there's no top-level "Framework" grouping in the > Trove > stuff. I'm not sure what will happen if one is added. I (or someone > else who > possibly has more time) will need to test things out to make sure it > won't > fall about laughing. As I remember the trove categories were a pretty simple entry in the database, just a flat list of strings. > >> That's just the ones we want, and we have packages that could go in >> there right now. I'm not that happy about putting WSGI under Topic :: >> ..., but it's not really a "Framework" either. Though putting it >> under >> framework would be okay too. > > Er, I assume that means you'd prefer it to be under Topic, or do you > not care. > I'd prefer that you make the call, to be honest. > > Would "Topic :: Internet :: WWW/HTTP :: Framework :: ..." be too > cubmersome? Yes, that would be too cumbersome; we just happen to be web frameworks. Other frameworks might want a place in there too. "Framework" being a classifier for actually-interesting-to-Python-users categories ;) Right now the trove categories don't make much sense for Python projects; lots of cruft, little granularity around things we actually care about. And "Topic :: Internet :: WWW/HTTP" is a super-lame category anyway ;) It should be "Topic :: Web". But eh... really, the whole hierarchy and taxonomy of packages is stupid. Which is why I would just like a fairly flat list of "frameworks", which are Python projects for which there exist packages that extend or utilize the framework. > Currently under "WWW/HTTP" we have: > > Topic :: Internet :: WWW/HTTP :: Browsers > Topic :: Internet :: WWW/HTTP :: Dynamic Content > Topic :: Internet :: WWW/HTTP :: Dynamic Content :: CGI > Tools/Libraries > Topic :: Internet :: WWW/HTTP :: Dynamic Content :: Message Boards > Topic :: Internet :: WWW/HTTP :: Dynamic Content :: News/Diary > Topic :: Internet :: WWW/HTTP :: Dynamic Content :: Page Counters > Topic :: Internet :: WWW/HTTP :: HTTP Servers > Topic :: Internet :: WWW/HTTP :: Indexing/Search > Topic :: Internet :: WWW/HTTP :: Site Management > Topic :: Internet :: WWW/HTTP :: Site Management :: Link Checking > > Consider browsing - I'd think that people are more likely to go into > the > WWW/HTTP topic to discover web stuff than a separate top-level > Framework > grouping. The top-level framework group is actually something I expect projects will be linking directly into. So Paste will have a link to its category, TurboGears to its, and so on; the XMLRPC interface offering some additional opportunities. Or maybe with RSS extensions, e.g., putting a filtered aggregator on a website. Mostly I don't want projects to have to implement their own package indexes. If for no other reason than that it is a big waste of time for those projects when we already have an index. But projects need a way of providing a selective view of the index. -- Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org From pje at telecommunity.com Thu Mar 2 23:57:59 2006 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu, 02 Mar 2006 17:57:59 -0500 Subject: [Catalog-sig] Adding trove categories In-Reply-To: References: <200603021659.17116.richardjones@optushome.com.au> <5b79f7651a6dc1e604221be1f25a1eb0@colorstudy.com> <200603021659.17116.richardjones@optushome.com.au> Message-ID: <5.1.1.6.0.20060302175259.01df5428@mail.telecommunity.com> At 02:54 PM 3/2/2006 -0600, Ian Bicking wrote: >Right now the trove categories don't make much sense for Python >projects; lots of cruft, little granularity around things we actually >care about. > >And "Topic :: Internet :: WWW/HTTP" is a super-lame category anyway ;) >It should be "Topic :: Web". But eh... really, the whole hierarchy and >taxonomy of packages is stupid. +1. Flat is better than nested, and the current categories are insanely nested. 5 levels deep to get to the idea of "Message Boards"? Wow. That having been said, I'm sure the trove stuff was adopted for a very good reason, i.e., to avoid getting bogged down in taxonomy wars before there was even a working product. :) Now, however, that there are hundreds of projects already on a working system, it might be a good idea to see what categories are actually getting used, and consider collapsing them to a flatter hierarchy, or maybe even just tags. From richardjones at optushome.com.au Fri Mar 3 00:17:19 2006 From: richardjones at optushome.com.au (Richard Jones) Date: Fri, 3 Mar 2006 10:17:19 +1100 Subject: [Catalog-sig] Adding trove categories In-Reply-To: <5.1.1.6.0.20060302175259.01df5428@mail.telecommunity.com> References: <200603021659.17116.richardjones@optushome.com.au> <5.1.1.6.0.20060302175259.01df5428@mail.telecommunity.com> Message-ID: <200603031017.20162.richardjones@optushome.com.au> FYI, some revision ideas were rolled into this wiki page some time ago (mid 2004): http://wiki.python.org/moin/RevisedPyPiCategories Of course, that doesn't include Ian's recent "Framework" idea. I'm busy at the moment, so can't really devote brain space to this problem. Perhaps next week I will be able to. As always, I'm perfectly happy for someone else to take on the problem as their own :) Richard From richardjones at optushome.com.au Fri Mar 3 00:24:58 2006 From: richardjones at optushome.com.au (Richard Jones) Date: Fri, 3 Mar 2006 10:24:58 +1100 Subject: [Catalog-sig] Adding trove categories In-Reply-To: References: <200603021659.17116.richardjones@optushome.com.au> <5.1.1.6.0.20060302175259.01df5428@mail.telecommunity.com> Message-ID: <200603031024.58248.richardjones@optushome.com.au> On Friday 03 March 2006 10:14, you wrote: > I'd go +1 for (freeform) tags.. the tags people want to use to > describe their projects should shake out pretty quickly, and it > prevents us from ever having to request a new topic whenever someone > comes up with a new idea or web framework :) No, free-form fields should be somewhere else. Propose a "keywords" field if you like, but I believe the description field performs this job adequately. I work for a company that runs conferences. We have approximately 7,500 proposals in across 10 conferences. They're all humanities-related, but in slightly different fields. Regardless, we now have 25,000 unique "keywords" that have been supplied from our free-form keywords field. Not so useful. Richard From bob at redivi.com Fri Mar 3 00:14:13 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 2 Mar 2006 15:14:13 -0800 Subject: [Catalog-sig] Adding trove categories In-Reply-To: <5.1.1.6.0.20060302175259.01df5428@mail.telecommunity.com> References: <200603021659.17116.richardjones@optushome.com.au> <5b79f7651a6dc1e604221be1f25a1eb0@colorstudy.com> <200603021659.17116.richardjones@optushome.com.au> <5.1.1.6.0.20060302175259.01df5428@mail.telecommunity.com> Message-ID: On Mar 2, 2006, at 2:57 PM, Phillip J. Eby wrote: > At 02:54 PM 3/2/2006 -0600, Ian Bicking wrote: >> Right now the trove categories don't make much sense for Python >> projects; lots of cruft, little granularity around things we actually >> care about. >> >> And "Topic :: Internet :: WWW/HTTP" is a super-lame category >> anyway ;) >> It should be "Topic :: Web". But eh... really, the whole >> hierarchy and >> taxonomy of packages is stupid. > > +1. Flat is better than nested, and the current categories are > insanely > nested. 5 levels deep to get to the idea of "Message Boards"? Wow. > > That having been said, I'm sure the trove stuff was adopted for a > very good > reason, i.e., to avoid getting bogged down in taxonomy wars before > there > was even a working product. :) > > Now, however, that there are hundreds of projects already on a working > system, it might be a good idea to see what categories are actually > getting > used, and consider collapsing them to a flatter hierarchy, or maybe > even > just tags. I'd go +1 for (freeform) tags.. the tags people want to use to describe their projects should shake out pretty quickly, and it prevents us from ever having to request a new topic whenever someone comes up with a new idea or web framework :) -bob From bob at redivi.com Fri Mar 3 00:32:29 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 2 Mar 2006 15:32:29 -0800 Subject: [Catalog-sig] Adding trove categories In-Reply-To: <200603031024.58248.richardjones@optushome.com.au> References: <200603021659.17116.richardjones@optushome.com.au> <5.1.1.6.0.20060302175259.01df5428@mail.telecommunity.com> <200603031024.58248.richardjones@optushome.com.au> Message-ID: <8726C021-49E9-40BA-A97E-B3C9B6CC646F@redivi.com> On Mar 2, 2006, at 3:24 PM, Richard Jones wrote: > On Friday 03 March 2006 10:14, you wrote: >> I'd go +1 for (freeform) tags.. the tags people want to use to >> describe their projects should shake out pretty quickly, and it >> prevents us from ever having to request a new topic whenever someone >> comes up with a new idea or web framework :) > > No, free-form fields should be somewhere else. Propose a "keywords" > field if > you like, but I believe the description field performs this job > adequately. > > I work for a company that runs conferences. We have approximately > 7,500 > proposals in across 10 conferences. They're all humanities-related, > but in > slightly different fields. Regardless, we now have 25,000 unique > "keywords" > that have been supplied from our free-form keywords field. Not so > useful. So what? If you're browsing, only show the N most popular ones. -bob From ianb at colorstudy.com Fri Mar 3 23:38:41 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Fri, 03 Mar 2006 16:38:41 -0600 Subject: [Catalog-sig] Adding trove categories In-Reply-To: <200603031024.58248.richardjones@optushome.com.au> References: <200603021659.17116.richardjones@optushome.com.au> <5.1.1.6.0.20060302175259.01df5428@mail.telecommunity.com> <200603031024.58248.richardjones@optushome.com.au> Message-ID: <4408C571.7040500@colorstudy.com> Richard Jones wrote: > On Friday 03 March 2006 10:14, you wrote: > >>I'd go +1 for (freeform) tags.. the tags people want to use to >>describe their projects should shake out pretty quickly, and it >>prevents us from ever having to request a new topic whenever someone >>comes up with a new idea or web framework :) > > > No, free-form fields should be somewhere else. Propose a "keywords" field if > you like, but I believe the description field performs this job adequately. There is a keywords field. This would work okay if there was better abilities to query and browse that field. I don't remember how it is stored in the database. But anyway, assuming we are doing that, how should we open up participation? The lack of a representative database dump makes it hard for other people to work on it on their local machines. And of course Subversion access for some people. -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org From lac at strakt.com Sat Mar 4 16:47:13 2006 From: lac at strakt.com (Laura Creighton) Date: Sat, 04 Mar 2006 16:47:13 +0100 Subject: [Catalog-sig] Adding trove categories In-Reply-To: Message from Ian Bicking of "Thu, 02 Mar 2006 14:54:23 CST." References: <5b79f7651a6dc1e604221be1f25a1eb0@colorstudy.com> <200603021659.17116.richardjones@optushome.com.au> Message-ID: <200603041547.k24FlDgd011355@theraft.strakt.com> >> Topic :: Internet :: WWW/HTTP :: HTTP Servers >> Topic :: Internet :: WWW/HTTP :: Indexing/Search >> Topic :: Internet :: WWW/HTTP :: Site Management >> Topic :: Internet :: WWW/HTTP :: Site Management :: Link Checking If at all possible, you do not want a hierarchy. What you want is a way to attatch meta-data to the project and search for intersections of relevancies. So -- CAPS (our main product) is a framework. It is also a workflow system. You can connect it to the internet, but you do not have to. There is a WWW client if you want one, we have others that aren't webbish at all. The more versatile you are, the harder time you will have fitting into a pre-existing heirarchy. Which may be the whole reason you wrote the thing in the first place -- you judged the functionality of existing offerings inadequate precisely because they were limited by somebody's heirarchical expectations, and you refused to be boxed in. Laura From tim at pollenation.net Sat Mar 11 12:22:47 2006 From: tim at pollenation.net (Tim Parkin) Date: Sat, 11 Mar 2006 11:22:47 +0000 Subject: [Catalog-sig] feedback received from python.org trac Message-ID: <4412B307.1070309@pollenation.net> This was posted on the psf.pollenation.net trac.. Just forwarding on.. --------------------------------------------------- Password reset needs improvement for Cheese Shop. If a registered user changes or closes an email accounts, then that user cannot get into the package submission site ever again ever, unless he reregisters. But that is the problem. The user's previously submitted package will exist as is for ever and ever or until someone deletes it. The problem is : When entering a user name to reset the password an email is sent to the old email which is closed. The email is bounced, returned, living only until some automated system destroys it but never to be received by anyone. If a registered user enters his current email address (the new one), to reset the password, then the username is not recognized as a match to the username and the entry invalid. Either way the user is forced to re-register. However the user cannot resubmit the same package, nor can he access his previously registered package because his original registration belongs to a ghost. The managers of my webspace offer an option to submit a new email address after entering a login name and password. What an idea. Works for me. If you are wondering how I thought of this needed improvement, the answer is that this problem is happening to me right now. And, if someone ever decides to make such an improvement, I would appreciate an email sent to tech at inqvista.com it's in the inqVista package, listed on the Cheese Shop site. Also valid is inq1ltd at verizon.net. Otherwise my package will live forever as is. And, I will have to re-work, re-build, re-write, re-submit, redo, re-install, re-construct, re-compose, re-compile, re-name and re-register, just for starters. And, I hope not. Re-Regards, jim derose (inq1ltd at verizon.net) From martin at v.loewis.de Sat Mar 11 14:15:31 2006 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 11 Mar 2006 14:15:31 +0100 Subject: [Catalog-sig] feedback received from python.org trac In-Reply-To: <4412B307.1070309@pollenation.net> References: <4412B307.1070309@pollenation.net> Message-ID: <4412CD73.8010703@v.loewis.de> Dear Jim, I'm not sure I completely sure I understand your problem. > If a registered user enters his current email address (the new one), to > reset the password, then the username is not recognized as a match to > the username and the entry invalid. > > Either way the user is forced to re-register. If the user remembers the Cheeseshop password, he can just change the email address. Login to the page, go to "Your details", edit the field "Email address", and press "Update details". > The managers of my webspace offer an option to submit a new email > address after entering a login name and password. What an idea. Works > for me. Right: after entering a login name and password. The same works for Cheeseshop. > And, if someone ever decides to make such an improvement I still wonder what improvement you are looking for. Regards, Martin From ianb at colorstudy.com Sat Mar 11 22:09:08 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Sat, 11 Mar 2006 15:09:08 -0600 Subject: [Catalog-sig] feedback received from python.org trac In-Reply-To: <4412B307.1070309@pollenation.net> References: <4412B307.1070309@pollenation.net> Message-ID: <44133C74.3030800@colorstudy.com> Tim Parkin wrote: > This was posted on the psf.pollenation.net trac.. > > Just forwarding on.. > > --------------------------------------------------- > Password reset needs improvement for Cheese Shop. > > If a registered user changes or closes an email accounts, then that user > cannot get into the package submission site ever again ever, unless he > reregisters. But that is the problem. The user's previously submitted > package will exist as is for ever and ever or until someone deletes it. > > The problem is : When entering a user name to reset the password an > email is sent to the old email which is closed. The email is bounced, > returned, living only until some automated system destroys it but never > to be received by anyone. There's no way to resolve this. The only way is for the person to contact a human and figure it out. Or they can check ~/.pypirc, which has a plaintext password. Maybe there needs to be a contact form or something on the forgotten password page. -- Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org From martin at v.loewis.de Sun Mar 12 01:08:58 2006 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 12 Mar 2006 01:08:58 +0100 Subject: [Catalog-sig] feedback received from python.org trac In-Reply-To: <200603111401.13267.inq1ltd@verizon.net> References: <4412B307.1070309@pollenation.net> <4412CD73.8010703@v.loewis.de> <200603111401.13267.inq1ltd@verizon.net> Message-ID: <4413669A.6010503@v.loewis.de> jim_on_linux wrote: > The question is, Now what? What does this user > do? You gave your web provider (or somebody) as an example: what do they do if you have forgotten your password, *and* your email address has changed? There is no way to automatically verify that you are still the same person. If anybody could change anybody's password and email address, we would not need to use passwords in the first place. Ian Bicking points out that you can look into the file .pypirc, if you still have that, perhaps it has cached the password, in which case it would be stored as clear text. If you only ever interacted with the Cheeseshop with a web browser, then it won't have the password stored. In that case, you should follow the "Get Help" on the lower-left side of http://cheeseshop.python.org/pypi which brings you to http://sourceforge.net/tracker/?group_id=66150&atid=513504 and request a change of email address. State your real name, your account name, and your old and new email address. Regards, Martin From inq1ltd at verizon.net Sun Mar 12 22:31:24 2006 From: inq1ltd at verizon.net (jim_on_linux) Date: Sun, 12 Mar 2006 16:31:24 -0500 Subject: [Catalog-sig] feedback received from python.org trac In-Reply-To: <4412CD73.8010703@v.loewis.de> References: <4412B307.1070309@pollenation.net> <4412CD73.8010703@v.loewis.de> Message-ID: <0IW1007J09POJY80@vms046.mailsrvcs.net> Dear Martin, On Saturday 11 March 2006 08:15, Martin v. L?wis wrote: > Dear Jim, >............. >................ > I still wonder what improvement you are looking > for. If this type of event is a regular occurrence, then I suggest something like the following. When registering, I would require a third identifier in addition to name and password. The third identifier: Offer a pop-up menu with many choices. Instruct the user to pick at least four choices from this menu. But, pick only one that the user would, or could, easily answer. Then, In the case where someone may forget either password, login identifier, or have an email address change, then a click on the button, "Cannot login?" would call the following form: --------------------------------------------------------------- Enter the email address that you used when registering with this system: ................... Enter Your current email address: ............... Both email addresses above must be entered. Answer only two of the following questions. Enter login id: ............. Enter Password: ........................ (Below are questions that could have been picked from a menu of many by the user at registration, and only one of which would be answered or error.) My son's first car, make and year: ................... My mothers's maiden name , first and last name: ............. The city my mother was born in. My favorite movie: ................. My oldest sister's birthday, month and year: ............. The city my father was born in: ........... ------------------------------------------------------------ (And many others that could be suggested.) A valid email and login gets an email sent to user. A correct login ID and answered question is a valid login. And a valid password and answered question is a valid login. If the email addresses above don't match, then, no email is sent but the user can change the email after entering the system. In all cases the user can then change any of the parameters, with two of three identifiers, valid email, password or login, answered question. Keeping track of passwords can be a pain, but picking a third way of entering a system from one's life's experience (a little harder to forget than a password) may be a additional way to keep some of this stuff in order. Regards, jim From exarkun at divmod.com Sun Mar 12 22:36:43 2006 From: exarkun at divmod.com (Jean-Paul Calderone) Date: Sun, 12 Mar 2006 16:36:43 -0500 Subject: [Catalog-sig] feedback received from python.org trac In-Reply-To: <0IW1007J09POJY80@vms046.mailsrvcs.net> Message-ID: <20060312213643.6122.349544126.divmod.quotient.15584@ohm> On Sun, 12 Mar 2006 16:31:24 -0500, jim_on_linux wrote: >Dear Martin, > >On Saturday 11 March 2006 08:15, Martin v. L?wis >wrote: > >> Dear Jim, >>............. >>................ >> I still wonder what improvement you are looking >> for. > >If this type of event is a regular occurrence, >then I suggest something like the following. > > [snip - "Secret question" system description] > >Keeping track of passwords can be a pain, but >picking a third way of entering a system from >one's life's experience (a little harder to >forget than a password) may be a additional way >to keep some of this stuff in order. > I hate these systems. Did I provide real information because I was fed up with them and didn't care about security? Did I make up something and if I did did I write it down someplace? Which question did I provide an answer to? What do I do when I forget the answer to _this_ round of questions? If you can't remember your password, write it down. At least then you are limiting your exposure to people with physical access to your terminal, instead of opening yourself up to attacks from anyone who knows how to use google. Or better yet, just keep your email address in the system up to date. There are a slew of free email services which will give you an address that lasts practically forever: get one and use it. Jean-Paul From martin at v.loewis.de Sun Mar 12 23:07:23 2006 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 12 Mar 2006 23:07:23 +0100 Subject: [Catalog-sig] feedback received from python.org trac In-Reply-To: <0IW1007J09POJY80@vms046.mailsrvcs.net> References: <4412B307.1070309@pollenation.net> <4412CD73.8010703@v.loewis.de> <0IW1007J09POJY80@vms046.mailsrvcs.net> Message-ID: <44149B9B.4070400@v.loewis.de> jim_on_linux wrote: > If this type of event is a regular occurrence, > then I suggest something like the following. It's not a regular occurrence. Most users apparently found one or the other way to deal with such systems. For example, one could use the same password for a number of such systems, e.g. your favourite movie, or your mother's maiden name. Regards, Martin From inq1ltd at verizon.net Mon Mar 13 04:16:38 2006 From: inq1ltd at verizon.net (jim_on_linux) Date: Sun, 12 Mar 2006 22:16:38 -0500 Subject: [Catalog-sig] feedback received from python.org trac In-Reply-To: <44149B9B.4070400@v.loewis.de> References: <4412B307.1070309@pollenation.net> <0IW1007J09POJY80@vms046.mailsrvcs.net> <44149B9B.4070400@v.loewis.de> Message-ID: <200603122216.38232.inq1ltd@verizon.net> On Sunday 12 March 2006 17:07, Martin v. L?wis wrote: > It's not a regular occurrence. Most users > apparently found one or the other way to deal > with such systems. For example, one could use > the same password for a number of such systems, Dear Martin, If this is not a regular event I agree leave it alone. However I checked the .pypirc file and found that the user name and password that I am using is valid. And, after trying trying again a few minutes ago I'm still having the same problem. "Authentication Failed. Do you want to retry?" The problem is not that I forgot my user name or password. I will try your suggestion in the morning. http://cheeseshop.python.org/pypi http://sourceforge.net/tracker/?group_id=66150&atid=513504 Thanks, Jim From matt at thenashgroup.net Tue Mar 21 19:13:19 2006 From: matt at thenashgroup.net (Matt Carpenter) Date: Tue, 21 Mar 2006 10:13:19 -0800 Subject: [Catalog-sig] Satellite Imaging Engineer Opportunity in Southern California Message-ID: <20060321181029.FCOE17006.fed1rmmtao02.cox.net@Mat> My name is Matt Carpenter and I manage a recruiting company in San Diego California. One of my most impressive clients in Southern California is looking for a Satellite Systems Engineer. The position requires and advanced understanding of satellite imaging and a proven track record of innovation. The job highlights are below and my motivation is a 12 on a scale from 1-10! I was wondering if you might know any qualified candidates you could refer to me? Please contact me or have them contact me ASAP at matt at thenashgroup.net Or reply to my e-mail. Experience should include writing plans and test procedures for large-scale engineering systems incorporating requirement analysis and high level design documentation. 6-10 years experience in large development projects; or satellite ground station projects. Experience with satellite remote sensing or imaging systems development preferred. Proven experience using formal system engineering methodologies for requirements, analysis, design, integration and testing. University degree in Applied Sciences / Engineering or Computer Science. Generic/extensible programming techniques in Python or other dynamic languages. A working knowledge of GNU Command-line tools (sed, awk, xargs, grep, .. etc). Thanks in advance, Matt Carpenter The Nash Group 619.851.2614 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/catalog-sig/attachments/20060321/882bc43f/attachment.htm From dangoor at gmail.com Thu Mar 23 21:25:39 2006 From: dangoor at gmail.com (Kevin Dangoor) Date: Thu, 23 Mar 2006 15:25:39 -0500 Subject: [Catalog-sig] Adding trove categories In-Reply-To: <5b79f7651a6dc1e604221be1f25a1eb0@colorstudy.com> References: <5b79f7651a6dc1e604221be1f25a1eb0@colorstudy.com> Message-ID: <3f085ecd0603231225kd7225c6l3b4b308cb5c5a68e@mail.gmail.com> On 3/1/06, Ian Bicking wrote: > We want to add Cheese Shop categories for frameworks, so people can > register things. > > These are the ones we (Kevin and I) would like: > > Framework :: Paste > Framework :: TurboGears > Framework :: TurboGears :: Widgets > Framework :: TruboGears :: Applications > Topic :: Internet :: WWW/HTTP :: WSGI > Topic :: Internet :: WWW/HTTP :: WSGI :: Application > Topic :: Internet :: WWW/HTTP :: WSGI :: Server > Topic :: Internet :: WWW/HTTP :: WSGI :: Middleware Still no word on this. I've poked around and found the XML-RPC interface and how the query mechanism works. Maybe I'll resort to using keywords or something in the description to be able to find these. Kevin From ianb at colorstudy.com Thu Mar 23 22:29:32 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Thu, 23 Mar 2006 15:29:32 -0600 Subject: [Catalog-sig] Adding trove categories In-Reply-To: <3f085ecd0603231225kd7225c6l3b4b308cb5c5a68e@mail.gmail.com> References: <5b79f7651a6dc1e604221be1f25a1eb0@colorstudy.com> <3f085ecd0603231225kd7225c6l3b4b308cb5c5a68e@mail.gmail.com> Message-ID: <4423133C.4050009@colorstudy.com> Kevin Dangoor wrote: > On 3/1/06, Ian Bicking wrote: > >>We want to add Cheese Shop categories for frameworks, so people can >>register things. >> >>These are the ones we (Kevin and I) would like: >> >>Framework :: Paste >>Framework :: TurboGears >>Framework :: TurboGears :: Widgets >>Framework :: TruboGears :: Applications >>Topic :: Internet :: WWW/HTTP :: WSGI >>Topic :: Internet :: WWW/HTTP :: WSGI :: Application >>Topic :: Internet :: WWW/HTTP :: WSGI :: Server >>Topic :: Internet :: WWW/HTTP :: WSGI :: Middleware > > > Still no word on this. I've poked around and found the XML-RPC > interface and how the query mechanism works. Maybe I'll resort to > using keywords or something in the description to be able to find > these. I actually think this is a good idea anyway. Keywords are freetext and people can come up with their own taxonomies fairly freely. E.g., turbogears+toolbox (all toolbox things), or turbogears+toolbox+sqlobject (all toolbox things that use SQLObject), or toolbox (any framework's toolbox?) It would also be nice if you could do http://cheeseshop.python.org/pypi/tags/turbogears+toolbox and get a listing, del.icio.us-style, but that can be implemented over XML-RPC for now. The XML-RPC interface could use some additions too... which really brings us back to the question of developer access to the codebase, or more specifically to a representative data set for use in testing? -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org From dangoor at gmail.com Thu Mar 23 22:36:39 2006 From: dangoor at gmail.com (Kevin Dangoor) Date: Thu, 23 Mar 2006 16:36:39 -0500 Subject: [Catalog-sig] Adding trove categories In-Reply-To: <4423133C.4050009@colorstudy.com> References: <5b79f7651a6dc1e604221be1f25a1eb0@colorstudy.com> <3f085ecd0603231225kd7225c6l3b4b308cb5c5a68e@mail.gmail.com> <4423133C.4050009@colorstudy.com> Message-ID: <3f085ecd0603231336t6b297630l8b26ff930f315c24@mail.gmail.com> On 3/23/06, Ian Bicking wrote: > It would also be nice if you could do > http://cheeseshop.python.org/pypi/tags/turbogears+toolbox and get a > listing, del.icio.us-style, but that can be implemented over XML-RPC for > now. The XML-RPC interface could use some additions too... which really > brings us back to the question of developer access to the codebase, or > more specifically to a representative data set for use in testing? Even beyond just testing, it would be nice to be able to put a little more information up at TurboGears.org without having to run individual queries for the relevant packages. At least the XML-RPC interface that's there now gives me a good start though. Kevin