Re: [Launchpad-dev] timeline questions
And if get_current_browser_request always works, can we put it in get_request_timeline instead of typing it explicitly every time? So there are two disconnected steps: - get a request from some context - get the timeline from that request (which will use IAnnotations once bug 623199 is fixed) I'm not too keen on conflating these steps; we could certainly add a new helper get_current_browser_request_timeline() though, that would be fine. For scripts, consider adding this as an attribute on LaunchpadScript so everyone gets to play. -- Stuart Bishop stu...@stuartbishop.net http://www.stuartbishop.net/ ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] timeline questions
On Wed, Sep 29, 2010 at 8:19 PM, Stuart Bishop stuart.bis...@canonical.com wrote: And if get_current_browser_request always works, can we put it in get_request_timeline instead of typing it explicitly every time? So there are two disconnected steps: - get a request from some context - get the timeline from that request (which will use IAnnotations once bug 623199 is fixed) I'm not too keen on conflating these steps; we could certainly add a new helper get_current_browser_request_timeline() though, that would be fine. For scripts, consider adding this as an attribute on LaunchpadScript so everyone gets to play. hmm? scripts can use features already; fixing bug 623199 would make that be better structured, but theres no functional issue today. -Rob ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] timeline questions
On Wed, Sep 29, 2010 at 3:06 PM, Robert Collins robert.coll...@canonical.com wrote: On Wed, Sep 29, 2010 at 8:19 PM, Stuart Bishop stuart.bis...@canonical.com wrote: And if get_current_browser_request always works, can we put it in get_request_timeline instead of typing it explicitly every time? So there are two disconnected steps: - get a request from some context - get the timeline from that request (which will use IAnnotations once bug 623199 is fixed) I'm not too keen on conflating these steps; we could certainly add a new helper get_current_browser_request_timeline() though, that would be fine. For scripts, consider adding this as an attribute on LaunchpadScript so everyone gets to play. hmm? scripts can use features already; fixing bug 623199 would make that be better structured, but theres no functional issue today. I mean making LaunchpadScript.__init__() initialize self.timeline (or LaunchpadScript.timeline into a property) so it is trivial for scripts to use and easy to find, which makes it much more likely people will use it. Also only one piece of code to change if the setup dance changes. -- Stuart Bishop stu...@stuartbishop.net http://www.stuartbishop.net/ ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] timeline questions
On Wed, Sep 29, 2010 at 10:05 PM, Stuart Bishop stuart.bis...@canonical.com wrote: I mean making LaunchpadScript.__init__() initialize self.timeline (or LaunchpadScript.timeline into a property) so it is trivial for scripts to use and easy to find, which makes it much more likely people will use it. Also only one piece of code to change if the setup dance changes. Scripts already do set_request_started, which is all thats needed; I'm not sure why this additional thing would be needed. To work with security properly scripts need to be setting up participations, which should provide an IAnnotation participation long term, and thats where it would live at that point (and OOPSes would use that too, etc) -Rob ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] performance tuesday... tests
On 2010-09-29 06:02, Robert Collins wrote: Everyone else may know this already, but layers are a pretty poor interface, at least the way they are used in LP's test suite. Yay for revisiting our layers setup! If I may add a pet peeve of my own: the email stub. LaunchpadScriptLayer (and no lighter layer, for no other reason that I can see than the layers system) does this: provideUtility(TestMailBox(), IMailBox) ...after which email gets captured in a global variable. I'd love to see that become a fixture or resource that I can use in more fine-grained tests without setting up a full LaunchpadLayer. Jeroen ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] timeline questions
On Wed, Sep 29, 2010 at 4:31 PM, Robert Collins robert.coll...@canonical.com wrote: Scripts already do set_request_started, which is all thats needed; I'm not sure why this additional thing would be needed. Its not needed. Its convenient. self.timeline is much easier to remember than get_request_timeline(get_current_browser_request()), as well as avoiding the huh? factor on what get_current_browser_requests() means in the context of a command line tool. -- Stuart Bishop stu...@stuartbishop.net http://www.stuartbishop.net/ ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] performance tuesday... tests
On Wed, Sep 29, 2010 at 12:02 AM, Robert Collins robe...@robertcollins.net wrote: So I meant to look at +filebug timeouts yesterday but I got distracted into test infrastructure (because things were slow). I'm very glad you're looking into this. Let me know if there's something I can do to help. jml ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] How do we fix the Launchpad's login experience?
On Fri, Sep 24, 2010 at 5:45 AM, William Grant m...@williamgrant.id.au wrote: On Fri, 2010-09-24 at 00:38 -0400, Elliot Murphy wrote: I'm really glad to see this being discussed in detail. On Thu, Sep 23, 2010 at 7:18 PM, William Grant m...@williamgrant.id.au wrote: I think that login.launchpad.net needs to disappear. It is simply too confusing -- everyone has two independent sets of email addresses associated with Launchpad.net. It can't safely be destroyed now (forcing non-Ubuntu LP users to use an Ubuntu-branded SSO site would be foolish), but it seems reasonable to do it once LP becomes a general OpenID provider. This might be a dumb question, but why is it a problem if non-Ubuntu LP users see an Ubuntu-branded SSO site? Many projects are concerned that Launchpad is too tied to Ubuntu. Forcing them through an Ubuntu authentication gateway will probably not help with that. I don't disagree with you, but I haven't heard anything from these projects. I'd like to know more about their concerns, do you have anything that could help me follow this up? ... In summary: fix bug #637968, make LP a general RP, destroy login.launchpad.net. This sounds like a good summary, although I would like to understand why is making LP a general RP a necessary step? As above: we don't want to scare more people off LP. Forcing everyone through somewhere with heavy Ubuntu branding is going to scare more people off. Well, even separately from the branding issue, it's removing a step for people who already have openids. I'm not convinced that Ubuntu branding would scare people off. First, I don't think Ubuntu branding is that scary. Second, I think that a little bit of copy could significantly reduce the you are now Ubuntified aspect. I more readily believe that people will be put off simply by yet another password confirmation dialog. jml ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] stories for external test helpers (librarian, memcache, etc)
On Tuesday 28 September 2010 23:39:41 Robert Collins wrote: Yes, you did, for clarity here - I'm not proposing to start *postgresql* dynamically [yet, the contract does permit it though] simply for performance reasons. I'd really like to see some of the other external processes started on demand though. For example, I object vehemently to these persistent services on my *desktop* machine: * Apache (and the rewrite script we use for Code) * Rabbit MQ (why is this installed when we're not even using it yet?) * Memcached Rabbit is particularly annoying because it blocks shutdown on my machine when it hangs :/ Requiring all this stuff to be running persistently is a very large barrier to drive-by contributions. Cheers J ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] generic job queue cronjob?
On Mon, Sep 27, 2010 at 2:46 PM, Aaron Bentley aa...@canonical.com wrote: ... We are already pretty decoupled there. When the scanner notices a branch tip change, it fires a TipChanged event. One of the subscribers generates the appropriate UpdatePreviewDiffJob. And they told me I was mad. Well, I'll show them. I'll show them all! Muahahahahah, jml ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] redundant Poppy (soyuz upload server) instances
On Tue, Sep 28, 2010 at 9:29 PM, Robert Collins robe...@robertcollins.net wrote: One of the SPOF's we have at the moment is poppy: we have a single instance of both the FTP and SFTP servers. Are any code changes needed to support having two instances of both (behind a load balancer, so clients won't know about them). Or is it just creating one/two new configs in production and deploying another copy running that config? I am assuming, given that we run a separate SFTP and FTP process, that there aren't any concurrency issues around the task being performed. I don't know about Poppy per se, but there's nothing in its SSH server code preventing multiple instances that I know of. jml ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] New utility script: update-copyright
On Tue, Sep 28, 2010 at 2:33 PM, Henning Eggers henning.egg...@canonical.com wrote: Hi LP coders! Devel revision 11645 has a new script utilities/update-copyright. It will update the years in the Copyright 2009-2010 Canonical Ltd. statement that is found on top of each source file (*) in the LP tree. This is such a minor thing that it is often forgotten and many files still refer to just 2009 although they have already been changed this year. (The notice was only added last year before LP was open-sourced.) Sounds good. How can I set this up as a pre-commit hook so I don't ever have to think about this again? jml ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] release branches
On Tue, Sep 28, 2010 at 4:41 AM, Robert Collins robert.coll...@canonical.com wrote: On Tue, Sep 28, 2010 at 4:05 PM, William Grant m...@williamgrant.id.au wrote: This would chop 4 hours off the time that things take to deploy, remove one buildbot queue and generally make the whole code-live story a bit simpler, at the cost of making the security-fix story more complex. Personally, I think that that is a net win. It's not just security fixes that need this sort of treatment. See, for example, jtv's recent emergency Codehosting fix: it needed to skip ahead of un-QA'd revisions. Cowboying may be appropriate here too. I don't really know. So really, we're saying that there are two sorts of changes: - must-deploy-asap - deploy-with-due-care This sounds straightforward. Would it be appropriate to start tracking how often we engage the must-deploy-asap branch of the process? jml ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] redundant Poppy (soyuz upload server) instances
On Wednesday 29 September 2010 12:24:12 Jonathan Lange wrote: On Tue, Sep 28, 2010 at 9:29 PM, Robert Collins robe...@robertcollins.net wrote: One of the SPOF's we have at the moment is poppy: we have a single instance of both the FTP and SFTP servers. Are any code changes needed to support having two instances of both (behind a load balancer, so clients won't know about them). Or is it just creating one/two new configs in production and deploying another copy running that config? I am assuming, given that we run a separate SFTP and FTP process, that there aren't any concurrency issues around the task being performed. I don't know about Poppy per se, but there's nothing in its SSH server code preventing multiple instances that I know of. There is an issue in both to do with file name creation races isn't there? ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] stories for external test helpers (librarian, memcache, etc)
On Wed, Sep 29, 2010 at 5:54 PM, Julian Edwards julian.edwa...@canonical.com wrote: * Rabbit MQ (why is this installed when we're not even using it yet?) * Memcached You can turn off memcached - LP starts this as necessary. And RabbitMQ since no code is using it yet (waiting on staging install). I think the 'preferred' method is still the incredibly ugly: update-rc.d -f memcached remove update-rc.d memcached stop 20 2 3 4 5 . (or is there some way of making service(8) do the right thing? Nothing in the manpage) Rabbit is particularly annoying because it blocks shutdown on my machine when it hangs :/ My laptop too. I keep forgetting to disable it :) -- Stuart Bishop stu...@stuartbishop.net http://www.stuartbishop.net/ ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] so many unmerged branches
On Wed, Sep 29, 2010 at 2:44 AM, Jon Sackett jonathan.sack...@canonical.com wrote: - 4 hour test suites [highly delayed feedback] - testfix *existing* [after your 4 hour check, it can still bounce] - a high rate of spurious errors ( 1% is high, and I'm pretty sure thats the case) - folk working on many things at once (which is itself a result of the 4 hour queue) From the perspective of a newer developer, you have succinctly grabbed the basic problems I have with getting branches from Approved to Merged. If it weren't for the fact that the number of balls I'm juggling is pretty low right now, I'm sure branches would start being forgotten. I'm practically an old hand and they're the same problems for me. There are a few tricks you can use to not forget branches: * Consult https://code.edge.launchpad.net/~jcsackett/launchpad * Consult https://code.edge.launchpad.net/~jcsackett/+activereviews * Delete local copies (or checkouts) of branches after they've been merged into stable/db-stable * Keep the number of branches low I especially rely on the third one, since it's really easy for me to do `ls ~/src/launchpad` to see what work I've got outstanding. jml ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFI: translations of website applications
On Tue, Sep 28, 2010 at 10:32 PM, Robert Collins robe...@robertcollins.net wrote: Personally I'd welcome translation of Launchpad's UI itself and I think answers is a great place to start. I think that we could, for instance, ask for 'please write the bug report in english' on bug pages and so forth, to mitigate the 'we may get lots of non english reports'. Translating user content, like project descriptions would be awesome too. Hi, Rob. I think we need to think through the potential bug problem a bit more. People don't read warnings on websites. :-) I have heard the concern expressed 3 or 4 times in the last year that the problem of a large numbers of bugs would get worse if a non-small amount of those bugs were suddenly entered in languages other than English. I'm not against translating Launchpad, but I think we have to have a better answer than add a warning to the page. I'm not sure what that answer is, though. I don't see this preventing starting work on this with the answers app, but I do think we need to be thinking more about this before moving on to the bugs app. Cheers, deryck -- Deryck Hodge https://launchpad.net/~deryck http://www.devurandom.org/ ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFI: translations of website applications
У сре, 29. 09 2010. у 06:53 -0500, Deryck Hodge пише: I don't see this preventing starting work on this with the answers app, but I do think we need to be thinking more about this before moving on to the bugs app. I agree that we do need a better answer than let's put up a warning. I think the one I mentioned (i.e. engaging community to translate bug reports back to English) would be a nice way to give even more people an opportunity to contribute and get involved (i.e. the quality of bug report translation doesn't have to be as high as regular UI translation). FWIW, I'd say the natural next target after Answers is Translations, then Registry, and only then other apps like Code, Soyuz and Bugs. And the point we start translating Registry, we'd have to come up with a good solution to this problem, so I wouldn't stress too much about getting bug comments in a different language (we already do to a small extent). Cheers, Danilo ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] so many unmerged branches
On Wed, Sep 29, 2010 at 6:50 AM, Jonathan Lange j...@canonical.com wrote: I'm practically an old hand and they're the same problems for me. There are a few tricks you can use to not forget branches: * Consult https://code.edge.launchpad.net/~jcsackett/launchpad * Consult https://code.edge.launchpad.net/~jcsackett/+activereviews * Delete local copies (or checkouts) of branches after they've been merged into stable/db-stable * Keep the number of branches low I especially rely on the third one, since it's really easy for me to do `ls ~/src/launchpad` to see what work I've got outstanding. The kanban board should help with the last item. We're making sure cards correspond to branches rather than bugs on the bugs team board. Part of this is to better reflect the work we're doing and see if that helps cycle time and part of it is to make sure we don't have work lingering forever. Cheers, deryck -- Deryck Hodge https://launchpad.net/~deryck http://www.devurandom.org/ ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFI: translations of website applications
On Wed, Sep 29, 2010 at 7:04 AM, Danilo Šegan dan...@canonical.com wrote: У сре, 29. 09 2010. у 06:53 -0500, Deryck Hodge пише: I don't see this preventing starting work on this with the answers app, but I do think we need to be thinking more about this before moving on to the bugs app. I agree that we do need a better answer than let's put up a warning. I think the one I mentioned (i.e. engaging community to translate bug reports back to English) would be a nice way to give even more people an opportunity to contribute and get involved (i.e. the quality of bug report translation doesn't have to be as high as regular UI translation). FWIW, I'd say the natural next target after Answers is Translations, then Registry, and only then other apps like Code, Soyuz and Bugs. And the point we start translating Registry, we'd have to come up with a good solution to this problem, so I wouldn't stress too much about getting bug comments in a different language (we already do to a small extent). Yes, I think translating the bug reports back to English could work. I think the general plan you outline looks good to me, too. Cheers, deryck -- Deryck Hodge https://launchpad.net/~deryck http://www.devurandom.org/ ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] so many unmerged branches
On Wed, Sep 29, 2010 at 7:05 AM, Deryck Hodge deryck.ho...@canonical.com wrote: On Wed, Sep 29, 2010 at 6:50 AM, Jonathan Lange j...@canonical.com wrote: I'm practically an old hand and they're the same problems for me. There are a few tricks you can use to not forget branches: * Consult https://code.edge.launchpad.net/~jcsackett/launchpad * Consult https://code.edge.launchpad.net/~jcsackett/+activereviews * Delete local copies (or checkouts) of branches after they've been merged into stable/db-stable * Keep the number of branches low I especially rely on the third one, since it's really easy for me to do `ls ~/src/launchpad` to see what work I've got outstanding. The kanban board should help with the last item. We're making sure cards correspond to branches rather than bugs on the bugs team board. Part of this is to better reflect the work we're doing and see if that helps cycle time and part of it is to make sure we don't have work lingering forever. As I clicked send, I realized this doesn't help non-Canonical Launchpad devs. But those of us using the Kanban board can add a card for community dev branches when we land those on another dev's behalf. Cheers, deryck ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFI: translations of website applications
On Wed, 2010-09-29 at 06:53 -0500, Deryck Hodge wrote: I have heard the concern expressed 3 or 4 times in the last year that the problem of a large numbers of bugs would get worse if a non-small amount of those bugs were suddenly entered in languages other than English. I'm not against translating Launchpad, but I think we have to have a better answer than add a warning to the page. I'm not sure what that answer is, though. The lose of registration/login/reset makes it harder to complete the user experience we want for Answers. We want to allow a non-technical user to come to accomplish a few tasks in their native language: * Search for an answer * Ask a question * Answer a question These last two points require a logged in user. It when Lp managed identity to allow users to register/login/reset in their own language. The profile page and links to answers need to be translated too. There is no solution/infrastructure for translating email templates. -- __Curtis C. Hovey_ http://launchpad.net/ signature.asc Description: This is a digitally signed message part ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] stories for external test helpers (librarian, memcache, etc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2010 06:54 AM, Julian Edwards wrote: On Tuesday 28 September 2010 23:39:41 Robert Collins wrote: Yes, you did, for clarity here - I'm not proposing to start *postgresql* dynamically [yet, the contract does permit it though] simply for performance reasons. I'd really like to see some of the other external processes started on demand though. For example, I object vehemently to these persistent services on my *desktop* machine: * Apache (and the rewrite script we use for Code) Because Apache's config contains a symlink to a file in my home directory, and my home directory is not available at apache startup time (because it's encrypted), Apache actually doesn't start for me. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyjPWsACgkQ0F+nu1YWqI2dzwCePGKjcnuKs7Qo2eSk27cOkhDx z88An1ZQgbrVbEy56H+KLm7MKKnWNdbl =YObx -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] How do we fix the Launchpad's login experience?
On Wed, 2010-09-29 at 11:39 +0100, Jonathan Lange wrote: Many projects are concerned that Launchpad is too tied to Ubuntu. Forcing them through an Ubuntu authentication gateway will probably not help with that. I don't disagree with you, but I haven't heard anything from these projects. I'd like to know more about their concerns, do you have anything that could help me follow this up? I would ask this differently. Launchpad uses Ubuntu SSO to manage identity now. Do projects believe this is deceitful (this sounds harsher than I mean), that they are being tricked into using Ubuntu SSO. I really think this is a non-issue given that (as I understand) the goal is to allow Lp to with with any OpenID provider. -- __Curtis C. Hovey_ http://launchpad.net/ signature.asc Description: This is a digitally signed message part ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] stories for external test helpers (librarian, memcache, etc)
On Wed, 29 Sep 2010 18:50:35 +0700, Stuart Bishop stuart.bis...@canonical.com wrote: On Wed, Sep 29, 2010 at 5:54 PM, Julian Edwards julian.edwa...@canonical.com wrote: * Rabbit MQ (why is this installed when we're not even using it yet?) * Memcached You can turn off memcached - LP starts this as necessary. And RabbitMQ since no code is using it yet (waiting on staging install). I think the 'preferred' method is still the incredibly ugly: update-rc.d -f memcached remove update-rc.d memcached stop 20 2 3 4 5 . (or is there some way of making service(8) do the right thing? Nothing in the manpage) This is not the preferred way. Unfortunately there isn't yet a way to consistently do this across services, but there is a convention to have an /etc/default/name file where it can be configured. Therefore to stop memcached running you can edit /etc/default/memcached and change ENABLE_MEMCACHED to no. RabbitMQ unfortunately doesn't have as nice a way of doing it, but you could set DAEMON=true in /etc/default/rabbitmq if you wanted to do it. Thanks, James ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] release branches
Hi Robert, I think this is a nice simplification of our process. Let's proceed with this once qastaging is live and edge no more. Cheers -- Francis J. Lacoste francis.laco...@canonical.com On September 27, 2010, Robert Collins wrote: Hi, we have currently a production-stable branch which is private; it is maintained with CP's and merges during a cycle and discarded every time we bring db-stable into play. I'd like to suggest that we make a few changes here as RFWTAD progresses. Firstly, I think that security patches which have never been public are really very very rare: we can make the process for dealing with them a little more complex, and make the common case much simpler, for an overall net win. Once we have qastaging live, we're going to be switching deployments to edge that haven't been QA'd, off. QA will be moving to qastaging. At that point, if we want to, we can simply stop using production-devel and production-stable. Here's how it would work. We deploy stable rather than production-stable to servers. This would mean no more CP's - only cowboys and deploys. We shouldn't need CP's because we have the QA process Maris mailed out for moving things on stable into production. And at that point, if we have a security issue we have to deploy asap; we'd do the following: - cowboy it out there [and keep it as a cowboy on future deploys] - land a regular branch fixing it for good - remove the cowboy when the regular branch has been incorporated into the main deployed codebase. This would chop 4 hours off the time that things take to deploy, remove one buildbot queue and generally make the whole code-live story a bit simpler, at the cost of making the security-fix story more complex. Personally, I think that that is a net win. Seeking-your-thoughts, Rob ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp signature.asc Description: This is a digitally signed message part. ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] performance tuesday... tests
Hi Robert, On September 28, 2010, Robert Collins wrote: Several ways, firstly layers, by supporting setup-only fixtures add about 30-40 seconds per test run for every layer that we have that can't be torn down. Secondly, because layers are so fragile, our test fixtures do redundant work on setup - they have code to shutdown failed-to-shutdown instances that can spin for up to 5 seconds (by default). Unless I'm mistaken the only layer that can't be currently torn down is the FunctionalLayer that loads the ZCML. And I remember Gary telling me that recent zope libraries (that we are using) now support unloading the zope component registry. So in theory, we could make all our layers support tear down. -- Francis J. Lacoste francis.laco...@canonical.com signature.asc Description: This is a digitally signed message part. ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] performance tuesday... tests
On Wed, Sep 29, 2010 at 3:15 PM, Francis J. Lacoste francis.laco...@canonical.com wrote: Hi Robert, On September 28, 2010, Robert Collins wrote: Several ways, firstly layers, by supporting setup-only fixtures add about 30-40 seconds per test run for every layer that we have that can't be torn down. Secondly, because layers are so fragile, our test fixtures do redundant work on setup - they have code to shutdown failed-to-shutdown instances that can spin for up to 5 seconds (by default). Unless I'm mistaken the only layer that can't be currently torn down is the FunctionalLayer that loads the ZCML. And I remember Gary telling me that recent zope libraries (that we are using) now support unloading the zope component registry. So in theory, we could make all our layers support tear down. The Zopeless layer also can't be torn down. I believe it's for the same reasons, so the theory still holds. jml ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] redundant Poppy (soyuz upload server) instances
On Wed, Sep 29, 2010 at 12:38 PM, Julian Edwards julian.edwa...@canonical.com wrote: On Wednesday 29 September 2010 12:24:12 Jonathan Lange wrote: On Tue, Sep 28, 2010 at 9:29 PM, Robert Collins robe...@robertcollins.net wrote: I am assuming, given that we run a separate SFTP and FTP process, that there aren't any concurrency issues around the task being performed. I don't know about Poppy per se, but there's nothing in its SSH server code preventing multiple instances that I know of. There is an issue in both to do with file name creation races isn't there? Don't know. A very quick scan through the code mentions bug 156795 and bug 185731. Next step is for someone (not me!) to either do some serious code analysis or an experiment. Or both. jml ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
[Launchpad-dev] Script and Cronscript updates
Some changes have landed recently to make script wragling better. Now for scripts and cronscripts, the --log-file argument has been decoupled from the stderr verbosity settings. It has also been extended to specify the level of messages that go into the log file. So now the following will emit WARNING and above messages to stderr, and log DEBUG and above messages to the given file: foo.py -q --log-file=/var/logs/foo.log logrotate can be used to rotate the logs - the Python logging system watches for rotation and handles things gracefully. Cronscripts now generate OOPS reports for WARNING and above log messages. Other scripts do not (they could, but it didn't seem to make much sense). We also have a config file that can be retrieved from a URL to enable or disable cronscripts individually or in bulk. The default config file location is file:cronscripts.ini (relative to the tree root, so cronscripts.ini in the root of the tree), and can be overridden by setting cron_control_url in the [canonical] section of the active launchpad-lazr.conf file. The file can look like this: [DEFAULT] enabled = True [checkwatches] enabled = False If a script can't find its own section, the DEFAULT is used. If the config cannot be loaded or parsing fails, things default to enabled. Scripts emit an INFO message if they are disabled. The script names are the same ones the monitoring scripts look for. Our first use of this could be to disable staging cronscripts during staging updates - if they kick in at the wrong time during the update it can cause deadlocks and the update to abort, like we saw yesterday. -- Stuart Bishop stu...@stuartbishop.net http://www.stuartbishop.net/ ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] How do we fix the Launchpad's login experience?
On September 24, 2010, William Grant wrote: On Fri, 2010-09-24 at 00:38 -0400, Elliot Murphy wrote: I'm really glad to see this being discussed in detail. On Thu, Sep 23, 2010 at 7:18 PM, William Grant m...@williamgrant.id.au wrote: I use https://launchpad.net/~statik/ to login via openID to various 3rd party sites such as stackoverflow.com. Is this going to stop working ?(I won't complain if it does, just trying to understand) That's the XRDS coming into play. If you look at the HTML, you'll see elements delegating the page's identity to login.launchpad.net. login.launchpad.net and login.ubuntu.com are real OpenID providers, while Launchpad just has a couple of tags that delegate. This XRDS dates from the days when LP was an OpenID provider, and there was no other URL to use. It could probably be deprecated, perhaps with newly-created profiles not providing the delegation tags. The plan was once we support arbitrary OpenID provider, we would let you choose to which identity your profile identity is delegated. With probably a default option of no delegation. (A feature stolen from Sourceforge :-) In summary: fix bug #637968, make LP a general RP, destroy login.launchpad.net. This sounds like a good summary, although I would like to understand why is making LP a general RP a necessary step? As above: we don't want to scare more people off LP. Forcing everyone through somewhere with heavy Ubuntu branding is going to scare more people off. That was the working assumption when we rebranded the SSO site to Ubuntu (and not Canonical). It might be argued though, that people who object to using Launchpad because of the Ubuntu SSO login wouldn't use it anyway because of the Canonical/Ubuntu link. Said differently: we assumed the difference between the set of people who won't use Launchpad with a Ubuntu-branded SSO and the set of people who won't use Launchpad is non-empty. A different assumption is that these two sets are identical and the difference is empty. We could test this assumption by sending an email to all Lauchpad users stating our intention of using the Ubuntu SSO in a month, what it means for them, what is the change they are going to see... and counting the number of people who scream :-) -- Francis J. Lacoste francis.laco...@canonical.com signature.asc Description: This is a digitally signed message part. ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] RFI: translations of website applications
For what's it worth, the SSO part is already I18Ned. So the login/registration process has already been taken care of. -- Francis J. Lacoste francis.laco...@canonical.com On September 29, 2010, Curtis Hovey wrote: On Wed, 2010-09-29 at 06:53 -0500, Deryck Hodge wrote: I have heard the concern expressed 3 or 4 times in the last year that the problem of a large numbers of bugs would get worse if a non-small amount of those bugs were suddenly entered in languages other than English. I'm not against translating Launchpad, but I think we have to have a better answer than add a warning to the page. I'm not sure what that answer is, though. The lose of registration/login/reset makes it harder to complete the user experience we want for Answers. We want to allow a non-technical user to come to accomplish a few tasks in their native language: * Search for an answer * Ask a question * Answer a question These last two points require a logged in user. It when Lp managed identity to allow users to register/login/reset in their own language. The profile page and links to answers need to be translated too. There is no solution/infrastructure for translating email templates. signature.asc Description: This is a digitally signed message part. ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] How to QA your code for continuous rollouts
On September 27, 2010, Julian Edwards wrote: On Friday 24 September 2010 03:50:42 Maris Fogels wrote: There's one more scenario that I'd like to see - marking a change as already qa-ok when it lands. In the Soyuz team we frequently do QA on unlanded branches on the dogfood server, partly because it's easy for us to do this, and partly because we're extremely uncomfortable landing some kinds of changes without a *lot* of QA first (over several weeks). Right now I am using the [no-qa] tag for PQM which makes the scripts mark the bug as qa-untestable. I'd like it if we could have a [qa-ok] as well to indicate that QA was indeed carried out sucessfully. This would also reduce my frustration when I forget that the tagger script happily removes my qa-ok tag and replaces it with something else. ;) I think this is a sensible request. There are some other use cases where a change is QA-ed on staging by a manual merge before being landed. (That happens for release-critical bug fixes or security fixes). -- Francis J. Lacoste francis.laco...@canonical.com signature.asc Description: This is a digitally signed message part. ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] How to QA your code for continuous rollouts
On September 23, 2010, Maris Fogels wrote: = Has my branch been deployed yet? = We have created HTML reports that shows the QA status of all of the revisions on stable and db-stable: https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html https://devpad.canonical.com/~lpqateam/qa_reports/deployment-db- stable.html Hi Maris, Thanks a lot to Diogo, Ursula and you for these changes! This is greatly appreciated. A few nit-picks on the reports. * It says 'Revision X can be deployed to edge'. That should be 'production' since we are getting rid of edge and currently automatically deploying to it. * If the first revision is undeployable, the message reads weird 'Revision can be deployed to edge' * You need some special logic to handle the automatic merge from stable. These are marked as orphaned. Which doesn't make sense. In the ideal world, we should probably mark them as qa-ok once all the revisions contained in the merge are marked as qa-ok/qa-untestable. Cheers -- Francis J. Lacoste francis.laco...@canonical.com signature.asc Description: This is a digitally signed message part. ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] how to use feature flags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/21/2010 06:09 PM, Robert Collins wrote: yes, see the existing tests that do it ;) I suggest the memcache ones as an example. There is an XXX there that needs fixing too. You mean this? ignore = getFeatureStore().add(FeatureFlag( ... scope=u'default', flag=u'memcache', value=u'disabled', ... priority=1)) empty_request = LaunchpadTestRequest() per_thread.features = FeatureController( ... ScopesFromRequest(empty_request).lookup) I think there's a lot of room for improvement here. If feature flags are meant to be pervasive, I think we should be able to depend on their existence in tests, not need to create them explicitly-- otherwise, we'll get test failures because the FeatureController hasn't been initialized. (Or worse, we'll accidentally leak FeatureControllers into other tests.) If performance is an issue, we can make a LazyFeatureController that won't cost anything unless we use a FeatureFlag. There's also a significant disconnect between how flags are queried and how they are set. Since they are queried via FeatureController, I searched in vain for a method to set them there. Also, features.getFeatureFlag is a function, not a method, so it should not have a camelCase name. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyjhJcACgkQ0F+nu1YWqI3k9QCfbILJTc+ny/BVsn2cHCchlxjV 3OEAn1sgKvJVrObQWyHFzfGXTs7ZSMxa =1OBY -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] how to use feature flags
On 09/29/2010 02:25 PM, Aaron Bentley wrote: On 09/21/2010 06:09 PM, Robert Collins wrote: yes, see the existing tests that do it ;) I suggest the memcache ones as an example. There is an XXX there that needs fixing too. You mean this? ignore = getFeatureStore().add(FeatureFlag( ... scope=u'default', flag=u'memcache', value=u'disabled', ... priority=1)) empty_request = LaunchpadTestRequest() per_thread.features = FeatureController( ... ScopesFromRequest(empty_request).lookup) I think there's a lot of room for improvement here. If feature flags are meant to be pervasive, I think we should be able to depend on their existence in tests, not need to create them explicitly-- otherwise, we'll get test failures because the FeatureController hasn't been initialized. (Or worse, we'll accidentally leak FeatureControllers into other tests.) If performance is an issue, we can make a LazyFeatureController that won't cost anything unless we use a FeatureFlag. There's also a significant disconnect between how flags are queried and how they are set. Since they are queried via FeatureController, I searched in vain for a method to set them there. Also, features.getFeatureFlag is a function, not a method, so it should not have a camelCase name. Aaron I have a branch in development that adds a much easier to use test helper for setting feature flags during development. Unfortunately I am blocked on the flags not being set properly during one peculiar pagetest (if anyone is able to help me with this, please feel free to ping me on IRC). Once I figure out how to get the flags to work in my branch, then I will land it and update the list with instructions for using the new helpers. -- Māris Fogels -- https://launchpad.net/~mars Launchpad.net -- cross-project collaboration and hosting signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] The future of downtime for rollouts?
I like the idea of a fixed downtime budget a lot. What do we need to make it happen? My thoughts: * A feedback mechanism allowing us to track how much of the budget is spent. * Something like a script that extracts a measure from the staging update? * Once the budget is spent, no more DB changes. * We probably need a way to input the budget for case where a OS maintenance task will shrink the DB budget. -- Francis J. Lacoste francis.laco...@canonical.com On September 14, 2010, Robert Collins wrote: On Wed, Sep 15, 2010 at 12:46 AM, Curtis Hovey curtis.ho...@canonical.com wrote: On Tue, 2010-09-14 at 11:41 +0100, Tom Haddon wrote: Might be more reliable but less accurate :) We estimate the downtime based on how long the last update took on staging, and then multiplying by a factor that seems to have accurately reflected the difference in time between staging and production (with a little padding). We could only commit to 90 mins if we refused to rollout any DB updates that took longer than a certain period of time on staging. Staging restore times trend up, so we are always talking about increasing time for a rollout. We will continue to do schema development after the featureflag is complete. What we cannot see is the staging restore time verses the real time--maybe that is pointless because there are other rollout incidents that increased the rollout. Staging restore times as a whole are a poor surrogate as already discussed. The point I am making is that unless we decide *how much downtime we will tolerate*, we'll always have reasons to do more. So I'm proposing: - a 90m budget. - if we can't do it in that timeframe, we don't do it. We *will have to* innovate and address various issues to stick to this, but 90m of time is actually a lot of lost time to the many thousands of users we have in every timezone. We could spend a week with the whole team working on something to make the upgrade faster, and still be spending less time than our users are losing, when we're down. -Rob ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp signature.asc Description: This is a digitally signed message part. ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] ArchitectureGuide - all developers please read this ; )
This looks great.
I think the values are on the mark and that the metric are at the very least
worth a try.
What was the reviewers feedback on this?
--
Francis J. Lacoste
francis.laco...@canonical.com
On September 9, 2010, Robert Collins wrote:
So at the Epic I proposed some architectural values that I hope will
help us reach some goals for the system. This wiki page:
https://dev.launchpad.net/ArchitectureGuide lays those goals, values
and draft metrics out.
Our review team is very good at having sensible discussions about all
the code that comes into the system, and I've asked (via the normal
process for review changes) that they start including in those
discussions questions/comments about those values and metrics on the
ArchitectureGuide page.
There will be specific things like ('does this page/API do more
queries as it gets more data') which we may want to accumulate as
things-to-look for - please put them on *their* relevant wiki page
(e.g. for the example I gave, dev.launchpad.net/Database/Performance
might be a sensible place, or just /Performance).
The goal I have here is to provoke *discussion and analysis*, so that
our shared body of knowledge for delivering a fast, robust flexible
product increases in the areas I've highlighted on the
ArchitectureGuide page, which were not previously covered at all. We
all own the guide, so like the rest of the wiki, this is a living
page: please dive in and improve it.
I'm totally sure the metrics I'm suggesting are noddy and
dialed-wrongly : lets fix those as we go, or perhaps even take them
out. Though I think it is nice to a ballpark figure to aim for for
things, just to prompt one to think about the issues.
I'm going to follow up in the review meetings over the next few weeks
to see how reviewers are finding these discussions, and how its
working for everyone.
In short, I'd love it if you can:
- Please read the ArchitectureGuide. It contains useful stuff. In a
very broad sense, follow its recommendations/request or fix it if its
wrong.
- I believe that doing this will help us all have a better product in
a very significant fashion.
- In every review, whether you are the reviewee or reviewer, try to
talk about -even one- of the values I mention. For instance, talk
performance.
Cheers,
Rob
___
Mailing list: https://launchpad.net/~launchpad-dev
Post to : launchpad-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~launchpad-dev
More help : https://help.launchpad.net/ListHelp
signature.asc
Description: This is a digitally signed message part.
___
Mailing list: https://launchpad.net/~launchpad-dev
Post to : launchpad-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~launchpad-dev
More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] stories for external test helpers (librarian, memcache, etc)
On Wed, 29 Sep 2010 11:54:01 +0100, Julian Edwards julian.edwa...@canonical.com wrote: On Tuesday 28 September 2010 23:39:41 Robert Collins wrote: Yes, you did, for clarity here - I'm not proposing to start *postgresql* dynamically [yet, the contract does permit it though] simply for performance reasons. I'd really like to see some of the other external processes started on demand though. For example, I object vehemently to these persistent services on my *desktop* machine: * Apache (and the rewrite script we use for Code) Yeah, this sucks. I'm not sure what would be better though. I guess we could run an apache that listens on a high port under Launchpad's control when we run make run_codehosting and have bazaar.launchpad.dev:80 proxy to that. An alternative would be using something other than Apache to serve the static data and get away from the horrible prg rewrite interface, but that's a little bit scary. Cheers, mwh ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] generic job queue cronjob?
On 27 September 2010 23:46, Aaron Bentley aa...@canonical.com wrote: On 09/24/2010 05:45 PM, Martin Pool wrote: On 24 September 2010 23:27, Aaron Bentley aa...@canonical.com wrote: Right. I was wondering if Launchpad was going to (now, or later) change to just sending this branch tip changed and then have the recipients decide what to do with that. For instance, we want to update precalculated mp preview diffs when the branch changes. Ideally, in a message system, the branch scanner wouldn't need to know anything about that, only the job that's subscribed to those events. We are already pretty decoupled there. When the scanner notices a branch tip change, it fires a TipChanged event. One of the subscribers generates the appropriate UpdatePreviewDiffJob. That's what I meant: it seems like we already have both pubsub and task-dispatch type messaging. Perhaps we are happy having the events happen entirely in process for now, but if we're considering future architecture perhaps it should be taken into account. If we want to take that direction perhaps it's better not considering it only as a task dispatch system? I don't know about that. It's quite useful to represent this as a job, not an event. (You could do an event message which generates a job message, but that seems inefficient to me.) But isn't that basically what you described above? Or are you saying it would be inefficient to do an event passed out to an external broker rather than just transmitted within zope? We can then inform our users that a diff is pending (and maybe distinguish between pending and in progress). This is a real-world example of imperative messages imply an expected consequence, while informative messages don't, and leave us less-informed as a consequence. Nice example, particularly that if you know you requested a task rather than just sending a message you can check its status, potentially cancel it, etc. -- Martin ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Test results: flags-gui = devel: SUCCESS
That's such a nice subject line I had to keep it. When devel is next deployed, Launchpad will get a /+feature-rules page, through which ~admins can configure feature flag rules, as an alternative to losas updating them through sql. http://launchpadlibrarian.net/56727141/20100929-feature-control.png For instance if someone adds a flag to disable moving bugs out of fix-released, we might add bugs.lock_fix_released edge 100 true where the fields are - the flag name, matching your call to getFeatureFlag http://people.canonical.com/~mwh/canonicalapi/lp.services.features.html - the scope selector in which you want this value to apply - the priority of this rule, higher numbers being more important, used when more than one scope could match for this flag - the value it will take, as a string I encourage you to use this on launchpad.dev to interactively test how your feature flags work. Changes to the rules on production are governed by the ProductionChangeApprovalPolicy (internal link: https://wiki.canonical.com/Launchpad/PolicyandProcess/ProductionChangeApprovalPolicy) which basically means that you should ask a team lead, project lead, or technical architect, who will then ask a LOSA to actually make the change. -- Martin ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] stories for external test helpers (librarian, memcache, etc)
So, starting services that we need just in time. I'm totally +1 on this. What it broadly needs: - some way to install but not run (at all) system services such as apache, which can be custom per-thing, we just need to ensure that when you install the thing *via* the lp-developer-deps that this happens. one way would be to depend on e.g. lp-apache | apache, and lp-apache would do the disabling stuff; it would only be pulled in if apache wasn't already installed. - glue to configure-and-run those services when we need them. This could take [at least] two forms: - system wide configs (e.g. like the apache site we use) and we start the service - transient configs generated on the fly just for use (and then we run the binary with only our config) Clearly system wide configs is what we use for apache and postgresql, and we may want to where the service is particularly costly to bring up; but we don't need to stop there. I'm not *personally* driven to improve this area yet, because I think the incremental benefits are small compared to concurrent test runs, for instance. It does have the potential to make it dramatically easier to get setup developing on LP though, which would be awesome. -Rob ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] The future of downtime for rollouts?
On Thu, Sep 30, 2010 at 9:07 AM, Francis J. Lacoste francis.laco...@canonical.com wrote: I like the idea of a fixed downtime budget a lot. What do we need to make it happen? My thoughts: * A feedback mechanism allowing us to track how much of the budget is spent. * Something like a script that extracts a measure from the staging update? * Once the budget is spent, no more DB changes. * We probably need a way to input the budget for case where a OS maintenance task will shrink the DB budget. Those things may help automate the process but I think all we actually need is: * Choose a budget. * Change the release managers documentation to remove 'determine the downtime window' stuff and instead be 'announce how much of the budget will be used'. We only need these two things as long as we have some constraints: - the LOSA OS maintenance windows are the downtime budget and we know a cycle in advance for them. - there is a chokepoint for DB patches where someone can assess how we're going when patches are considered. And we already have those constraints. -Rob ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] The future of downtime for rollouts?
On 30 September 2010 06:07, Francis J. Lacoste francis.laco...@canonical.com wrote: I like the idea of a fixed downtime budget a lot. What do we need to make it happen? My thoughts: * A feedback mechanism allowing us to track how much of the budget is spent. * Something like a script that extracts a measure from the staging update? * Once the budget is spent, no more DB changes. * We probably need a way to input the budget for case where a OS maintenance task will shrink the DB budget. It seems like, by saying no more DB changes, you're anticipating a budget that refills only every several months or so. That's a pretty interesting idea. I thought what Robert was saying, though, was a cap at 90 minutes on any single outage. -- Martin ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] ArchitectureGuide - all developers please read this ; )
I liked the talk and I like the values expressed here. To me, this document in its current form is not really an architecture guide. In a document with that name I'd expect to find some discussion of the big moving parts in the system (zope, storm, jobs, cronscripts), what kind of approach we like people to take (do security in zcml, don't write doctests, ...), and so on. Probably some of that is already written down and can merge into this. Coupling: No more than 5 dependencies of a component. Cohesion: Attributes should be used in more than 1/3 of interactions. If they are used less often than that, consider deleting or splitting into separate components. I still think those are really weird expressions of useful values. :-} Perhaps it could be If you can split a class into two or more simpler classes, do it. -- Martin ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] How to QA your code for continuous rollouts
I wish, as part of these changes, Launchpad would change away from using the confusing term QA for this process. QA proper means much more than just testing, but the process described here isn't even testing or verification that the bug is actually fixed. It's more like shakedown or approval for deployment. -- Martin ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Test results: flags-gui = devel: SUCCESS
On Thu, Sep 30, 2010 at 09:04:33AM +1000, Martin Pool wrote: That's such a nice subject line I had to keep it. Indeed, thanks, I've been appreciating this new format today. :-) Bryce ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] ArchitectureGuide - all developers please read this ; )
I still think those are really weird expressions of useful values. :-} Perhaps it could be If you can split a class into two or more simpler classes, do it. Thats a nice test to use as well; perhaps you could add it to the page? -Rob ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] performance tuesday... tests
On Wed, Sep 29, 2010 at 9:15 PM, Francis J. Lacoste francis.laco...@canonical.com wrote: Hi Robert, On September 28, 2010, Robert Collins wrote: Several ways, firstly layers, by supporting setup-only fixtures add about 30-40 seconds per test run for every layer that we have that can't be torn down. Secondly, because layers are so fragile, our test fixtures do redundant work on setup - they have code to shutdown failed-to-shutdown instances that can spin for up to 5 seconds (by default). Unless I'm mistaken the only layer that can't be currently torn down is the FunctionalLayer that loads the ZCML. And I remember Gary telling me that recent zope libraries (that we are using) now support unloading the zope component registry. So in theory, we could make all our layers support tear down. But the really interesting thing is that I think the only reason we had to go with layers was that it handled resources that couldn't be torn down. If the CA teardown works reliably and as expected, I don't see anything else tying us to layers. Layers never really fit right - I got agreement with upstream for a 'resources' model supporting our complex environment that would have been backwards compatible, but nobody ever got around to implementing it. -- Stuart Bishop stu...@stuartbishop.net http://www.stuartbishop.net/ ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] How to QA your code for continuous rollouts
On Mon, Sep 27, 2010 at 6:41 PM, Julian Edwards julian.edwa...@canonical.com wrote: Right now I am using the [no-qa] tag for PQM which makes the scripts mark the bug as qa-untestable. I'd like it if we could have a [qa-ok] as well to indicate that QA was indeed carried out sucessfully. This would also reduce my frustration when I forget that the tagger script happily removes my qa-ok tag and replaces it with something else. ;) It is a little overenthusiastic isn't it. I just qa-ok'd https://bugs.edge.launchpad.net/launchpad-foundations/+bug/628637 for the third time. Maybe third time is the charm? -- Stuart Bishop stu...@stuartbishop.net http://www.stuartbishop.net/ ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
