FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Kubuntu Development

 
 
LinkBack Thread Tools
 
Old 11-03-2009, 06:58 AM
Mark Kretschmann
 
Default Project Timelord -- Initial consideration

On Tue, Oct 20, 2009 at 9:21 PM, Jonathan Thomas <echidnaman@gmail.com> wrote:
> Hello fellow Kubuntu developers,
>
> Kubuntu, as we know, is a fairly good KDE distribution. (Otherwise we would
> not be here reading this mailing list) However, things are not perfect. In
> fact, things could be much better.
>
> "But what is Project Timelord?", you may ask, "and how does it relate to
> Kubuntu's problems?" Both are good questions. Project Timelord is the
> brainchild of the Kubuntu developer legend Harald Sitter; the culmination of
> several weeks of brainstorming by a handful of Kubuntu developers, focused
> towards identifying problems Kubuntu currently faces and solutions for these
> problems.
>
> And now, we wish to bring Project Timelord to the attention of the greater
> Kubuntu development community for input. You can find the internal developer
> release announcement that outlines the purpose and proposed solutions of
> Project Timelord at: http://docs.google.com/View?id=dfc7xjfj_18g8k5ztg4
>
> If it is decided that we would like to adopt Project Timelord as a goal to
> work towards over the next few cycles, we can start towards prioritizing the
> solutions and work towards forming a roadmap to implementing these solutions.
> This way we can all stay in the know of what is going on even if we are unable
> to attend UDS, and those attending UDS will have a unified goal to work
> towards as they flesh out the implementation details for Kubuntu 10.04, Lucid
> Lynx.
>
> The purpose of this email is to generate discussion to determine whether the
> Kubuntu developer community wishes to adopt this plan or not, as well as to
> provide input on the brainstormed solutions. Until it is decided, we would
> politely ask you to not announce the existence of the project to the general
> public. We would like to hear your thoughts on the initiative here, though.
>
> Thanks in advance,
> Jonathan "JontheEchidna" Thomas.

I'm a bit late in the game, but I would like to express my support for
Project Timelord. While I think that we must be happy for the support
that Canonical is giving Kubuntu, their level of support is limited,
and it also also comes with lot of baggage from Ubuntu, including for
instance Apport and PulseAudio.

I feel that Canonical runs Kubuntu without the right amount of
attention it could provide, which is also very evident in the
promotion sector. While I am not a packager (I'm a KDE application
developer), I do offer to help out with this project where I can,
including giving technical advice, or providing other work (for
example promotion). Naturally my personal focus is also on improving
the environment for developers, e.g. by adding current versions of
important development tools, such as Qt Creator.

--
Mark Kretschmann
Amarok Developer
www.kde.org - amarok.kde.org

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 11-03-2009, 09:39 PM
Scott Kitterman
 
Default Project Timelord -- Initial consideration

On Tue, 3 Nov 2009 08:58:18 +0100 Mark Kretschmann <kretschmann@kde.org>
wrote:
>On Tue, Oct 20, 2009 at 9:21 PM, Jonathan Thomas <echidnaman@gmail.com>
wrote:
>> Hello fellow Kubuntu developers,
>>
>> Kubuntu, as we know, is a fairly good KDE distribution. (Otherwise we
would
>> not be here reading this mailing list) However, things are not perfect.
In
>> fact, things could be much better.
>>
>> "But what is Project Timelord?", you may ask, "and how does it relate to
>> Kubuntu's problems?" Both are good questions. Project Timelord is the
>> brainchild of the Kubuntu developer legend Harald Sitter; the
culmination of
>> several weeks of brainstorming by a handful of Kubuntu developers,
focused
>> towards identifying problems Kubuntu currently faces and solutions for
these
>> problems.
>>
>> And now, we wish to bring Project Timelord to the attention of the
greater
>> Kubuntu development community for input. You can find the internal
developer
>> release announcement that outlines the purpose and proposed solutions of
>> Project Timelord at: http://docs.google.com/View?id=dfc7xjfj_18g8k5ztg4
>>
>> If it is decided that we would like to adopt Project Timelord as a goal
to
>> work towards over the next few cycles, we can start towards prioritizing
the
>> solutions and work towards forming a roadmap to implementing these
solutions.
>> This way we can all stay in the know of what is going on even if we are
unable
>> to attend UDS, and those attending UDS will have a unified goal to work
>> towards as they flesh out the implementation details for Kubuntu 10.04,
Lucid
>> Lynx.
>>
>> The purpose of this email is to generate discussion to determine whether
the
>> Kubuntu developer community wishes to adopt this plan or not, as well as
to
>> provide input on the brainstormed solutions. Until it is decided, we
would
>> politely ask you to not announce the existence of the project to the
general
>> public. We would like to hear your thoughts on the initiative here,
though.
>>
>> Thanks in advance,
>> Jonathan "JontheEchidna" Thomas.
>
>I'm a bit late in the game, but I would like to express my support for
>Project Timelord. While I think that we must be happy for the support
>that Canonical is giving Kubuntu, their level of support is limited,
>and it also also comes with lot of baggage from Ubuntu, including for
>instance Apport and PulseAudio.
>
>I feel that Canonical runs Kubuntu without the right amount of
>attention it could provide, which is also very evident in the
>promotion sector. While I am not a packager (I'm a KDE application
>developer), I do offer to help out with this project where I can,
>including giving technical advice, or providing other work (for
>example promotion). Naturally my personal focus is also on improving
>the environment for developers, e.g. by adding current versions of
>important development tools, such as Qt Creator.

