Re: Moving udd to django
On Sat, 10 Dec 2011 17:52:40 +1300, Robert Collins robe...@robertcollins.net wrote: On Sat, Dec 10, 2011 at 3:10 PM, James Westby jw+deb...@jameswestby.net wrote: Hi, I think there are a few reasons that we should consider moving udd to django (more on what this actually means later.) I'm curious what data udd stores. There are two sets. There's the bookkeeping data for running import-package each time a package is uploaded to Debian or Ubuntu, keeping track of failures, etc. Then there's the bookkeeping data for import-package itself, about what it thinks the state of bzr is etc. These should be treated differently, with the former the one that is more important for the goals laid out here. Thanks, James -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Moving udd to django
On Sun, Dec 11, 2011 at 4:28 AM, James Westby jw+deb...@jameswestby.net wrote: On Sat, 10 Dec 2011 17:52:40 +1300, Robert Collins robe...@robertcollins.net wrote: On Sat, Dec 10, 2011 at 3:10 PM, James Westby jw+deb...@jameswestby.net wrote: Hi, I think there are a few reasons that we should consider moving udd to django (more on what this actually means later.) I'm curious what data udd stores. There are two sets. There's the bookkeeping data for running import-package each time a package is uploaded to Debian or Ubuntu, keeping track of failures, etc. It might be interesting - as a thought experiment if nothing else - to consider failures a form of crash and upload them to a crash database rather than processing them inside udd - e.g. toss them out over amqp. -Rob -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Moving udd to django
On Sun, 11 Dec 2011 06:38:25 +1300, Robert Collins robe...@robertcollins.net wrote: It might be interesting - as a thought experiment if nothing else - to consider failures a form of crash and upload them to a crash database rather than processing them inside udd - e.g. toss them out over amqp. The current design is that it also uses them to avoid acting on that package until there is manual intervention. So it may be interesting to use oopses to communicate the problems and do analysis of them, but it won't avoid storing the data as well unless that model is changed. Thanks, James -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Moving udd to django
On Sun, Dec 11, 2011 at 7:19 AM, James Westby jw+deb...@jameswestby.net wrote:
On Sun, 11 Dec 2011 06:38:25 +1300, Robert Collins
robe...@robertcollins.net wrote:
It might be interesting - as a thought experiment if nothing else - to
consider failures a form of crash and upload them to a crash database
rather than processing them inside udd - e.g. toss them out over amqp.
The current design is that it also uses them to avoid acting on that
package until there is manual intervention.
So it may be interesting to use oopses to communicate the problems and
do analysis of them, but it won't avoid storing the data as well unless
that model is changed.
I'm sure the data needs to be stored somewhere. If its in a crash
database, then you can ask 'has this crash been handled' where I guess
handled means flagging the crash signature in someway ('retry', 'bug
X', ..). The poential benefit I see is one less place writing fault
aggregation heuristics.
-Rob
--
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: REVU, #ubuntu-packaging, and mentors.debian.org
On 12/10/2011 11:41 AM, Scott Ritchie wrote: If you're going to leave REVU up, you need to make it very clear that it's neglected within the REVU submission interface itself. The notices up on the website help, but the actual submission interface for REVU is dput. The revu-hackers may have ideas on how much leeway we've got to hook extra actions into a dput upload. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: REVU, #ubuntu-packaging, and mentors.debian.org
On 12/10/2011 09:36 PM, Allison Randal wrote: On 12/10/2011 11:41 AM, Scott Ritchie wrote: If you're going to leave REVU up, you need to make it very clear that it's neglected within the REVU submission interface itself. The notices up on the website help, but the actual submission interface for REVU is dput. The revu-hackers may have ideas on how much leeway we've got to hook extra actions into a dput upload. I think for REVU it's reasonable to expect people will look at the web site or some related documentation. I think if it's clear there, that's sufficient. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Fwd: libmpfr1ldbl not found in oneiric
On 12/09/2011 06:48 PM, diego fanesi wrote: Hi, I'm trying to install bigbluebutton on oneiric but libmpfr1ldbl package seems to be missing. The whole mpfr source package has been replaced by mpfr4. The library package is currently called libmpfr4. Could you add this package on official oneiric repository or check dependencies of bigbluebutton? Since bigbluebutton isn't in the official repositories, you should direct your question to the maintainers. They should update their ppa for oneiric. Bye, Andreas signature.asc Description: OpenPGP digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
