Re: [Launchpad-dev] UI RFD: branches that haven't been pushed to
У сре, 28. 04 2010. у 16:03 +1000, Martin Pool пише: To me, the translation exporter is creating a branch that can be looked at and or merged, in much the same way that a third-party contributor can do. It shouldn't be creating new empty branches and it shouldn't be writing in to branches owned by someone else. Except it's very natural for people to want to not do anything and get their translations in their own branches: and merging them by hand is too much for some people (yes, just like people want to integrate tarmac with Launchpad, they want other things to happen automatically). Translation PO files might seem like actual source code, but they don't really work well with version control. They have a lot of metadata around useful data (translations) that may be changed and merging would be a nightmare. For instance, every msgid in the PO file has a source code reference which includes the line number where it appears. Add an empty line to one of your source files, and that and all other references to that file will change. You've got yourself a conflict (or more often, a million of them). It should make its own branch and then invite people to look at it or merge from it. This seems to avoid many questions about users pushing to it etc. So, translation exporter overwrites PO files in your target branch. That saves you the trouble of having to worry about resolving conflicts yourself because this is most likely how you'd resolve them anyway (by just using a better copy to overwrite the existing file). Thus, the question remains. If PO files were completely manually maintained, it would have been much simpler. But they are instead a mixture of generated data and human input. Cheers, Danilo ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
[Launchpad-dev] Want feedback on LaunchpadSharp
Hi everyone, For the last few days I have been working on creating Mono/.NET client wrappers on Launchpad API. I love Python but my day job involves a lot of C# coding, so I thought it would be good to have multiple client wrapper for this API so that the potential of Launchpad can be exploited to the maximum. I know many people can be skeptical of Mono, but as a programmer I wanted even Mono developers of Windows developers on C#.NET to start using Launchpad or even better host their Open Source Projects on this platform. Let me explain Aurthur about the project: =wadlsharp= Launchpad provides a WADL file describing the API for the web-service. I wrote a WADL-C# converter called wadlsharp[1] . Actually with minor modifications it can even create VB code but that is not the current target. wadlsharp is just a library and I am yet to write it's documentation. I created wadlsharp just to create the C# client code so that customizing the generated C# code can as easy as possible. I have released v0.1 of wadlsharp. Get the code from bzr[2] or download the tarball[3] =LpSharp= Using the generated C# code, I have completed implementation of OAuth specific to LP. For all the HTTP methods supported in Launchpad - GET, POST, PUT, PATCH and DELETE, I have implemented GET as of now. The project is still under development, but I wanted to send a mail to inform everyone that such an effort is underway and they can send their comments using which I can prevent serious design mistakes or even accept patches for this project. The name of this project is Launchpad#[4] I have already take the permission for using the word Launchpad which is a trademark of Canonical. I would humbly request everyone to look at the source code and send their valuable feedback so that I can make it better. Both the projects are licensed under MIT / X11 / Expat license [1] https://launchpad.net/wadlsharp [2] https://code.launchpad.net/~manishsinha/wadlsharp/trunk [3] http://launchpad.net/wadlsharp/trunk/release-v0.1/+download/LpNet.WadlSharp.Common.tar [4] https://launchpad.net/lpsharp/ CCing all the Canonical devs with whom I have talked earlier when I was about to start working on LpSharp (Launchpad#) -- Manish Sinha http://launchpad.net/~manishsinha ___ 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 feature in Launchpad TestCase base class
Hi All, In my continued mission to make things easier to test, I've added a new feature to the base TestCase class in lp.testing (this makes it in TestCaseWithFactory too). r9327 of db-devel (will be rolled out tonight) contains this change. The test case class now has an oopses attribute. This is a list that gets any oops generated as part of the test appended as it is generated. This gives any test a deterministic way to determine if any oopses were generated. Tim -- the magic The error reporting utility now notifies listeners when a new oops is generated using an IErrorReportEvent (which is an object event). The setUp method of the test case adds a listener, and adds the cleanup to remove the listener after tearDown. This uses a Fixture that jml wrote a while ago for the scanner (which has since been removed). The fixture code was moved to lp.testing.fixture. If you have a need to use something in your tests that has a setUp and tearDown, you can define a fixture, and use the TestCase method installFixture. ___ 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] Build branch to archive - status report
Hi Francis, Julian and interested observers, We have had some initial testing on dogfood.launchpad.net for the build branch to archive work. Initial progress is very promising with some end to end recipe builds working. Here is a list of things that we need to get finished before we enable on edge: * recipe build index - shows the builds relating to a particular recipe * we have an authentication edge case that we are chasing down but hindered slightly by the dogfood oops report disappearing * some builds that are not viewable by the user are being shown in a listing causing a 403, these need to be filtered out (for example someone else builds your recipe into a private ppa) * we are missing a select permission for the buildd uploader * some work needs to be done on the distroseries selection and build request validation None of this is exceptionally long or hard work, and we'll try to keep you updated. There is still a lot of UI polish that is needed as we AJAXify things. Tim signature.asc Description: This is a digitally signed message part. ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