One the development level, I think this improved significantly in this
cycle. Where we had transition problems (e.g.network manager API changes)
we had help from the larger Ubuntu development team. This has not been the
case in the past.

This isn't to say it couldn't still be better, but we should recognize the
progress.

In Kubuntu, the community has a lot more control over what gets done than
in Ubuntu. I, for one, would not want so much additional help from
Canonical that they changed that.

Scott K

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 11-04-2009, 12:58 PM
David Planella
 
Default Project Timelord -- Initial consideration

Hi all,

First of all, let me start with a word of thanks to all of you who've
participated in some way or another in translations on this cycle, be it
translators, developers, documenters, advocates or any other
contributors. You've done a truly rocking job, and I believe I can say
without a doubt that this release has been the best in translations so
far, with Kubuntu featuring the most visible results.

It's been my first complete cycle as UTC. I've learned a lot, and I'm
very proud of what we've achieved together. I probably can't make an
exhaustive list of what we've done, but here are some of the items we've
delivered:

* The UTC team at full swing. The team [1] has been building up,
learning, defining processes and at the same time doing awesome
work in administering and coordinating translations globally.
* The ubuntu-translations project. Born from an initiative
discussed at UDS, this project in Launchpad [2] has been
initially used as a central place to track and fix translation
issues. We've seen more translation bugs reported, triaged and
fixed than ever.
* Communication. More transparent processes, documentation and
regular communication and focus through meetings.
* UDS. We've seen a lot of good discussions on UDS, and this time
we're going to have even more content.
* Governance, best practices. Started an effort to define policies
and best practices in Ubuntu translations, with the intention of
achieving translations with the best quality around.
* Jams. Translation Jams are from now on a regular feature of the
Ubuntu Global Jam.
* Translation Days. We've kicked off the Kubuntu Translation Days,
to give some love to the distro's translations.

For me, this is just the beginning. We've started with a great
foundation to build upon, and make Kubuntu and Ubuntu the distros with
best translations around.

I've read the Project Timelord's goals with interest, and I'm glad to
see that translations are a major focus. With all said, what strikes me
is that there has been no communication with the translations teams
before drafting such a proposal. Although developers do have a great
deal of interaction with Rosetta, it is ultimately a tool for
translators, and I consider it very important that they have their say
on this as well. On that question, I greatly appreciate the "The
ultimate decision will be left to the translation community" point in
the Solution section of the document.

At the risk of being repetitive, I'll mention again that I'm very proud
on the path we've started for communication between the several actors
involved (Kubuntu developers, Translations Community, Launchpad
Translations developers, Ubuntu developers), which I think is key in
solving a great deal of the issues.

We've got quite a lot of communication channels available (translations
meetings, UDS, ubuntu-translators and ubuntu-translations-coordinators
ML, #ubuntu-translators, #launchpad, #launchpad-dev) and I would like to
see all of us involved in translations to more actively use those which
normally fall outside of our day-to-day communities.

I'd also like to comment on some particular points of the proposal:

"most of the bugs where Launchpad Translations breaks upstream
translations have been fixed; as far as we know."

There are a lot of translation bugs, which are not exclusive to
Launchpad Translations. Since KDE switched to using the standard gettext
we've had less and less problems, and I believe this cycle has been
particularly good in terms of not having big infrastructural bugs. There
are many other types of bugs affecting Kubuntu translations: packaging,
translations themselves and yes, sometimes there are also mistakes in
upstream translations [3]. I agree with Riddell that QA is a point which
still needs much improvement, but what have been the particular issues
in this release which have made you want to stop using Launchpad for
translations?

