Re: [Debian-l10n-devel] Package description translations for Lenny
On Sun, Aug 10, 2008 at 12:42 AM, Luk Claes <[EMAIL PROTECTED]> wrote: > Currently it would be strange to do description translation updates for > stable outside point releases, so if that's wanted, that would need more > discussion... Given the pecentage of packages translated for some languages it would be nice if new translations could be added after the release. Not saying we have to, but it's good for the motivation. Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Would an ABI change of apt for DDTP support still be accepted?
On 10/2/06, Thijs Kinkhorst <[EMAIL PROTECTED]> wrote: I value the importance of the DDTP project, but the translating effort has only recently seriously started. Looking at the statistics[1], I see that the best language has yet only one third of descriptions translated in optional and extra, and steeply dropping to only a couple of percentpoints for those after that. Not sure which statistics you're looking at, perhaps these? [1] Sure, maybe the top language has only 33% of optional done, but several languages cover the entire base install. Additionally, the numbers are not fixed. As many (most?) descriptions are shared between etch and sid, even after etch is released the descriptions will keep getting updated and improved. Best translated are required/important/standard, but those descriptions will be the least relevant to Joe Average, since these packages are already installed for him. The goal should be making sure that most of the packages people have installed are translated, as well as the most popular packages. That is a much more acheivable goal, and I think that's attainable in the near future... I hope you're not suggesting we need to get all languages covering all of optional before you think it is worthwhile? As for whether it's enough to make it happen for etch, that's not my call. But the vast majority of descriptions for etch+1 will be usable for etch also, so the decision should *not* be based on whether the descriptions are ready now. Have a nice day, [1] http://svana.org/kleptog/temp/ddts-stats.html -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Do not make gratuitous source uploads just to provoke the buildds!
On Wed, 16 Mar 2005 14:44:34 +0100, Wouter Verhelst <[EMAIL PROTECTED]> wrote: > Op di, 15-03-2005 te 16:19 -0500, schreef Anthony DeRobertis: > > Wouter Verhelst wrote: > > > > | You misunderstood. I don't fight generic changes to the order; I just > > | don't think it would be a good thing that any random developer could > > | prioritize his pet package. > > | > > > > Any random developer already has root on X thousand debian systems. We > > can trust him with that, but not with helping determine build order? > > I'm afraid it won't actually be 'helping'. > > I've seen enough of "My package isn't built and it's urgent and the > buildd admins suck!" to expect what would happen. Aah, so the trick should be to implement this on the quiet. Tweak the values according to have it's progressing. Eventually you should see a reduction in complaints. It wouldn't be hard to be able to guarentee an upper bound for building, say two months. Once people stop complaining you can tell them. Maybe they won't feel so inclined to fiddle when they can see it works. > That's not to say that a request to prioritize a package is to be > ignored; however, the power of deciding which packages get built first > should be with those that actually build the packages, rather than with > those who want their packages to be built. The former are expected to be > following the larger picture; the latter are not. As far as I can tell, buildd admins don't spend all day prioritising builds manually anyway. We're dealing with computers here, they don't care how complicated the calculations are. Decide where your priorities are and implement it. If you don't like to hear people complain, add a rule saying "if package is older then one month, build it now". It cost you nothing and saves heaps of grief. As a bonus, repeatedly uploading new versions would keep resetting the counter, so they'd be encouraged to upload less. The current process of indefinitly starving "extra" packages is just silly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
