Re: [Launchpad-dev] Checklist 403
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14-01-07 11:21 AM, anatoly techtonik wrote: On this page: https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess Checklist page is 403. Works for me. This may be because I'm a member of the Launchpad team. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLMNZoACgkQ0F+nu1YWqI20kwCfa09WvMTARMArrMHQaPh4OdVU 2uQAn1OloDbelU4nMti8KuQuH21gjHH5 =j5sY -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] DB review process - time to change?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-10-03 10:22 PM, Robert Collins wrote: Stuart and I, and Francis and I have briefly discussed this, and we think the time has come to make DB reviews the same as regular code reviews. Sounds like a great idea. Should also improve timezone overlap with DB reviewers, and thus reduce our latency. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBtlpIACgkQ0F+nu1YWqI1xZwCeKrNTaNgxocCf/L0KnEB7xcgP uPAAnifDrta4zImyHMjploIHGD51QVnd =+Ksx -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] Parallel testing is live
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-09-21 10:41 AM, William Grant wrote: WebOps have today finished setting up parallel testing in buildbot. buildbot-poll has been updated to know about the new builders, and I've confirmed that [testfix] and automatic stable merging etc. work fine. Nothing should have changed except that builds now take 35 minutes rather than 6.5 hours. Congratulations! That duration is similar to bzr's test suite. With bzr, we've always been able to run in the traditional PQM mode where PQM runs the tests, and if they fail, the code doesn't land. I bet that would work with Launchpad too, which would allow us to simplify a lot of our infrastructure-- launchpad/devel and launchpad/stable become a single branch, we don't need buildbot anymore, and we don't need to use ec2 land. We can just lp-land directly. When test runs were longer, this mode caused unfortunate queueing, but with 35-minute test runs, we can do 41 test runs a day, and the most landings I see this month is 11 (on Sept 12). Most days are more like 6. While knocking buildbot times down to 35 minutes is good, we still have to use ec2 (or local test runs), which increases latency. I'd love it if we could knock the overall time from approval to landing in stable down to 35 minutes. It would be plausible, nay, common, to go from code to approval, to landing, to QA in a single day. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBctCgACgkQ0F+nu1YWqI3SXQCfcz32ERj2KRnBx2hk89163b81 RVEAn0WcWtj9yG6m5Jw7qL1wnGbtGYBD =wuMj -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] Parallel testing is live
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-09-21 03:22 PM, Francis J. Lacoste wrote: I agree that going back to pre-commit merge is one thing we could try. There is a caveat in your data though. You are counting the number of test runs processed by buildbot in a day. The number that is truly important is the number of ec2test submission daily. Because only once a successful ec2 test run has happened does it gets send to buildbot. Right. The number of landings was much easier to get, since it didn't require hacking all the launchpad team and grovelling their shell histories :-). However, we're only in trouble if the number of attempts exceeds 41, which would be ~ a 4:1 ratio of attempts to landings. Also, the number of attempts is probably correlated to the speed of landings-- i.e. the faster results come back, the more incentive people have to re-attempt landing before checking to ensure they've fixed every bug. What you are proposing (and what was happening before we switched to buildbot) is that developers simply use the landing architecture as a convenient test runner. One problem in the old days was that a lot of queued landings would fail simply because the tests hadn't been run, not because of failing tests because of a integration error or intermittent failure. (Although we had also some of those.) I'm not sure that's really a problem. People still have an incentive to be conscientious about running the obvious tests, because 35 minutes is still a long time. But if non-obvious tests fail, it's better for them to fail in 35 minutes via our parallel tester than in 4 hours via ec2. I think reckless landings would be self-limiting, because they would tend to generate queues, reducing the advantage of reckless landing. I don't know what's the effort required to set a tarmac instance that can run parallelized tests. (Unfortunately, it probably requires scarce webops resource also). But I'd be willing to try an experiment around that if it's cheap. Cool. To achieve the similar flow you want, we can also make ec2test run tests in parallel in EC2. Or Canonistack, since this probably involves a lot of re-work anyhow. On the big instances with 32 cores, Yellow was seeing a ~50 mins test run in EC2. That would put us well into range of writing and deploying code in the same day. (And deploying this requires 0 webops involvement). It also lets people run the full suite quickly for those cases where you know you've probably broken something, but you don't know where. Maybe this is also a good time to plug my fault-line plugin https://launchpad.net/fault-line, which uses revision history to find correlations between changed files and test files. It's good for doing a broader test run without running the full suite: bin/test -vm $(bzr fault-line --module-regex -r :submit) Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBc2vkACgkQ0F+nu1YWqI2mbACghSoFQ9W53SRLTpDHS6zoZXn9 k+sAn2EE6Bd2LfVhcGEyl2vLnzTyBn1f =cvq1 -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] js timeout issues on ec2 due to deep js namespaces
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-09-18 01:51 PM, Richard Harding wrote: We also should share namespaces among files better. So we're going to push for a standard of: Y.$app.$namespace. For instance, my code in question added a bunch of JS for the product. So I created Y.registry.views.NewProduct. Other modules and files can share that same namespace Y.registry.views and add on other classes such as ViewProduct, EditProduct, etc. They can all be in their own files and modules, but share the same namespace cleanly and prevent us from layering too deep. I think that we should not do this. You're suggesting breaking the connection between modules and namespaces, which will make life harder-- knowing the namespace, we don't know what module is needed. Knowing the module name, we can guess at the namespace, but we won't necessarily be right. You brought up 'array-extras' as an example on IRC, but I think this is a great example of why we shouldn't. 'array-extras' monkey-patches the Y.Array class on load. So if your code depends on a Y.Array method, you don't know what modules you need to load in order for your code to work. lp.app.information_type didn't require 'array-extras', but it used Y.forEach, which is defined in 'array-extras'. Because of this, I had no idea why the code didn't work. Had forEach been in a 'Y.array_extras' namespace instead, I would have save hours of time, both mine and yours when I ultimately came to you for help. Using consistent module and namespace makes coding and debugging simpler. I don't think we should give that up. If we have to make our namespaces shorter, we should adjust our modules to match. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBZ1lcACgkQ0F+nu1YWqI14TACfbrVM6lOcbtgWW5xqExxHt7/K AJIAnAhdB2niEH12F8jUWuVBvq1vXv7N =CgqR -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] visibility vs. information_type for Products
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-09-17 04:35 PM, Deryck Hodge wrote: I think the main argument against using information_type is that it supports values that don't apply for Products. I understand that point, but we can limit the values from information_type directly and still use information_type without all the headache of adding yet another enum that really is just like information_type with some values removed. Specification.infomation_type also does not support the full range of information_types. It is limited to PUBLIC, PROPRIETARY and EMBARGOED, the same as Product.information_type would be. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBYdgAACgkQ0F+nu1YWqI0bIQCaAu7Kajl+ePmC3oJqZBlSEugX mIsAnRUo1E9EJSqWh0rgeAL86uCtX2oX =QyTB -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] visibility vs. information_type for Products
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-09-18 11:03 AM, Curtis Hovey wrote: There are groups of people interacting with a project and they use different information types. * Project Creators use Public, Proprietary, and Embargoed for planning. * Project Community uses Public, Private (user), Private Security I don't understand this distinction. It seems like creator actually means owner or planner, since people who had no role in the creation of the project could wind up filing proprietary bugs later. I think you're describing three categories Project Community, Project Creators who are not planning, who behave the same, and Project Creators who are planning, who use different types. (I split Project Creators into planning and non-planning to reconcile with your later statement The creators also work with [Public, Private (user), Private Security].) I don't think this is accurate, because some projects will use Proprietary and Embargoed regardless of whether they are planning. Perhaps you meant: * Project Creators use Public, Proprietary, and Embargoed for planning, and all available types when not planning. * Project Community uses Public, Private (user), Private Security Is that it? It seems to disagree with this next statement, which implies that creators do not create Private (user) or Private Security. Project, teams, and blueprints originate from the creators, so they can only be Public, Proprietary, and Embargoed It's certainly *possible* for a blueprint to be security-related. Similarly, it can contain private user data. I think the reason we exclude those information types from Specifications is because we don't think it's common enough to support. I don't think it's because they originate from planning creators. Also, we don't prevent non-creators from creating blueprints. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBYnvcACgkQ0F+nu1YWqI3TmwCfWd/3gOlLSM0+/GFnNHE+rh6O Ul0AnRkwbRiPY6jsfYizJ7N5UtcEyj9x =uNei -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] visibility vs. information_type for Products
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-09-18 10:44 AM, Curtis Hovey wrote: On 09/17/2012 04:35 PM, Deryck Hodge wrote: I'd like to use information_type for a few reasons. **Consistency with other parts of the code** It doesn't make sense to me to have different names for things that are basically the same concept in our code. it's simpler and more consistent to stick with information_type. Other devs who come along won't have to get their head around how visibility and information_type are related, even basically the same, yet somehow different. I am -0 with this. It disagrees with PersonVisibility. Do you want to replace PersonVisiblity with InformationType too. I don't really understand how private teams work. Is the idea that they have AccessPolicies, and then anyone with the right AccessPolicyGrant can see them? If so, it sounds like it would be a good fit. InformationType represents the content the content of an artefact. Projects and teams are not documents/parts. Right, but Milestones and Series, which will derive their InformationType from Project are parts. I agree that three of the enums do work with projects and teams, but two imply the project or team exists to create maleware or phishing scams. We will not except that. Projects and team might use a base class or subclass that only contains the three sensible enums. That's okay, it doesn't affect the database representation-- it's an int either way. Otherwise the db and applications needs constraints to ensure non-sense is not excepted. We need that anyway, e.g. for Specification. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBYoeUACgkQ0F+nu1YWqI2anACfYHaKtEt0/rW5FX+DQkb/UlFE hp4Anjs2qtV3B3AK731ACLBY2ACbRPrD =Qrpc -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] visibility vs. information_type for Products
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-09-18 12:32 PM, Curtis Hovey wrote: I don't understand this distinction. It seems like creator actually means owner or planner, since people who had no role in the creation of the project could wind up filing proprietary bugs later. I use creator because Launchpad owner, maintainer, driver, and shared organisation do not properly encompass the case where Canonical owned projects are proprietary. Our organisation delegates the responsibility to deliver or maintainer the project to many people. People in these project roles are the core people who clearly are creators of features. The people the project shares with are also placed in the role of creators, though they rarely will make use of it. Okay, I think I was confused because I thought we were talking about all projects and you were talking about projects that want to be proprietary. I think you're describing three categories Project Community, Project Creators who are not planning, who behave the same, and Project Creators who are planning, who use different types. (I split Project Creators into planning and non-planning to reconcile with your later statement The creators also work with [Public, Private (user), Private Security].) This case has never been demonstrated to be true in Launchpad's data, but we do recognise it can happen. We called YAGNI on the case. Oh, I thought it would happen on publicly-seen, privately-developed projects like the Ubuntu One server. For example, of the project that want to be proprietary, only 1 bug was every filed as a Private Security bug in 6 years. It was a mistake. Proprietary projects treat use other projects (via information bug linking) to manage Private Security and Private (user) bugs. Oh, so I misunderstood you. While The creators also work with [Public, Private (user), Private Security]., you're saying the data shows they never intentionally *create* them in proprietary-wanting projects. It's certainly *possible* for a blueprint to be security-related. Similarly, it can contain private user data. I think the reason we exclude those information types from Specifications is because we don't think it's common enough to support. I don't think it's because they originate from planning creators. Also, we don't prevent non-creators from creating blueprints. Not so, the blueprint can be edited to remove the personal information about a user. This is also true of bugs. We commonly file apprort bugs as private (user) and then clean them up later, so I don't see how it demonstrates that a blueprint *cannot* contain private user data. Maybe the distinction you see is that some bugs *must* contain user data? Anyhow, perhaps not common enough to support and originate from the creators are two side of the same coin if we include and the data shows creators never do this. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBYqUAACgkQ0F+nu1YWqI2dHACcD0IYl9iydHcfy6gKQUVnHEFs 6ckAnRn9vD4Can7wjRoUz1s9lxPDeYam =fQeV -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] visibility vs. information_type for Products
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-09-18 12:36 PM, Curtis Hovey wrote: On 09/18/2012 12:31 PM, Aaron Bentley wrote: I don't really understand how private teams work. Is the idea that they have AccessPolicies, and then anyone with the right AccessPolicyGrant can see them? If so, it sounds like it would be a good fit. They do not have any form of access policy. But given that Swift and product strategy created teams that they wanted to become public, I think we do want to solve this case. OEM/HWE does not need it though. Okay, I was confused by the accesspolicy.person column, but on IRC you explained that's unused. I think an AccessArtifactGrant might be the right approach. If we don't use access policies, then the PRIVATE/EMBARGOED distinction affects display, but does not affect who can see the team. (PUBLIC means all, PRIVATE/EMBARGOED means only grantees.) Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBYqwEACgkQ0F+nu1YWqI3J6gCfZjQOKV3kbrE/+0GwjLtZ5+Di qSUAn2j6982jWSwKFd+SNBZUoQYRYIUP =z/mN -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] InformationType 404 vs 403
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-09-18 01:17 PM, Curtis Hovey wrote: I want 403 to be returned for Private (user) bugs and maybe Private Security. I want 404 to be returned for Proprietary and Embargoed things because it is only these types that Lp offers (and can enforce) the non-existence policy. +1 Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBYusIACgkQ0F+nu1YWqI2mJwCeLYQ51b6UvBwNIiVsXRXHaHjI I5EAnRqyNzv3EZe67WXpBtz6wANfAQh+ =aX/C -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] Private Projects LEP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-07-30 03:10 PM, Robert Collins wrote: On Tue, Jul 31, 2012 at 6:26 AM, Aaron Bentley aa...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-07-30 10:01 AM, Matthew Revell wrote: https://dev.launchpad.net/LEP/PrivateProjects An untrusted user cannot guess the name of a private project based on the error message given when trying to register a new project with the same name. How do we accomplish this? One way would be to document that we blacklist names, and make the error when a name is blacklisted identical to the error when the name is already taken. We could certainly blacklist 'canonical*', etc without raising suspicion. But would we blacklist arbitrary names in order to conceal the fact that some of those names belonged to private projects? Another would be to have projects namespaced under their owners, which is the approach github has taken, and that neatly resolves a bunch of issues around namespace ownership - but raises as many as it solves when you consider our goal around consolidating upstream communities - bridging the gap. But surely, private projects don't want to participate in upstream communities? Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAW6U8ACgkQ0F+nu1YWqI1TKQCfQ9lmHB6n4zVXS2JaLsXrLgPG 1iAAoIYDI/g/qfjrxUzgQ/JKb+70fdaZ =DZ/E -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] Private Projects LEP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-07-30 04:22 PM, Robert Collins wrote: On Tue, Jul 31, 2012 at 8:06 AM, Aaron Bentley aa...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-07-30 03:10 PM, Robert Collins wrote: error when a name is blacklisted identical to the error when the name is already taken. We could certainly blacklist 'canonical*', etc without raising suspicion. But would we blacklist arbitrary names in order to conceal the fact that some of those names belonged to private projects? I don't think we need to - we don't need to publish the blacklist. I guess my point is that if we use a blacklist, it needs to be credible. Users must think that if Launchpad denies them a name, the blacklist is a likely cause. Given that users will encounter this error for arbitrary names, the blacklist is only a credible explanation if it contains arbitrary names. So presumably, we'd have to actually blacklist some arbitrary names to maintain credibility. Now, I suppose we could do a structured blacklist like $USERNAME-*, and only allow the named user to create projects with that name. We would then need to require private projects to follow that naming convention. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAW8qIACgkQ0F+nu1YWqI3C1gCeOL/1uB0J4uEA8RHYUWGFfuEf 3a0An28a/6JaM2RfMwFs5D8LVUFpurJX =Qacr -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] RFC: Should we keep the logical operators |!- as full text search operators?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-07-17 11:38 AM, Abel Deuring wrote: I see two options to fix this bug: (A) We can either fix the immediate problem (the fix would be quite simple) and keep the feature treat the characters '|!' as logical operators in full text searches. (B) Let ftq() simply remove |! from queries. Why not (C) leave |! in the queries, but treat them as text instead of booleans operators? Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAFmdAACgkQ0F+nu1YWqI3QuQCfRLYO7CWMkuKhddZ7DNm8/Y0D QkIAn0/DXNu4cvsMFZqTgy6ftEAVlZ0V =K3u5 -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] Who can create private bugs and branches?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-07-02 11:59 AM, Curtis Hovey wrote: Maybe sending an email to the branch owner when we discover the staking is insane. I don't understand the context of this. If you think we can easily prevent stacking issues with a change, please explain. The way I read the code, we're already handling this in codehosting, by not providing a control directory (and default stacking branch) if the user is not permitted to access the development focus: lib/lp/code/xmlrpc/codehosting.py: class CodehostingAPI(LaunchpadXMLRPCView): ... def _serializeControlDirectory(self, requester, product_path, trailing_path): ... try: path = branch_id_alias(default_branch) except Unauthorized: return -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/zF74ACgkQ0F+nu1YWqI0/hgCcDlMH/EREf0vac8Hb9J9HXaEA hYoAn3nmhDvzHP3QTaol8vFL17e/TGMt =Br3R -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] Yellow Squad Weekly Retrospective Minutes: June 22
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-06-22 05:12 PM, Gary Poster wrote: * benji: bzr negative ignore A neat trick that came in handy this week was that bzr supports a negative ignore, with a bang (!), like !pattern. This came in handy for him when he wanted to assert that everything inside a log directory should be ignored except a README. Why do you want to assert that a README isn't ignored? Shouldn't you add the README? Once you add it, it's not ignored anyway. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/oc70ACgkQ0F+nu1YWqI1tCgCePKqqI3hN2JiZC4DY6UTY381s iyAAnjZjjikdrlB6z2EFwOwgTPkxGOZT =22Yz -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] Yellow Squad Weekly Retrospective Minutes: June 22
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-06-25 03:43 PM, Benji York wrote: Ah! I didn't know that once added changes to the README wouldn't be ignored, so I thought the negative ignore was important. Good to know. Yes. In fact, ignoring only affects UI, and only affects unversioned[1] files. So essentially it controls the behaviour of add and commit --strict and the output of status and ignored. [1] An unversioned file is one whose changes are not tracked by Bazaar. ignored and unknown are sub-categories of unversioned. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/oxQ4ACgkQ0F+nu1YWqI3nagCfY8VSYm2G73P1VCYgMrzQq/Hc DZ0An2t2vIQdZ1pJQjgw0s2hCaZswr/I =fJmr -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] Yellow Squad Weekly Retrospective Minutes: June 22
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-06-25 04:26 PM, Benji York wrote: On Mon, Jun 25, 2012 at 4:07 PM, Aaron Bentley aa...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-06-25 03:43 PM, Benji York wrote: Ah! I didn't know that once added changes to the README wouldn't be ignored, so I thought the negative ignore was important. Good to know. Yes. In fact, ignoring only affects UI, and only affects unversioned[1] files. So essentially it controls the behaviour of add and commit --strict and the output of status and ignored. [1] An unversioned file is one whose changes are not tracked by Bazaar. ignored and unknown are sub-categories of unversioned. Thanks for the info. So, negative ignores are useful when you want to be sure you see a file listed as unknown when that file normally does not exist and who's existence would otherwise be masked by the active .bzrignore. Right? Right. If so, that seems like a narrow use case. I tend to agree, but the rationale was given in https://bugs.launchpad.net/bzr/+bug/428031 and a discussion: http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/61638 But good bzr trivia. Is there a geek pub game company we can submit this to? ;) :-) Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/oztEACgkQ0F+nu1YWqI36jwCeLrA67/zBybaz7AaHY8cHsbIg ADwAn35GudkO6c9fzN3EqYQ8/c3eGIvG =OpfA -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] Yellow squad checklist thoughts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-06-18 08:23 AM, Jonathan Lange wrote: [1] ISTR, Drive and other bits of research that show that incentives often backfire, as people would often rather cop the punishment or do without the reward than do the actual thing. As seen in http://chrishecker.com/Achievements_Considered_Harmful%3F : For interesting tasks, 1. Tangible, expected, contingent rewards reduce free-choice intrinsic motivation, and 2. Verbal, unexpected, informational feedback, increases free-choice and self-reported intrinsic motivation. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/fQK4ACgkQ0F+nu1YWqI1dpQCeKoo9+3u0n5TLM8u4LAyo+fl2 UQwAoIWk37ohnFZjOQfWAzYIPqanrGPg =v7fS -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] Yellow retrospective meeting notes 2012-06-01
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-06-01 01:54 PM, Gary Poster wrote: (We then discussed lightweight branches and colocated branches to make sure everyone knew what they were and how to use them.) What do you mean by lightweight branch? Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/MuiIACgkQ0F+nu1YWqI1MMwCeOTGwz6YqjOSSW1lMDpyHFtPv q44An1GynzIzfIWPyQ+M7skkqGSkUvkI =R/oL -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] What is the state of celery in production?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-05-24 11:27 AM, Francis J. Lacoste wrote: The deployment of celery to production is now blocked because celery keeps long transaction open. https://bugs.launchpad.net/launchpad/+bug/1003720 Since this is only celerybeat, it would be possible to deploy the main celeryd, and deploy celerybeat afterward. But I expect to be resolving this issue this afternoon, so that we can do it all at once. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk++VGwACgkQ0F+nu1YWqI259ACeIHR7k7ZkMJGe87ue/091dTPE aWAAnRzqkhYg8hnmSxwqprliJVP1BCbA =1eOd -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] What is the state of celery in production?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-05-22 08:09 PM, Ian Booth wrote: I haven't landed any of my branches which introduce the new Celery jobs yet since I am waiting for Celery to be ready. Only job classes that are mentioned in the jobs.celery.enabled_classes feature flag will be run, so it is safe to land your code. I think my basic implementation is ok based on the CeleryJobs wiki page and have unit tests using the CeleryLayer which seem to confirm this. But I am unsure what, if anything, I need to do with respect to error handling, retry on failure etc. Perhaps that is all done as part of the Celery framework? But then again, how would the framework know the difference between a fatal error that means the job must be aborted vs a transient error where the job can be retried. Are there any expected classes of exceptions one should raise in the run method which the framework relies on to determine how it should handle failure? Do I need to do anything to account for the job runner aborting half way through a job - will the job be automatically rerun? The jobs code checks the retry_error_types member of your BaseRunnableJob subclass, and if the exception matches one of those classes, it retries the job until it hits max_retries. If it hits max_retries, it allows the exception to propagate. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+87bEACgkQ0F+nu1YWqI1ojwCbBDL5mikECmq9p6rAWOtbz1VW NwgAmwUuHbtfPtdVj5BlM8M319q6V/aL =25ux -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] What is the state of celery in production?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-05-23 07:21 PM, Ian Booth wrote: On 24/05/12 00:01, Aaron Bentley wrote: Only job classes that are mentioned in the jobs.celery.enabled_classes feature flag will be run, so it is safe to land your code. Except that I haven't configured my new jobs to run via the normal job runner so they will just queue up. I suppose you could use lp.services.job.runner.celery_enabled to prevent your job from queueing up if they're not enabled to run via Celery. I may have to relent and configure my jobs to run via the normal job runner until Celery is ready on production. You are definitely on the bleeding edge, given that we haven't got Celery running jobs on production yet. I do hope we'll be ready soon. If you do want to run jobs via Cron, consider the run_jobs script. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+9wDcACgkQ0F+nu1YWqI25xwCfV54ew3Gl+36rrT/Wvka4o9Oh hrYAnR1+4f8IihhR8v4g1hM1h//YyDla =XSPO -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] LEP: Improve our Launchpad setup scripts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-05-21 03:09 PM, Francesco Banconi wrote: Any feedback and suggestions are appreciated. I like it. The Support all the customized environments that can possibly be used by Launchpad developers (i.e. lightweight checkouts). is a bit hyperbolic. It would be better to say what you *will* support. Personally, I think the default set-up should be bzr's native colocated branches. This basically removes the need for a rocketful-branch script, since you can just use bzr switch -b. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+7p3IACgkQ0F+nu1YWqI1fOQCdHBZKWlrSB92DaeeTIoSwOFjE gXsAn3RLDmXsuwhE1XLFdhuhjHfog4TE =vq4A -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] LEP: Improve our Launchpad setup scripts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-05-22 12:48 PM, Francesco Banconi wrote: On 05/22/2012 04:49 PM, Aaron Bentley wrote: AFAICT, having the set up described above, the developer can freely choose what to use: normal branches or co-located ones. We are trying to at least support, and hopefully improve, all the features already present in the rocketfuel-* scripts (e.g. rocketfuel-branch). Great. I got a very wrong impression then. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+7ys4ACgkQ0F+nu1YWqI3O+ACff/ToS+yzvxh+XKmnXrmb+hFg MlkAn39jmDvczGCM+7u21CZX78a5uwN4 =6LK5 -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] What is the state of celery in production?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-05-22 01:16 PM, curtis Hovey wrote: Hi rocket scientists. The purple squad wants to land our last branches needs to sync subscriptions to sharing. This is a celery job. Is celery ready in production? If not what do we need to do to get this ready so that we can put sharing into beta? As of Abel's report this morning, we have everything running on staging/qastaging, and he's testing it. What remains is to implement that slow lane in production, so that when jobs take too long and fail over into the slow lane, they are run. Also we have some apprehension that something might be missing from our implementation of RemoveSubscriptionsJobSource. Can someone take a look at the pieces and tell us if something is missing that is needed to run in production. I can't find anything by that name in r15284 Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+724sACgkQ0F+nu1YWqI1PDgCfW5Sxsk+aJURpbRQEtGckIjDQ +QEAn0ITWElGIAX0b3n3K0aPtEzVeRp3 =/iIm -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] Feature flag images
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-05-14 02:09 AM, Huw Wilkins wrote: I recently tried to feature flag images. My approach was that I would have images with the same name inside a sub-directory to the images folder, which would be named after the feature flag. How were you using the feature flag? Were you using it in a template, or by querying it via Javascript, or checking it in Python? I ran into a problem where the local development server would expose the root image folder but none of its sub-directories. It looks like this is fine in production however. This doesn't sound like a general problem, because feature flags don't directly affect images. If we understand your implementation better, we can probably suggest solutions. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+xCGwACgkQ0F+nu1YWqI0IygCfRMyd7Ju74HzWhxCTdLDmvpD/ X7cAnA0tG7Sk/+30auxA/UULvh67PMb2 =b9Rs -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] Next steps for Better Privacy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-05-08 01:38 AM, William Grant wrote: - Port the few remaining search queries to the new schema + Design and implement BugSummary v2 [wgrant] + Replace miscellaneous bits around the codebase [wgrant] - Introduce facilities for reconciliation of illegal subscriptions + Add job to remove illegal subscriptions on unsharing [wallyworld] + Add job to remove illegal subscriptions on membership revocation + Add daily cron (garbo?) job to detect missed illegal subscriptions Since the Jobs are being designed to run via celery, it may make sense to use celerybeat to schedule a missed-illegal-subscriptions job. - Teach Bug to maintain AccessArtifactGrant + Extend Bug.subscribe() to share if necessary + Extend Bug.unsubscribe() to unshare if there's an artifact grant for the subscriber Is there a risk that the artifact grant existed before the subscription, and so unsharing might cause a surprising removal of access? Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+pG/4ACgkQ0F+nu1YWqI38wQCeIpIzjNIerJ+m/Wgdn0npEs4D WOgAnRKv+lRQSwWNuI9xi6Ow54hGZWmN =eOBs -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] Is CopyArchiveJob in use?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-04-26 09:53 PM, Julian Edwards wrote: We have Celery deployed on production (ackee) now. Running garbo tasks via Celery is probably simple, but we have been focusing on jobs which provide the IRunnableJob interface, so I don't think our work is directly applicable. I'm quite excited to see an off the shelf solution being used to run our jobs. Have you documented its use in LP anywhere on the dev wiki? It's a bit more of a challenge keeping up with LP developments while we've been working on MAAS! I've started work on this: https://dev.launchpad.net/CeleryJobs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+ioacACgkQ0F+nu1YWqI0lWwCfakQNtp7cmXaC09XuDCnd4a7C QJsAn0HTpGl47MlytUwX0esxZtaPMTH5 =AHpz -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] remove subscriptions job part 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-05-01 01:29 PM, curtis Hovey wrote: When I wrote jobs in the past, the job ran as a celebrity, such as the janitor, which is given permission to complete the task for the user. I think some security checkers continue to use celebrities for translations and registry process. I do not know if celery is running as the proxy celebrity or as the user that initiated the change. Most launchpad scripts actually ignore user-based security entirely. They initialize with scripts.execute_zcml_for_scripts(use_web_security=False) The Celery job runner does the same. It does not explicitly set a current user. (It does set the current dbuser, which varies by job type.) Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+gM2oACgkQ0F+nu1YWqI3dggCghEd7VUF85Ynk5kfI5HQmg5hY /3gAn2WOnOHefBvffQDO+GflvcovwHDk =oTfK -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] Is CopyArchiveJob in use?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-04-24 09:40 PM, Julian Edwards wrote: On Tuesday 24 Apr 2012 09:21:55 Aaron Bentley wrote: I think that BFJs could *become* Jobs, but that's a task for another time, if we decide we want that. I want the exact opposite, they are totally unlike Jobs and have caused no end of pain trying to integrate them as such. Maybe sometime we can have a chat about that, because it's hard for me to see how they could be totally unlike Jobs. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+X+QYACgkQ0F+nu1YWqI3gYgCfTGbDykR2NGUWEyOQgS3X0o+p hU8AnjaBlQXc1KGQBLbSN5fNXI4lkF6+ =2hiC -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] Is CopyArchiveJob in use?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-04-23 10:52 PM, Julian Edwards wrote: On Monday 23 April 2012 14:25:22 Aaron Bentley wrote: I'm working to convert all Jobs so they can run under Celery (not including build farm jobs). Good, we need to remove all trace of Job from BFJs. They are not Jobs and it was a mistake to use the Job code originally. To clarify, I'm not planning to do anything to BFJs. They will still share the code with Jobs that they shared before I began (which is mostly model definition and some state transition rules). I think that BFJs could *become* Jobs, but that's a task for another time, if we decide we want that. I started to convert CopyArchiveJob, but it appears to be unused...Is this code in use? I don't think it is. The PackageCopyJob stuff has superseded it, so feel free to rip it out. Thanks! Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+WqPMACgkQ0F+nu1YWqI1UJQCZAaoPRvOX46sSu4pMWH2NRFy9 +hsAn2NZM3WlnCnPCTB24r8Qn2E40v/9 =LLue -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
[Launchpad-dev] Is CopyArchiveJob in use?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm working to convert all Jobs so they can run under Celery (not including build farm jobs). I started to convert CopyArchiveJob, but it appears to be unused; it does not have a script, it's not mentioned in the process-job-source-groups, and it does not have a config section. It appears the last serious work done on it was in 2010. Is this code in use? Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+VnpIACgkQ0F+nu1YWqI3Y5ACeNUMPvXMYwk4JC7TdaDQcUFil Be8AnjdndpB2xWq5RBBz2sHvecPHl3Ix =apKe -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] Help please - launchpadlib collections
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-04-12 10:50 PM, Ian Booth wrote: On 12-04-12 06:18 PM, Ian Booth wrote: dir(lp) will list the services for sure, but also everything else as well. Having the top level collection 'services' provides a namespace of sorts which I think is necessary. Could you explain why you think it's necessary? So far, I thought you were saying that discoverability is nice-to-have. It is a nice to have and is not strictly necessary now when there's only one service. But later when there are more, I think it will become more important. As an extreme example, we wouldn't want to do away with the distributions collection and have all the distros as top level entries. I see no difference between that and services. That's my opinion based on past experience anyway. The difference I see is that all distributions provide a common api, and so writing code that works with a particular distribution does not require foreknowledge of that particular distribution. It is plausible to write functionality that works on any (or every) member of a distribution. Services will all be different, both in signatures and in semantics. Writing code that uses a service requires foreknowledge of that particular service, because 1. Without knowing what it does, you don't know that you want to use it 2. Without knowing its method signatures, you can't use it I agree that having a namespace for services would be useful, but I think using a collection to provide that namespace would be misleading. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IOggACgkQ0F+nu1YWqI3nMACfdKJ7M780EfdtfhnGMc7oSsZd mQIAnimvf4YKeYuX+szqmy67AGoWpLiH =9aSj -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] Help please - launchpadlib collections
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-04-11 09:17 PM, Ian Booth wrote: Plus, it is possible to iterate over the named services and see what's there, what service interfaces are implemented, what methods are available etc. ie a classic discoverability pattern. But this is also true of the lp.servicefoo approach. dir(lp) will list them, getattr can retrieve them. So I don't think the discoverability/iteration argument is a strong one. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+G54IACgkQ0F+nu1YWqI3mngCaA1gh/VcQDcWsAJjHARPlbZNM ZnsAnRBkzz52c8hdud6GJQm0ho39LiXP =w1tU -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] imperatives in bugs considered harmful - even for short lived workitems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-04-10 05:43 AM, Robert Collins wrote: A while ago I made the observation (I don't think it was original) that bugs with imperatives in their title/description are poor bug reports. The sense of entitlement sometimes implied by imperatives can be irritating, but the imperative itself is not the problem. Most imperatives can be rephrased without changing their meaning. For example, Foo should bar can be rephrased as Foo does not bar. The should is implied in the latter phrasing, but the meaning is essentially unchanged. So I think imperatives are only a hint that the bug is suboptimal. In recent months, I've seen a lot of the workitem style bugs which are very opaque, and presume that the very detailed workitem is a) comprehensible and b) the right way forward. I propose a personal experiment: please take the same care in filing a workitem bug as you would documenting a system limitation or defect in the current implementation. There are two places where we could describe a work item: the merge proposal or the bug. I think the merge proposal is preferable: - not all work items need bugs - merge proposals are mandatory and should describe the work well - merge proposals are associated with the revision that merged the work, not just with the branch. I think that saying see merge proposal baz in a work item bug would reduce the opacity of such bugs without adding undue work. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+HLc4ACgkQ0F+nu1YWqI2e0wCfecU72AYUhfQm6BLnHvuMUSEQ GzAAn1AaOYtu+6GqivSnBy/YHac7gAqc =s3Lk -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] Help please - launchpadlib collections
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-04-12 06:18 PM, Ian Booth wrote: dir(lp) will list the services for sure, but also everything else as well. Having the top level collection 'services' provides a namespace of sorts which I think is necessary. Could you explain why you think it's necessary? So far, I thought you were saying that discoverability is nice-to-have. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+HbXsACgkQ0F+nu1YWqI21IgCfVJ/8oPfU8Vj+gnRtSiwpuDn+ cW0AnikyMI3DyaihDu2X9q/IuMrHX3df =wfjj -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] Introduction to and Minutes of yellow squad's weekly postmortem call: 2012-03-30
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-03-30 11:17 AM, Gary Poster wrote: * Suggested process change: never patch eggs; fork branches if you must, and make eggs from them. I thought that this was already our policy: https://dev.launchpad.net/PolicyForDocumentingCustomDistributions Implied by: The first [comment line] should indicate the location of the sourcecode (trunk or branch or tag), that was used to create the distribution Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk912HoACgkQ0F+nu1YWqI06dACdHcxfaJ28/KV+j7aGzGnvNPXs dSUAnjb6tvTnu61PJ4zyv3wY0GaNWXJO =i+9f -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] memcache errors in ec2 and buildbot -- newer python-memcached to blame?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-03-23 06:20 AM, Stuart Bishop wrote: On Fri, Mar 23, 2012 at 3:57 PM, William Grant william.gr...@canonical.com wrote: python-memcached was upgraded a week ago, so it's tempting to revert it to see if it makes things more stable. What do people think? The old one was very simple. Anyone recall why we upgraded it? I believe it was to fix this bug: https://bugs.launchpad.net/launchpad/+bug/954232 Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9secQACgkQ0F+nu1YWqI2LiACfa+v33jP43Hm9tXlp8NT9lZZU LlcAniNdhj8vJvgyGo2W+wwKoeaPcjJK =+Afn -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] ec2 scripts moving to lp-dev-utils
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, This change has now landed in stable and devel. To use the version of ec2 in lp-dev-utils, you'll need an up-to-date bzr-pqm (which I've placed in the Launchpad PPA), and possibly the python-tz package. Please let me know if you encounter any difficulties. Bugs should now be filed against lp-dev-utils, rather than launchpad. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9aTlAACgkQ0F+nu1YWqI2mswCfQHq4zeRaOeyjgiqwa06qM7Sa wHkAniohbQf6Q+aap5F6ap0VVm7Md6Yt =vWxa -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] New services infrastructure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12-03-01 02:43 AM, Ian Booth wrote:
Our standard lazr.restful library is used, but we are not
attaching service methods to domain objects which I believe is the
wrong approach.
+1
2. launchpadlib api
from launchpadlib.launchpad import Launchpad lp =
Launchpad.login_with('testing', version='devel') # Launchpadlib
can't do relative url's service = self.launchpad.load(
'%s/+services/accesspolicy' % self.launchpad._root_uri)
service.addPillarObserver()
I hope that eventually, we'll be able to access this more cleanly.
Say, as self.launchpad.services.accesspolicy
Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9Pk4cACgkQ0F+nu1YWqI0VpwCfa2DX/PaGK3ijxq7oTf+2W6t+
cLMAni1m5IZvz0u4dN46d4K9IuJi9f81
=FwYy
-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
[Launchpad-dev] ec2 scripts moving to lp-dev-utils
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, The ec2 script doesn't need to be part of the Launchpad tree. It doesn't use Launchpad code, and it depends bzr-pqm, which is a plugin that Launchpad doesn't provide. It's also not necessary for developing Launchpad (though I believe I'm the only one not using it on a regular basis). Therefore, I'm moving it to lp-dev-tools. It is, after all, a tool for Launchpad developers. This deletes ~6000 lines from the launchpad tree. I've landed it in lp-dev-tools already, but I won't delete it from the Launchpad tree until we've made it easy to switch. If you want to be an early adopter, you'll need the latest bzr-pqm (r88), which you can get via bzr branch lp:bzr-pqm ~/.bazaar/plugins/pqm. You'll also need the python-tz package, which you can apt-get install. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9P81cACgkQ0F+nu1YWqI0xjQCfaleEnNgVr3gZ3ovMtukDX1FN z+EAoIKOWZ+SEtTNMXvgo5FBjqeyKEFv =uBvK -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] server side rendering, client side rendering, forms, oh my.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-02-21 06:11 PM, Robert Collins wrote: On Wed, Feb 22, 2012 at 12:04 PM, Aaron Bentley aa...@canonical.com wrote: But it only doubles the page size when we use server-side rendering. Clients can get the JSONCache via ++model++ urls. indeed, but if they are going to request it separately, there isn't a functional difference vs the API (subject to making good API calls that fit the problem space :)) - or am I missing something? The JSONCache is meant to be page-specific. I think there's a risk that if we use the API in place of it, we'll wind up with a bunch of page-specific API methods that aren't useful to other clients. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9HlZQACgkQ0F+nu1YWqI2niACghVIS6CnUkn+9+F45JiLkbW+y 6zkAn0HE+AmehGPaH0ZKhRcBufm1BxHl =Bthk -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] server side rendering, client side rendering, forms, oh my.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-02-20 11:55 PM, Robert Collins wrote: So, going back at least 18 months, maybe more, there has been a long slow-running conversation amongst us about what we render were, with different projects choosing different answers. I think we have enough data now, that we can consolidate on a good default answer and ask that everyone pick that answers *by default* with variation needing to be experiments - explicit decisions to learn something new. tl;dr: lets: * render searchable content on server side and client side using a common template language * render the forms needed to file a bug server side and optionally client side * render all other forms exclusively client side and have them communicate exclusively via the API I think that this approach makes sense. The current API is not roundtrip-efficient for multiple-item listings, but forms are usually related to a small number of items, so this should not be a problem. You didn't specify that the API must be used when rendering searchable content on the client side. The JSONCache is roundtrip-efficient for this purpose, and can also deliver identical data to client-side and server-side templates, so I think we should prefer it for now. If we want to use the API for client-side rendering of things like bug and branch listings, I think we will need to change the API to make it roundtrip-efficient, and find a way to ensure that identical data is presented to client-side and server-side renderers. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9DzacACgkQ0F+nu1YWqI01IQCfUMoSD418g1z+ZYcno2gczYDw dGkAnj7KwsKfJdxk9gZxmcLDBHTwpkme =nXUt -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] server side rendering, client side rendering, forms, oh my.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-02-21 04:42 PM, Robert Collins wrote: So, the API is *capable* of being round trip efficient for any use we would make of it in a web page. Some of our 'magic' glue however will be in the way and in the short term is best avoided. E.g. a collection of nested dicts can be trivially returned by an API call; a collection of Bug objects will return only the Bug object representations themselves. We may be in violent agreement. You are suggesting we should add new API calls that return the specific collection of objects we need for the web page, in order to be efficient? That sounds okay, but it does sound like a change. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9EE0sACgkQ0F+nu1YWqI1YEACfeYJm2G6rzrgaxFk+ACFe7R/h pJwAn1D2Ug8p8MuNTFWYx1bT2qdGnW4S =xcPk -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] server side rendering, client side rendering, forms, oh my.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-02-21 05:05 PM, Robert Collins wrote: Lists of content such as lp.net/bzr/2.0 have a bunch of different data to assemble, *and* we want server rendering for Google. That means we need a View class, and we will have the data locally so shoving it into the LP JSONCache is a simple and effective means of handing it off to the client. That said, its also a waste: we have already rendered the content at that point (because we want to show it to Google) so we may as well just hand over the rendered HTML (or browser-sniff and render exclusively on the client for non-search-bots). Transmitting the same data twice is a waste though; I am strongly in favour of rendering directly on the client all the time. It is desirable to do so because of things like the cog on the bug listings view that lets additional data not rendered by default be added to the view - we need all the data which the initial server rendered output wouldn't necessarily include (unless we change how we tackle it and hide content using css classes rather than template output - one constant render, client side visibility choices). I'm in favour of dropping server-side rendering for sessions when client-side rendering is supported. Is that what you mean? And in fact, it looks like hiding content would have been a better option for bug listings, because that can be done more smoothly in Firefox. we can always fall back to the JSONCache, for all that it does (roughly) double the page size. But it only doubles the page size when we use server-side rendering. Clients can get the JSONCache via ++model++ urls. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9EIwwACgkQ0F+nu1YWqI2GgACeNLGYN4RcJKXBF4qE6esAOU4p LDcAmwZ+XSSIU8WS9SydGo6x/T3aiFv5 =7Yi7 -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] Feature Request: Like/Dislike Buttons
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-02-15 07:09 AM, Laura Czajkowski wrote: I came across a question today on launchpad Questions that I thought would get a better discussion on here first before I or anyone else replies to it. The question is could like/dislike buttons be added on bugs which would would encourage more interaction and also like many other sites nowadays have a +1 to comments https://answers.launchpad.net/launchpad/+question/187822 Feature requests should be reported as bugs, which also increases their visibility. That said, while adding a +1 button to comments seems fine, adding a feature like that doesn't seem to match our current focus on reducing maintenance costs. If the request were to add it to bugs themselves, it would also overlap with Does this bug affect you?. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk88H60ACgkQ0F+nu1YWqI3hMwCggPyfPSS1n6a/YBVZXxcIBWut skYAni39PfPee7G8pYzL6pyqkRfbe2OH =Xcsh -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] Plan to migrate Blueprint work items from whiteboards
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-02-08 07:57 PM, Robert Collins wrote: - move most of utilities/* to the lpdevtools project - thats 6K LOC on its own If our goal is to reduce maintenance costs, how does moving code from Launchpad to lpdevtools accomplish that? Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8z1OkACgkQ0F+nu1YWqI0NVwCcD/9j1u+oB81E3FLCYkb2VmD9 6uQAnjxoeXENEYXobskm1pmIA3wiJl92 =EP3B -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] proposed policy: maintenance costs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-02-09 12:37 PM, Robert Collins wrote: I think in-kind cost trading is a no-brainer, but hard to do (how well can we predict future support costs :(). So if in-kind cost trading is hard to do, other kinds of trades are very hard indeed. Allowing other kinds of trades is conceptually important though - otherwise making landings cheaper by writing code wouldn't be able to be done! True, but you could simultaneously remove code in a way that made landings harder (but not quite as hard as before) :-) Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk80BfIACgkQ0F+nu1YWqI02bgCfY3xiDTi+eSWvB6uGj5Pj8fON oqAAn2fTOqgNlW7zOiDGoBNwTF6Lkup1 =eAVm -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] proposed policy: maintenance costs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-02-09 12:35 PM, Robert Collins wrote: There are certainly instances where increased modularity will increase LoC. When a short function is extracted, and it only has a few call sites, a LoC increase is likely, if only from additional documentation. As the number of call sites or the length of the function increases, the LoC will tend to decrease. An interesting question (without a satisfactory answer I think) is then whether the modularity is worth it. It can be tough :) That said, I would tend to go for extracted functions even with only 2 call sites, most of the time. Me too, but it's certainly possible to be fooled about the parameters of a solution with only two instances of a problem. With a third instance, I feel very comfortable that a solution is generalized in a useful way. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk80Br4ACgkQ0F+nu1YWqI3itQCcDQOudjVpXslBFlOKxqc8913N GlwAnAypimWsuW6EDOppW4Pye7fzStE6 =8/70 -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] proposed policy: maintenance costs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-01-31 10:32 PM, Robert Collins wrote: Hi, please glance at https://dev.launchpad.net/PolicyAndProcess/MaintenanceCosts One thing I find difficult about the policy is that it's hard to compare the different kinds of costs. How many lines of code should I remove to justify increasing the number of support tickets by 5 per month? Maybe we should recommend in-kind cost trading, so an increase of 5 tickets per month would be offset by reducing tickets per month elsewhere, rather than by removing code, making landings easier, automatic operational tasks, etc. Also, there's a lot of duplication in the increase and decrease lists. Maybe just one list of things that are costly? Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8xNKAACgkQ0F+nu1YWqI357gCfbyCRIKfU/1WoJqUMdw5hN9N1 Cx4An3TzOL09fR6GBa4IeOsAXalHbn1X =SWY2 -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] proposed policy: maintenance costs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-02-07 09:19 AM, Jonathan Lange wrote: sloccount is overkill, surely? Couldn't you just (get a computer to) count the pluses and minuses in the diff? We include that information in merge proposals, e.g. Diff against target: 268 lines (+259/-0) 2 files modified. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8xOtYACgkQ0F+nu1YWqI3epgCeIfEJ1fYYzcIWX4cXiED7SF/y 6/AAn1KhRui3tdKQwsecmervbA8tFKU7 =F8A4 -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] Update - running Launchpad tests on canonistack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-02-03 04:30 AM, Ian Booth wrote: I've been doing a bit of investigation on running the Launchpad test suite in a canonistack instance. Andrew Glen-Young has been awesome in helping me get access to an instance to work with - thanks. lp.archivepublisher.tests.test_ftparchive.TestFTPArchive.test_generateConfig lp.archiveuploader.tests.test_uploadprocessor.TestUploadProcessor.testLZMADebUpload lp.services.mailman.tests.test_mlist_sync.TestMListSync.test_staging_sync lp.services.mailman.tests.test_mlist_sync.TestMListSync.test_staging_sync_list_without_team lp.services.mailman.tests.test_mlist_sync.TestMListSync.test_staging_sync_with_team_address Total: 17029 tests, 5 failures, 0 errors in 210 minutes 43.985 seconds. At last, I'm not the only one seeing these! I've been meaning to look into them, but it got back-burnered during the dynamic bug listings work. I hacked together 3 scripts, based on snippets extracted from various bits of our python stuff used to configure ec2: rootsetup.sh (run as root) setup.sh databasesetup.sh This sounds quite a lot like the scripts test farm uses to configure a Launchpad instance. Have you had a look at it? bzr+ssh://bazaar.launchpad.net/~abentley/+junk/test-farm/ The above are bash scripts - I find these easier to write and debug rather than how our ec2 stuff is written by creating a connection and shoving bash commands down the pipe to be executed. I scp'ed these scripts to the blank instance and ran them. I could have also used sftp. You can also use cloud-init to perform the install. Or juju, I imagine. test-farm used clould-init to do post-init customization. You can just supply a script as --user-data-file to the euca-run-instances command. I wonder if we can reuse ec2-land more directly, though? Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8sCSkACgkQ0F+nu1YWqI3QrgCdGsgJbgXWsvgR6wwl2shqJzGd 7hwAn1eUhk7UoErjG7IcqEqIxcLAEU60 =986l -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] Update - running Launchpad tests on canonistack
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12-02-03 11:30 AM, Gary Poster wrote:
This sounds quite a lot like the scripts test farm uses to
configure a Launchpad instance. Have you had a look at it?
bzr+ssh://bazaar.launchpad.net/~abentley/+junk/test-farm/
...and a bit like utilities/setuplxc and a bit like
utilities/rocketfuel-setup and friends. And like ec2, as
already mentioned.
Is there significant code-duplication between setuplxc and
rocketfuel-setup? I've always just used rocketfuel-setup
- --no-workspace and then implemented the workspace myself. I guess
that might not work for setuplxc.
(stupid-simple install-launchpad script attached.)
We were considering collapsing setuplxc and rocketfuel-setup at
least (not that everyone would have to use lxc, but the
duplicated bits between the two could be maintained together). I
suspect that these two are more like Ian's current scripts than
ec2, at least.
That makes plenty of sense. Maybe turn it into a real python script
with different invocations for different use cases?
...ec2 seems more like what I'd like canonistack setup to reuse,
though, myself. That's remote setup, while setuplxc and
rocketfuel-setup are about local setup. ec2, or maybe what Aaron
describes below.
Aside from actually spinning up instances, I'd hope that the way you
set up a remote instance is very close to the way you set up a local one.
Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8sJV8ACgkQ0F+nu1YWqI3fOACfdHtpvL9GIL8VlTzwjaKqO2vm
szQAnjJzuU3lupOfv22tff/pL2xk9Ulj
=9XgJ
-END PGP SIGNATURE-
#!/bin/sh
set -e
echo '127.0.0.1 ubuntu' | sudo tee -a /etc/hosts /dev/null
. /etc/lsb-release
sudo apt-add-repository deb http://archive.ubuntu.com/ubuntu/
${DISTRIB_CODENAME} multiverse
sudo apt-get install bzr --yes
bzr init-repo launchpad
bzr branch http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable
launchpad/stable
cd launchpad/stable
utilities/rocketfuel-setup --no-workspace
bzr branch http://bazaar.launchpad.net/~launchpad/lp-source-dependencies/trunk/
download-cache
utilities/update-sourcecode
utilities/launchpad-database-setup ubuntu
make schema
sudo make install
___
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] Update - running Launchpad tests on canonistack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-02-03 01:37 PM, Gary Poster wrote: That makes plenty of sense. Maybe turn it into a real python script with different invocations for different use cases? Yes, setuplxc is Python. So, yeah, my thought was to continue with the setuplxc direction. Rename it to setup (or rocketfuel-setup), and have it handle all three cases, eliminating the current rocketfuel-setup. Win. I can see where you are coming from. ec2 does control things from a distance, which was a design choice I made early on. Okay, that makes sense. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8sLFEACgkQ0F+nu1YWqI3RcgCdGsrZeCPIDuZ48N2ruWkrhGAS mOEAnj1dJou0SMTgRwjv6krTjvNENvNE =aFc9 -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] Plan to migrate Blueprint work items from whiteboards
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-02-03 02:28 PM, Guilherme Salgado wrote: 2. Expose at least a read-only API to get the work items of a Blueprint, including a way to get a text representation of all of them, using the standard format. (This is necessary so that we don't have to rewrite too much stuff in lp-work-items-tracker) If this is a specific formatting that is used on a web page, it might be nicer to expose this as part of the page's JSONRequestCache (the bit that shows up as LP.cache in the page). This representation can be requested as JSON using a ++model++ URL. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8sPKUACgkQ0F+nu1YWqI2iWQCfZXfE8mI/FEUhm+dKe88ys/ku CSUAnR8RJLOAixWvFawD4YUzt0EtJYkz =ikoI -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] 'stache, handlebars, tal and so forth
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-01-24 07:50 PM, Robert Collins wrote: we really need to consolidate our template languages somewhat, as part of streamlining LP and reducing maintenance surprises / learning curves. So, I propose that we take 'stache as the baseline *for now*: Mustache's main advantage as a templating language is that it is cross-platform. But both the Python and JavaScript versions need a lot of work. The JavaScript version, in particular, might need to be re-implemented along the same lines as Handlebars in order to fix its performance issues. And it's pretty clear that the implementations are not tested for interoperability-- I found obvious bugs on both sides. So if we make Mustache our main templating language, I think we'll be investing a lot in it. And I'm not sure it's a language we would otherwise choose to invest in-- the syntax is overloaded and weird. Maybe that effort would be better spent on writing a template language with saner syntax and guaranteed uniformity between implementations. As you say, the codebase is tiny, so implementing something comparable should not be a big job. In any case, I think it's a bad idea to use Mustache extensively on the python side until we're running a version that has https://github.com/defunkt/pystache/issues/8 fixed. The current release, 0.3.1, still suffers from it. - when touching a template consider migrating it across - and consider migrating templates as an itch-scratching exercise. If we're going to make a big commitment to a language, we should be confident that it's a language we want to be using. As a language, I think Mustache is worse than pretty much any other template language I've encountered. I would use it tactically, where no other template language is appropriate. I think this should be treated as an evolutionary step: if 'stache won't do the job, we need to find a different template language that will, while still being both server and client side available (to accelerate our migration to an API driven client side app). I don't think Mustache is particularly compatible with the web service API. It wants dumb objects, not Restful API wrappers. And it wants them organized in ways that the API does not support. The client-side and server side renderings of dynamic bug listings are identical because it *avoids* the web service API, and instead uses the JSONRequestCache on both sides. This allows Launchpad to generate the exact data that Mustache wants to consume. I believe this will be the winning technique whenever we want to support client-and-server-side rendering. If we move to client-only rendering, then it's possible we'd use the web service API, but we wouldn't have to use Mustache, either. Last resort, we could write one : but that is the last resort. Personally, I'd rather wait for something better than switch whole-hog to Mustache. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8gHtgACgkQ0F+nu1YWqI3DNgCfXHfGnxufgynwggseN+HyJrJ2 rCIAn1QqKJ1YXnALeGGCotq82rI7T43v =ZyMt -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] combo loader update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-01-22 11:59 PM, Ian Booth wrote: AttributeError: 'module' object has no attribute 'argv' Yes, it was claiming that module sys has no argv attribute. And sure enough, doing a print dir(sys) showed that argv is gone. WTF. I'd love to know what could possibly cause something to effectively execute what appears to be del sys.argv. I believe it's more a case of sys.argv having never existed in that context. This can happen when Python is loaded as an extension, IIRC. I tripped over this a few months ago, but the details are hazy. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAk8da3EACgkQ0F+nu1YWqI1jdgCVEw+POxOqyk2S1I9ZL5kd5l1r LQCeMNqGT1dSckFJISi8WlBp3s5NASI= =n0c3 -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] notifications - an implementation straw man (warning explicit discussion of services follows)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11-12-28 03:07 AM, Robert Collins wrote:
This won't be customised as it is today ('you have been requested
to review xxx') but it will have all the functional information to
let someone do the review, without duplicating the whole diff if
they are already subscribed (and thus it fixes a current bug).
A sufficiently smart template system could identify the
notification recipient as an actor in the event and replace
phrases; I think that is something we can live without for a bit,
and add in a future round: to me, the case for a single
notification service is extremely compelling even with these
tradeoffs.
I don't understand this bit. We already use a template system to
substitute these phrases. Why would we get rid of it and then create
a new one?
Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8DIHIACgkQ0F+nu1YWqI1YSgCfZzqwb0QA8ngLd9BpH8aPQn2K
UgYAn2p8urn7jpO4HNUKs1pCDmGGrg+g
=uvjo
-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] fallout and regressions are the new black
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-12-14 12:30 PM, curtis Hovey wrote: I think we have a simpler set of rules based on Francis posting that helps us to prioritise work. Fallout and regression bugs are criticals because we recently made something worse for users. Fallout can be a regression, but when it's not, we haven't made something worse for users. They couldn't do it at all, now they can do it, but it's buggy. We have, however, made the codebase more buggy. These bug queue must be kept at zero. Agreed, but because we must not let the codebase become more buggy. The rules for setting importance based on tags and the team that is driving the queue to zero look like this: Feature team Maintenance team | CRITICAL fallout | escalated regression | regression blocker | blocker | HIGH feature-tag | oops | timeout I don't understand what this means. If you mean that maintenance teams would not work on fallout bugs, I don't think that's right, because fallout can be discovered after the feature is completed and the team rotates. Whatever team is on maintenance should fix fallout if it's discovered after feature completion. Maybe we can just use tags? That way we wouldn't have to change the bug importances to reflect them. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7o7UoACgkQ0F+nu1YWqI0J8QCeJdNxMI8hcxWa4f2yip/1OxCT JpMAmwckkz64/Yl1/oVYjwRAy5/bQ1Jq =5zHv -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] SOA object ids
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-12-13 01:26 AM, Robert Collins wrote: We could say 'utf8' and leave it at that. Or we could say 'the printable subset of ascii' or some such. I'd just say non whitespace utf8, as strings are easier to deal with, and avoiding whitespace avoids most likely encoding issues. If we're using Unicode identifiers, do we need to specify a normalization form (NFC or NFD), or would we impose that on the data after receiving it? Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7nYOIACgkQ0F+nu1YWqI35RwCghOAMri5/6IBlXv1gjqDAelWI 9vsAn2Ka0zVUHLjB9MHWWvcwnnMNjBrJ =KCY3 -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] Bug listings checkpoint 2011-12-02
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-12-05 08:52 AM, Matthew Revell wrote: * Diogo and Dan: check how important it is to be able to specify sort ordering via the URL. I think you mean field visibility, not sort ordering. We are already able to specify sort ordering via the URL. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7c2IMACgkQ0F+nu1YWqI380ACdFkZ0W64nwFcfVlJ9BpKXD6GP oOYAnjNRG5UEbTnBHjRpMGOaAVMdieCh =m+yg -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] notifications - an implementation straw man (warning explicit discussion of services follows)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11-11-29 05:14 PM, Robert Collins wrote:
e.g. (if lifeless is my object id) 'lifeless is subscribed to
event tag 'assignee:lifeless'
I was thinking of the narrow case of adding and removing
relationships, so you'd have
notify($USER requested to review, $USER requested to review,
$USER requested to review, ['merge-proposal', 'add-relationship',
'add-reviewer'], ['BranchMergeProposal:25', 'Person:abentley'], [])
I don't really understand how your elaboration would work. ISTM that
if all reviewers were listed as event tags, it would be hard to work
out whose relationship had changed:
notify($USER requested to review, $USER requested to review,
$USER requested to review, ['merge-proposal', 'add-relationship',
'add-reviewer', 'reviewer:abentley', 'reviewer:lifeless'],
['BranchMergeProposal:25'], [])
btw, I think topics might be better as a mapping, so that we can
distinguish between two objects of the same type with different roles.
notify(proposal created, proposal created, proposal
created,['merge-proposal', 'add-relationship', 'add-reviewer'],
{source_branch: 'Branch:12', target_branch: 'Branch:10',
proposal: BranchMergeProposal:25}, [])
It seems like it would be nice if we didn't have to specify both
summary and subject.
Also, what are subject_template, body_template and summary_template?
HTML? MIME?
Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7WSNUACgkQ0F+nu1YWqI3VHQCeMbXluerBt19ue8r48nwlbBtR
5coAoIS/wj9XwTZJaBrEjcM4AQxlJME6
=CU2W
-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] notifications - an implementation straw man (warning explicit discussion of services follows)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-11-28 01:49 AM, Robert Collins wrote: Imagine the following API (a strawman, I don't claim its right :)): - notify(subject_template, body_template, summary_template, event_tags, topics, subject_tags, participants) Notify subscribers about an event. here the three templates are hopefully obvious. event_tags is a set that would have things like 'bug', 'project', 'branch' topics is a set of SOA object ids(*) subject_tags is a set of tags on the object itself. E.g. a bugs tags would go in subject_tags participants is a list of subscribables which are direct participants in the event (and thus should be notified even if the data in LP doesn't show them as interested). I don't think we need participants in that API. I think people would like control over all notifications. So participants can be selected the same way that other recipients are selected. subscribe(recipient, subscription_tags, event_tags, exclude_event_tags, topics, exclude_topics, subject_tags, exclude_subject_tags) subscribe an object to an event I suggest that such objects should describe the recipient and the method of notification. For example, user abentley via email or user lifeless via activity wall. That way, some events might trigger emails (or XMPP messages, or tweets...) while others would only post on activity walls. Querying who is subscribed to an object needs to be fast however. A fact table: topic event_tag exclude_event_tag subscriber can give subscription lists for topics very easily, still relying on in-LP expansion of teams. (A topic being e.g. 'bugs for project foo' - a structural subscription). I'm not sure that doing expansion of teams after determining subscribers will give users the control they desire. I think it might be better if subscribing a team generated subscriptions for its members, so that they could then adjust them as they desire. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7VGS0ACgkQ0F+nu1YWqI3gngCfdwItmG1Jb9PLmgmhS2FhgcDC 2WsAn2W6iF4Lo9DGh2XU7Xyko+zQ9RQM =FSzw -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] notifications - an implementation straw man (warning explicit discussion of services follows)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-11-29 03:29 PM, Robert Collins wrote: On Wed, Nov 30, 2011 at 6:41 AM, Aaron Bentley aa...@canonical.com wrote: I don't think we need participants in that API. I think people would like control over all notifications. So participants can be selected the same way that other recipients are selected. I agree that people want that control. The issue here is dealing with race conditions. Consider: removing an assignee. You would expect the assignee to be notified. But LP no longer knows who the assignee is after they are removed. So that knowledge needs to be preserved. ISTM that you could subscribe $USER to relationship changes of $USER and then include the user in the event tags. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7VVx0ACgkQ0F+nu1YWqI0JegCfW4+Q5hzFfrs7Z6VrS6ypsaEQ f9YAnjxTy6TuVR7FLPPaIcLo5Tcvoutu =PwDl -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] Update on the custom bug listings beta
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-11-28 10:20 AM, Matthew Revell wrote: Aaron's CCd so maybe he'll add to this and/or correct me. Everything looks good to me. * The bug listing arrows appear to be backwards (bug 894535). Do most people agree? I agree. * How do we help smaller screens users (over 50% of LP visitors) make the most of the new data they can see in bug listings, while enabling wider screen users to see as many bugs as possible in one go? (bug 894442). I wonder whether the small-screen users are mostly bug reporters, rather than bug fixers, and whether we need to cater to those audiences differently. Or maybe people can self-medicate-- we can start with a short list of fields that will fit on a line of a small screen, but users with big screens can add more fields. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7TrXEACgkQ0F+nu1YWqI1mjwCfW77Mp2m+/sfu+tiZ/oaFR8MS OUsAn3ayB3gIlUfuJNr4Fj6rT/qURzIQ =B29w -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] text markup in launchpad
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-11-18 06:26 AM, Gavin Panella wrote: In a previous life I solved this by having a automatically updated preview pane next to the text area. If the user stopped typing for a certain amount of time the content was sent to the server for rendering and put into the preview pane. We might even be able to do this client-side. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7GfXUACgkQ0F+nu1YWqI1cPwCfbCMwsH5MJ5qer6JwL9gXu2k8 Fz4AniZSGGt/1pSpHE3MvAqgER/MLWrf =Ibc8 -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] ec2 test failures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-11-16 09:12 PM, Robert Collins wrote: One way to fix it would be to allocate each thread a range, monotonically increasing, and giving each range say 1M integers. Another would be to use the same series across all threads. Thats probably simpler. Bjorn implemented this to improve parallelism, IIRC. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7FFCgACgkQ0F+nu1YWqI1RZgCdHhEEmYv5jZm4zrBHncB816fK HKQAn3NCFkE9qeomQ4c75qdMPNVPbILK =8+R4 -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
[Launchpad-dev] LP.cache fully populated for anonymous users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Just a heads up, I've implemented full support for the LP.cache for not-logged-in users in r14286. We need this for the new dynamic bug listings, because they use the JSONRequestCache to retrieve the next batch of listings. This has landed on qastaging. Historically, we've avoided this because we wanted to obscure email addresses. henninge had already added support for obscuring text fields of web service Resources, but since the JSONRequestCache can also contain plain Python objects, I've made it obscure plain strings. There are a few caveats; it is certainly possible to wilfully avoid this obfuscation by using encoding (such as using #x40; instead of @). Ideally, there would be a sanctioned way to defeat the obfuscation, like a structured string, but we can add that when and if we need it. This obfuscation does not affect server-side code, so if you want to output the contents of the JSONRequestCache (as we do with the new bug listings on the server side), you must manually obscure it. For example: objects = obfuscate_structure(IJSONRequestCache(request).objects) Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7BNFkACgkQ0F+nu1YWqI0kWwCdGZfUCatbcMIN6onC3T7ypSr2 bVUAnjbsMHedTVmIrmxfARFW5ZjpHF0m =haM5 -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] An normal UX for Launchpad
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-11-11 10:25 AM, John Arbash Meinel wrote: On 11/11/2011 4:15 PM, Jonathan Lange wrote: Also, they mean that some pages exist that don't really serve much of a purpose, e.g. https://code.launchpad.net. jml Would https://launchpad.net/code be any less a page that exists that doesn't serve much of a purpose, but that would basically be expected to exist? It could be that code would be a second-level identifier, e.g. http://launchpad.net/bzrtools/code Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk69Px8ACgkQ0F+nu1YWqI0dHQCeKCx3dZ+FM2Vzojb5LgNqFtq7 IcUAn27pL4YYbtGz5HD86oCkFBklvnFE =4Ue2 -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] LESS CSS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-11-08 12:18 AM, Huw Wilkins wrote: LESS can be compiled server side or rendered client side by a JS file that is included on the HTML page. As we already have a compile step it should be straight forward to include LESS in that process. Though for developers, it would be nice to do it client side. I'm currently unittesting JavaScript, and it's very nice to skip the compile step. Also, I wonder if there are any synergies with Mustache templates, which we can also compile client-side using JavaScript. Personally I am in favour of using LESS. It sounds like a good idea to me. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk65P/EACgkQ0F+nu1YWqI1EzwCdF/hIlOQwQWKr8ug7NWle9tgl 7YAAnRczSq0aZCb+fc146f8g5/7WAP+t =vIr0 -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] Reviewer question about style of new objects in JavaScript
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-10-27 07:55 PM, Ian Booth wrote: My view is that I would rather adopt a consistent approach to these sorts of things, rather than using various design patterns to achieve the same end result. I guess I see it differently. To me, it's not about design patterns, it's about whether to add an extra layer. I think it's not the same result, because using YUI's oo means there's a whole bunch of extra YUI code involved. I just didn't see a strong reason to have an extra layer, and I wanted to get more experience with JavaScript's native oo. I'd agree that consistency can be a good reason, but AFAIK, both styles of oo are used in Launchpad, so either would be inconsistent. And I also think that any JavaScript programmer ought to be familiar with JavaScript's native oo. They'll encounter it sooner or later, perhaps even when debugging their own YUI-oo objects. The argument about someone without YUI experience looking at the code I don't think is relevant because YUI is our framework of choice and the entire codebase relies on it, so I can't see someone not knowing YUI being able to make much sense of too much at all really. I don't think we're an island. I could easily imagine extracting this code out to lazr.batchnavigator, and then the YUI requirement would be an unneeded barrier to entry. Using Y.Base doesn't really add much to the programming complexity and as stated below, offers a seamless path to using change events and attribute validators when required. I agree, Y.Base doesn't so increase the programming complexity very much, but a library should *reduce* the programming complexity. I find it annoying having to call .get(foo) to access each attribute. And I do wonder whether making method calls instead of doing direct variable access carries a significant performance penalty. What is the cost of supporting change events and attribute validators, when you're not using them? As a concrete example of the consistency issue, we had/have several different mockio implementations and it was/is a nightmare trying to figure out which one to use. I am sorry I gave you nightmares, but at the time I implemented IORecorder (now unified with the lazr-js one as MockIo by henninge), I could not find another implementation. I believe I implemented IORecorder essentially in parallel with lazr-js being integrated into the tree. So say lp.code.javascript used one implementation and lp.bugs.javascript used another and (the former) lazr-js yet another, one was forced to decide between staying consistent with what was there already in each code base or using what one knew from prior usage etc. This sort of thing kills developer velocity. We use a whole bunch of different kinds of persistent storage, IPC, serialization, etc in Launchpad. The main question is whether the advantages of each justifies the cost of the friction it introduces. I don't think native JavaScript oo should cause much friction. Every JavaScript programmer ought to know it. And since JavaScript provides prototype-based oo, it doesn't seem like a great idea to layer class-based oo on top of it. The abstraction will leak sooner or later, and if you don't know prototype-based oo, you won't understand what's really going on. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6qreIACgkQ0F+nu1YWqI3pFQCfbLmQitK1MQyuKia0RJVSojqu h4MAn2vS5JDFLN458C/3AhjqiLdWehHo =O1jH -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] Reviewer question about style of new objects in JavaScript
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-10-28 10:17 AM, Francis J. Lacoste wrote: I guess what I'm trying to argue is that in a large system, consistency beats local simplicity. That works for me. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6qvcgACgkQ0F+nu1YWqI1l8ACdGXKRVqub3xcQFkY+vvTyx4tc 5qIAn1dMu+rwtqZ1Itxnp8S2zZ8275r1 =4diW -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
[Launchpad-dev] Rendering templates either server or client-side
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I've just given Launchpad the ability to render a given template either server-side or client-side. I've done this because the CustomBugListings feature means we'll want to render bug listings on the client and server sides, and we have a new design for them. Here's a screenshot of the current work: http://people.canonical.com/~abentley/mustache-listings.png I've used the Mustache templating language for this. The Python implementation is called Pystache, and the JavaScript implementation is called mustache.js. In either language, the inputs are a string and a JSON-compatible mapping (a dict in Python, an object in JavaScript). In Javascript, you render a template like so: Mustache.to_html(template, data). In Python, it's pystache.render(template, data). For the bug listings, I bundle it as a variable (LP.mustache_listings), so that the exact same template text is used on both sides. This satisfies DRY, and helps ensure the output will look the same wherever it's rendered. I bundle the data in the IJSONRequestCache (LP.cache). This means that we're also able to retrieve the data without the web page, by appending ++model++ to the page's url path. As we move forward with client-side rendering, I'm sure we'll standardize this further, but I think we're off to a good start. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6YphEACgkQ0F+nu1YWqI1duACeN5E+QH6kJIVHW6DxhRM+DEFN S1sAn2zBIx/2ssH13pycEyhB+7NXOicb =iPTJ -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] Rendering templates either server or client-side
Hi Graham, Yes, the mustache support has landed. The new bug listings are up for review. Aaron -- Sent from my phone. Please excuse my brevity. Graham Binns gra...@canonical.com wrote: Hi Aaron, On 14 October 2011 22:13, Aaron Bentley aa...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I've just given Launchpad the ability to render a given template either server-side or client-side. I've done this because the CustomBugListings feature means we'll want to render bug listings on the client and server sides, and we have a new design for them. That's awesome. When you say I've just given do you mean this has landed on devel? If so, thank you. (I don't have a use for it yet myself, but it's still funky and cool). -- Graham Binns | PGP Key: EC66FA7D http://launchpad.net/~gmb ___ 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] Rename lpreview_body to bzr-lp-dev?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-10-12 03:39 PM, Robert Collins wrote: lp-link-bug just links a branch to a bug. It's nothing specific to developing Launchpad, so I'm going to propose adding the functionality to Bazaar's Launchpad plugin. I think that should perhaps be in lp;lptools. Could you explain why it should be there instead of in the Launchpad plugin? AFAICT, lptools isn't even a Bazaar plugin. Instead of breaking it out into a separate plugin, I propose broadening the mandate of lpreview_body to providing tools for developing Launchpad, and renaming it appropriately. It would be a companion to lp-dev-utils. What about putting it in lp-dev-utils? A companion would be fine too from my perspective. It would be weird to have a package be both a Bazaar plugin and a collection of scripts, don't you think? Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6V90oACgkQ0F+nu1YWqI3YkACfcH2p+Jeki8rHaUsczhcSPRFc oGQAn1aah0zCPpltUJsnYnz1b+WMHIDB =Zyqi -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] Orange begins work on custom bug listings!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-10-11 03:38 PM, Barry Warsaw wrote: On Oct 11, 2011, at 05:43 PM, Matthew Revell wrote: Yesterday, Deryck's Orange Squad began work on the Custom Bug Listings project! You can keep track of the project's progress here: https://dev.launchpad.net/Projects/CustomBugListings The mockups look great, and I can't wait to see this in action! One question immediately comes to mind: will the patch, bzr, lock, blueprint items be selectable, or are they part of the bug heat, or...? What do you mean by selectable? Able to turn them off and on in the display? Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6UnjgACgkQ0F+nu1YWqI0S2gCeI0eWaU1IrFBHmIrSvWZD4jaz +psAniomozJEbBoCGiU2j4jubDsl92oS =6ec6 -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] To wiki or not to wiki
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-10-06 05:14 AM, Matthew Revell wrote: Now, as for whether we favour Sphinx docs or doctests, I'm a little less clear on. I prefer the Sphinx stuff because anyone can access them via rtfd. However, my experience with doctests is pretty limited. I think we should favour doctests, but we may be able to provide them through Sphinx. I don't like calling them doctests, because they should be testable documentation, rather than being focused on testing. We should just call them documentation. Sphinx has an extension for doctests, so we may be able to support them through Sphinx. Read The Docs doesn't indicate whether they support that extension. I think a lot of our existing doctests are primarily focused on testing, so they would need some rehabilitation before we'd want to include them in Sphinx documentation. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6NryUACgkQ0F+nu1YWqI34jQCghjR8bqgfZ5uGHY6nSzIQ2yMd wBgAn3+/iG8cI9fgdBJT3RIhAH0yYG3u =UYa3 -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] headsup: upcoming changes to oops-*
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-10-04 05:54 AM, Robert Collins wrote: Actually thats a lie, this mail is about changes that have already happened, *and* about some upcoming changes. The exciting news is this: - oopses will be much more extensible - a bson serializable dict is used, rather than the rfc822 format bson-serializable, or bson-serialized? - we may have low latency (several second) delays from oops creation to inclusion on the oops-tools site Yay! The downside, and the reason for this mail *before* enacting all these changes, is that the change to bson will make OOPSes less greppable on devpad. Oopses have a lot of text, so the standard unix tools work well with them. Why not use json rather than bson, to retain that compatibility? Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6LC70ACgkQ0F+nu1YWqI3vIACcDkB0FeIIs25U0u5O0aFyRF3o Xx8AnR5/E84yueI0+YhDGPQC1bL7erAC =Zp7+ -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] Chaining security adapters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-09-06 12:43 PM, Brad Crittenden wrote: This sounds a lot like the DerivedAuthorization class. Have you seen that? I did see it Aaron. One difference is DerivedAuthorization doesn't allow using a different permission, which was a use that came up a few times. I think the two can probably be merged, though, and I like the name DerivedAuthorization better. I think merging them would be a good idea. Using a different permission makes sense in some cases, just not any of the ones I encountered while writing it. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5mTkUACgkQ0F+nu1YWqI1pYACdHPAijAVEtqmRWrLWUBp//G9C dKsAniR216R4p2Yig0tjmFUsiz6gimIK =QkIA -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] Aborted Deployments, Bad Revisions (and what this means for launchpad devs)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-08-24 11:38 AM, Deryck Hodge wrote: Henning has landed a rollback for r13766 in r13777. Since then, we encountered another regression, bug #833147. I have fixed it in r13779, so that should be our new landing target. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5VLUEACgkQ0F+nu1YWqI1k2ACdFBbOe02lfpCyQwWUisPdI2QJ PngAniBdEH7pno3kK9k8SCLLJ5Fglme9 =n8fL -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] Matthew Revell is the new Launchpad Product Manager
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-08-24 12:26 PM, Francis J. Lacoste wrote: It's my pleasure to announce that as of today, Matthew Revell is the new Launchpad Product Manager. Congratulations, Matthew! Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAk5VLW0ACgkQ0F+nu1YWqI0EwgCfRUKc2BL6iy6TAgH4Pd9yFvnY q+YAmLdiLOpbld6fsYNAKs+YdITzSAw= =Zi/X -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] Critical bugs over a month old still critical?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-08-19 04:12 PM, Francis J. Lacoste wrote: And since Critical doesn't mean must be fixed now why is it a work-on-first bucket? Why do we have a focus on burning it down to zero, at the cost of stalling our high and low bugs? It seems like allowing us to fix high bugs could improve the overall user experience more. Because we (at least I) think these issues are more important than other High or Low ones. Quoting Gavin who did a good job of summarizing the criteria here: I understand the criteria, but I think that the attributes of an issue are less important than what the issue actually is. For example, 723417 is a regression, but the regression is that a text field is smaller than it used to be. 823850 is an oops, but you can only get that oops in a corner case, and it doesn't prevent you from accomplishing anything. We cannot assess what fixes are going to give the most overall improvement using our critical criteria, because they don't consider overall impact. Avoiding an oops for 1 user is nice, but making life slightly easier for 1000 is better. Stakeholder escalations seems to be our only mechanism that considers impact. My main concern at this time is the fact that we are getting since April 1st 20 new of these bugs per week [1]! Which is about the same number of issues we fix on average per week [2]. No wonder the burndown is stalled for so long. Also, it's my impression that most of the low-hanging-fruit critical bugs have been taken, and the remaining ones are harder and therefore slower to fix. I don't have an explanation of why we are finding each weeks 20 of these issues. I also don't have the impression that these are legacy issues. Many of them comes from new work. We're also getting some about merge proposals and branch upgrades, which are features that haven't changed much recently. We need to investigate that stream of incoming rework and stop it at the source if we ever hope to burn these issues down. Once I sort out the recruitment projects I'm working on, that's my next project. Cool. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5SZYUACgkQ0F+nu1YWqI3wBgCcCdsq2KaPg1IzDuP+c6Jz/M1w gvcAnjs0Ld3t6qfiCdLoC5wUPOhhWC3e =oMIJ -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] Critical bugs over a month old still critical?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-08-19 03:02 PM, Francis J. Lacoste wrote: On 11-08-19 07:40 AM, Gavin Panella wrote: The Red Squad is going to be coming off a long hard feature cycle soon. I'm looking forward to maintenance, because I want to have time for longpoll and the SOA stuff. However, the Critical bug list is huge, and I have a sinking feeling that I won't have time for those things. I want to see if I can move the goalposts. On to your original question though, my answer is 'yes', they are still 'Critical'. The time it takes to fix issue isn't related to their priority. The fact that we cannot close all our critical issues in a month doesn't make them less of a priority. No, but for critical, in the normal sense, it is unacceptable to have not fixed it within a month. You should be working day and night until it is fixed, and if you usually don't fix your critical issues within a month, your web application won't be viable very long. So the fact that your application is still viable, despite having not fixed the bug after a month, is a strong indication that the bug wasn't critical in the normal sense. One source of confusion here is the critical name. Let's change the critical name, then. It's not just confusing to us, it's misleading to outsiders who look at our bug lists. We're not using Medium, so let's move our High bugs to Medium, our Critical bugs to High, and reserve critical for things that actually are critical. (And update our policies accordingly) Think of it as 'Work-on-first' bucket which is what they are about. And since Critical doesn't mean must be fixed now why is it a work-on-first bucket? Why do we have a focus on burning it down to zero, at the cost of stalling our high and low bugs? It seems like allowing us to fix high bugs could improve the overall user experience more. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5OuhIACgkQ0F+nu1YWqI3EAQCfduBGnCpjfCTCROlCrAtx6LSv BDwAoIG0VEm8ZHk+DEf8b8k19QcId/d3 =D8r3 -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] Help! Knowing what packages are in a distribution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-08-18 11:11 AM, Curtis Hovey wrote: We have no mechanism to ensure that source package branches are represented in the DSP table. Maybe the branch scanner could do this. When a user pushes a branch, an entry for that branch is created in the database immediately, even before scanner runs. I think it would make sense to update the DSP table on branch creation (which would also work for remote branches, which are never scanned). Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5NNXQACgkQ0F+nu1YWqI057ACfeA/zziL61PO6sAVJU8mGIszM iwYAniCka9H+fRf25MHHXf2Q39SkJPkn =05Cv -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] Help! Knowing what packages are in a distribution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-08-18 01:27 PM, curtis Hovey wrote: Francis qualifies that Lp cares about official source package branches. I think this means we want to call DistributionSourcePackage.ensure() when a SeriesSourcePackageBranch is created? I am not certain. That sounds right to me. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5NT7YACgkQ0F+nu1YWqI0U/QCfe5WmS2gzrXi/kIZAiOQLs2bq Y4kAn2vxOmaUVbun6EtdmBgfBC5RHWVI =l5Ph -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
[Launchpad-dev] script_commands library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, While hacking on the local-latency script (which now has a configurable - --port, by the way), I was unable to resist my compulsion to make it simpler the next time I do this kind of thing. The result is utilities/script_commands.py, which makes it easy to turn a function into a script, or script subcommand. Here's the definition of the start subcommand: @helps(delay='Length of delay in miliseconds (each way).', port='Port to induce delay on.') def start(delay=500, port=443): Add artificial latency to the lo interface on the specified port. As you can see, the only weird thing about the function is the helps decorator that describes each parameter. And that's optional. The stop command, which takes no parameters, is even simpler: def stop(): You run such commands with script.commands.run_from_args. Each parameter that has a default is converted into an option, and the type of the parameter is determined from the default. (I haven't needed positional parameters yet, so I haven't added support for them yet.) If your script needs subcommands, you stick them in a dict and call script.commands.run_subcommand instead of run_from_args. So the next time you're writing a utility script, give script_commands a try. It could save you time and drudgery. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4/724ACgkQ0F+nu1YWqI0pXwCfbsTonDqOSf1O8G+kqsfn0+z6 o/gAnRdhApBiIBw26bGLMrjksWFQ6A74 =fVE8 -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] script_commands library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-08-08 10:38 AM, Jamu Kakar wrote: This sounds a lot like a library I wrote some time ago called Commandant. It's a wrapper around bzrlib that let's you easily write applications with a Bazaar-like user experience. It's not surprising, since I've done so much hacking on bzr. But I've long thought that the command classes of bzrlib were somewhat redundant, since they only exist to house the run method. I think that functions are a better match for subcommands. Unlike bzrlib, script_commands doesn't require declaring options or their types. It's just less friction. It might be interesting if you want to go further and add topics, run shell scripts, etc.: I've no doubt Commandant provides a more polished user experience. I didn't think that was important for utility scripts, but maybe it is. Perhaps we should consider using it for our scripts. Certainly, anything that helps us avoid writing the same old boilerplate for our utility scripts is a win. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5AAG8ACgkQ0F+nu1YWqI1MgwCfc+d76F+rVVRHCzXtxzow1JrE U7YAnRk2+8ZJ7+LRP/PHXKimivwlWVSk =o3M2 -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] importance inflation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-08-04 04:13 PM, Robert Collins wrote: IMO when you have two bugs, a bug (A) that is directly critical per our triage rules, and a 'high' bug (B) saying that its very hard to identify whats going on in bug A, then bug B has to have its importance inflated to critical, otherwise bug A will suffer from priority inversion: imagine that A is the last critical bug. It can't be worked on because the data to solve it will come from closing bug B. And B is not critical, so its going to be worked on somewhere in the 6-month window of bugs that we try to size the 'high' set to. This then gives A an effective priority of 'high'. This is a classic priority inversion, and the normal scheduling fix is to grant the higher priority to the task holding the resource needed by the higher priority. I guess I'm reluctant to do priority inheritance because fixing bug B may not be necessary or sufficient to unstick bug A. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5AMtoACgkQ0F+nu1YWqI0ZQACdFvIy0+0H9CU7v4Pr4eURwTCZ vTcAn0AA0lfYlMb+TGfaFe29qa8s+M6Q =k95V -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
[Launchpad-dev] New local-latency script to simulate latency on your own box
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I've added a new script, local-latency to our utilities directory. This adds 500 ms of latency (in each direction) to port 443 (https) on your local machine. utilities/local-latency start will induce latency. utilities/local-latency stop will turn it off. The start subcommand also takes a --delay option to control the amount of latency. It's based on commands supplied by Martin Pool, but I turned it into script so it's easy to invoke. We want our AJAX to be as responsive as possible, and simulating latency will give you a better idea of how responsive your new code is. I know it would have been useful for me when I worked on the translation sharing-details page. I've added latency only to port 443, not the entire lo interface, because we don't want to induce latency on the database connections. The original commands are here: http://doc.bazaar.canonical.com/bzr.dev/developers/testing.html#simulating-slow-networks Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk477toACgkQ0F+nu1YWqI1tGACdGT6XVG/cgrjQUxM8kNSrMrBG TecAnjstBBTTYpJyQkihmiI0KTeUAuum =d6pn -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] importance inflation (was: merge-proposal-jobs interruption incident)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-08-04 09:24 AM, Gary Poster wrote: I spoke with Aaron on IRC. he identified 820510 and 820511 as the biggest bang for the buck. He did not want to mark these as critical. I don't really agree, but I also don't really care a lot. Yellow hopes to tackle at least one of those RSN. I think these bugs are important to fix, but I don't want to mark them critical in order to justify fixing them. Marking bugs critical when they really aren't makes us take longer to fix bugs that actually are critical, such as 556245, librarian1 non responsive and gobbling excessive memory. I think we're experiencing importance inflation, where things are getting marked higher than they should be, in order to increase their priority. Instead of using importance to determine priority, I think priority should be an ordered list that we control directly. That gives us much finer control, makes escalation trivial, and removes the temptation to inflate importance. When I'm doing triage, I have the incentive to mark a bug critical if I care about it, because our focus on critical bugs means that high bugs are rarely fixed. In scheduler theory, this is called starvation. However, this is also a solved problem: instead of trying to process all items in the highest priority class first, use ratios of classes. That way, progress is made on all classes, but priorities are respected. If we applied this to Launchpad, we could say, For every 5 critical bugs you close, close a high bug. For every 5 high bugs you close, close a low bug. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk46qZgACgkQ0F+nu1YWqI2ziACfdshWda67scmnc6KymwMmy218 WO8An2enJJKi7lCLA6c7q24LCoWm9SpS =5+Hn -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] merge-proposal-jobs interruption incident
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-08-03 07:47 PM, William Grant wrote: ParallelLimitedTaskConsumer has been implicated in several incidents this year, although not all of them were recorded formally. I don't actually think ParallelLimitedTaskConsumer is the cause, I just think that it's hard to understand, and not needed to solve this problem. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk462o4ACgkQ0F+nu1YWqI0nBgCfR7B3Bl0JPBEgDrP20SBQmWKh lUUAoIDg+e38ptETMraeDlGxuKGMrAD7 =Ir2A -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
[Launchpad-dev] merge-proposal-jobs interruption incident
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, We had some issues with the merge-proposal-jobs script earlier today: https://wiki.canonical.com/IncidentReports/2011-08-03-LP-failing-jobs I'm pleased to report that everything is working normally now. Unfortunately, we didn't actually fix anything. It just started working again when we killed and re-ran it. Since it's working now, we don't have enough information to debug it. We can take proactive steps to give us more info in the future. https://bugs.launchpad.net/bugs/820511 https://bugs.launchpad.net/bugs/820516 https://bugs.launchpad.net/bugs/820510 We should consider simplifying the code in the TwistedJobRunner by avoiding the ParallelLimitedTaskConsumer. We should also consider moving away from Ampoule, which appears to be unmaintained. Perhaps we could use Celery. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk45qZsACgkQ0F+nu1YWqI2oVgCfbvAi6ljq2yWqgIJ4m1QYMfTI MsoAnRxKlQ3cqiauwDAWFwYVLW0CIX8/ =PYn1 -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
[Launchpad-dev] Look out for LocationError...'getCacheJSON' on qastaging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I just landed a change to the way the IJSONRequestCache is serialized which has the side-effect that our base-layout template requires all views to be derived from LaunchpadView (or otherwise provide getCacheJSON). I fixed all failing tests, but at least one view wasn't being tested: the project +timeline-graph view. https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-2035QASTAGING62 Please let me know if you encounter any similar oopses on qastaging. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4ys9YACgkQ0F+nu1YWqI0TRgCfQqh0+G3KEhbK+DqfzrwNb5MN +V4AnioxydTljw3pPazYd+nqZr1U4sff =Pi/P -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] A draft microservice for gpg verification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-07-11 07:05 PM, Robert Collins wrote: On Tue, Jul 12, 2011 at 2:28 AM, Aaron Bentley aa...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-07-11 09:05 AM, Gary Poster wrote: I've done Twisted and Zope integration, and it's worked very well. All of the basics are open-sourced (zc.twist, zc.async) though none of it is of interest to us, because it uses ZODB. So have I, or perhaps it's called Twisted and Zopeless integration. In any case, our TwistedJobRunner manages to run jobs in a Zopeless environment, under Twisted. our script environment disables pretty much all the security checks :) Leaving just enough to be annoying, without actually being secure. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4cSa4ACgkQ0F+nu1YWqI2FRQCfSOWDN6ckZDBNNPlwQFm777FK du4An3+2K7/9NRVOD/xjWdTzytzDE48D =gmYU -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] A draft microservice for gpg verification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-07-11 09:05 AM, Gary Poster wrote: I've done Twisted and Zope integration, and it's worked very well. All of the basics are open-sourced (zc.twist, zc.async) though none of it is of interest to us, because it uses ZODB. So have I, or perhaps it's called Twisted and Zopeless integration. In any case, our TwistedJobRunner manages to run jobs in a Zopeless environment, under Twisted. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4bCIAACgkQ0F+nu1YWqI1NrgCeJhAdog/wwUyHDZVA+WHePiGb f4YAn3rKMY4f7jgYbsy9gw/0VXaNnVom =CZ0Q -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] Important: YUI repackaging (action required)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-07-01 12:57 AM, Ian Booth wrote: Hi Folks YUI is being pulled out of lazr-js and packaged separately in a tarball in the download-cache. The currect version we use is 3.3 so the tarball is called yui-3.3.tar.gz. This has already landed in download-cache. If you use rocketfuel-get, you shouldn't need to take any action since it has been updated to create the required directory and symlink. If you don't, read on. Could you please add this to the makefile instead of rocketfuel-get? Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4NsBwACgkQ0F+nu1YWqI3LqwCeJIY+RwftwvrPypgVRs5nCR+S ANkAn2RbUqV4dPG2EvgBOwGJsORr2Gvl =TUMQ -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] Moved developer docs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-06-22 11:38 AM, Jonathan Lange wrote: Hello all, If you'd like to read the Launchpad developer docs, you can find them at:: http://launchpad.rtfd.org Instead of the old location, which I'm not even going to mention here. Currently, I'm the owner of the 'launchpad' project on rtfd. As soon as I figure out how to change that, I will. If you want to *improve* the docs, well, it's all pretty standard Sphinx / reST. How do we know if a document should be on rtfd or the wiki? Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4CDZ4ACgkQ0F+nu1YWqI2oswCffJ+MzOrnxV9l/zgDQzOXnQGp rLEAnA/DBAcifH/d88NLgHVbfME8kMfr =WjIe -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] [RFC] LEP: Build from branch into archive
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-06-21 12:32 PM, Jelmer Vernooij wrote: It is possible to build a specific revision if you want to, you can specify one in the recipe, like so: # bzr-builder format 0.4 ubuntu:iprint 3 to build revno 3 of ubuntu:iprint Yes. In fact, manifests are recipes and can be used to reproduce a specific build exactly. Still - it will be harder to e.g. write a query that returns all source package releases built from the last X revisions in a branch. Yes, you do get more tables in the query. That seems like a different argument. Perhaps they are complex, but that has nothing to do with the need for traceability. It would be sub-optimal to have two different ways of determining the built revision. I don't see how manifests really provide traceability - the only thing they know is what revision from what branch was built. That is what I mean. I believe this can be vital information. If we keep track of that data in another manner anyway, how do manifests help with traceability? They don't, but it would be sub-optimal to have two different ways of determining the built revision. Most of the interesting traced data is either in the build logs, or in the build table anyway (requester of the build, target archive, etc). The revision id won't be in any of those, IIRC. Most of the code would be shared. To me, it looks like new code in the buildd, new code in the UI, new database tables. We use recipes to link everything together, so eliminating recipes means a lot of rewriting. The recipe and manifest only complicate matters here - they aren't necessary for bzr-builder to be able to build from a branch. What benefit would having a recipe have here? - From a feature development perspective, less work. From a maintenance perspective, less code and fewer bugs. From a user perspective, a simpler model. Hiding recipes at the UI layer for build-from-branch builds is going to make things more complicated. I think having two different features is more complicated. But I think that we might need to have unnamed recipes in order for this to work smoothly. Recipes make it harder to find back the relevant revision and branch that the build was created from. Harder in the sense of more tables in the query. Not harder in any significant sense. Manifests don't add extra traceability. No, but having two different ways of producing source packages makes it harder to trace the origins of a package. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4A2Z8ACgkQ0F+nu1YWqI1/qgCeJ81DlwR/PFXTQ6O5Q0D/cnSD N4gAnRoV7xzNuCZtjt2lVBJbt3c0NS5A =XXs8 -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] Micro clouds - could OpenStack be the Launchpad development environment?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-06-17 04:19 PM, Elliot Murphy wrote: For a long time I've dreamed of a development environment that could easily spin up and down multiple lightweight containers wrapped around different service components. I've been interested in this space for some time now. I think that deploying Launchpad as a private cloud client would give us more flexibility, give developers a higher-fidelity environment, and allow us to QA our work simultaneously with landing it. The less-intrusive installs would also be a win, especially for working with the buildd. My challenge to you, dear hackers, is can the default Launchpad developer setup be changed to run in LXC managed by OpenStack? I think it probably can, but I think we need to formally commit resources to doing it. OpenStack is making heavy use of Launchpad OpenStack is also moving away from using Launchpad and Bazaar for code hosting, and some are pushing for switching other services to github as well. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3/UVUACgkQ0F+nu1YWqI3HmgCfTkHwVonnvrowAIO9oD2r+R65 RT0Anj1Nk2vPnQtOg3YQsU0BYHKccOy3 =vZrT -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