"the current levels of Kubuntu developer and translator resources are
insufficient to reap the intended benefits of the system, much less fix
what goes wrong. Kubuntu modifications to applications do not get
translated in most of our supported languages due to a virtually
nonexistent Kubuntu translation team. This lack of resources also leaves
us unable to perform quality assurance on any languages other than the
one or two major languages translations-minded Kubuntu developers can
keep an eye on"

This is true, but it is also getting traction. I've had several
questions from different Ubuntu translation teams to promote and better
document the Kubuntu translation process, because they'd like to
translate Kubuntu. It is difficult sometimes for the UTC team as well,
because it is an involved process, but we've already started a
documentation effort [4], to be further expanded (help appreciated)
which should help on that aspect.

"A great part of the reason we do not have Kubuntu translators is that
in the past translations have been abysmal, depsite the hard work of the
Kubuntu translators. We lost entire languages-worth due to this. The
other part of the reason is the Launchpad Translations interface
itself."

I totally agree on that. And improving that is I believe what we are
working towards.

"Through chats with KDE translators on the KDE translators mailing list
and elsewhere, we have found that the use of Rosetta is a major
dealbreaker for getting them to help with our translations. One thing is
clear; to get a translations community we must make it as convenient as
possible for existing translators to contribute, and currently
translators have expressed their disinterest in the Launchpad
Translations interface."

Some of the concerns related to the particular point of using Launchpad
for translation I've heard have mostly to do with the interface
(although anyone not happy with the interface can download the PO files
and translate in the "classical" way), Launchpad not being Open Source
(does no longer apply) and Kubuntu translators modifying upstream
translations. Although we do still have issues, translation teams have
got a lot better in reviewing translations and using moderated policies
to control who can modify strings. They have also got resources on how
to get in touch and work with KDE upstream [5]. Finally, You are talking
of upstream translators, but I think we should not exclude Kubuntu
translators, which do have an interest in translating through Launchpad.

El dv 23 de 10 de 2009 a les 10:09 +0200, en/na Harald Sitter va
escriure:
>
> Using Rosetta is difficult from a maintenance POV. I think I outlined
> all concerns in a document that is yet to be published, so I will not
> state them right now, but to sum it up: we are always one step behind
> upstream, we are always one step behind Ubuntu, 95% of the cycle no
> one gives a crap, bugs fall through the cracks unless the UTC catch
> them, the translation quality is at times worse than what upstram got.

We do care about translation bugs, be it in Ubuntu or Kubuntu, and we
work hard at triaging and fixing them, or poking the relevant developers
to look at them. The ubuntu-translations project has helped a lot in not
letting translation bugs fall through the cracks in this cycle.
JohntheEchidna in particular (thanks!) has been rocking in assigning bug
tasks to the ubuntu-translations project for Kubuntu translation bugs,
and notifying the UTC team about them.

When talking about quality, I think we should make a difference between
technical quality and translation quality per se. On the latter, we
should not forget that there are a lot of Ubuntu and Kubuntu translation
teams with the same or even stricter reviewing processes, who are
working hard to have quality translations as well.

In conclusion, I think it is perfectly valid to discuss whether the
Kubuntu community wants to stop using Launchpad Translations, but I
would strongly discourage you of doing that. Despite the issues we all
know, I do believe it is a great collaborative translation tool for
distributions and projects, and I believe adopting an alternative at
this point would not only be more time consuming but would also
significantly raise the entry barrier for translators. If the discussion
is to be going further, I'd like to see the translation communities also
involved, and a concrete plan on an alternative infrastructure to manage
the translations of Kubuntu modifications or specific applications. Most
especially, also consideration on how a new translation community would
be built around this. In any case, I would instead prefer to focus on
the great work we've been doing together on this cycle and build upon it
for further improvement.

Thanks.

Regards,
David.

[1] https://wiki.ubuntu.com/UbuntuTranslationsCoordinators
[2] https://launchpad.net/ubuntu-translations
[] https://bugs.launchpad.net/ubuntu-translations/+bug/460984
[4]
https://wiki.ubuntu.com/Translations/Upstream/KDE/KubuntuTranslationsLifecycle
[5] https://wiki.ubuntu.com/Translations/Upstream/KDE

--
David Planella
Ubuntu Translations Coordinator
david(dot)planella(at)ubuntu(dot)com
www.ubuntu.com



--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 

Thread Tools




All times are GMT. The time now is 06:41 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org