Re: Status of the shadow package
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): Christian: please NMU away. Sorry, it's likely I misunderstand that one sentence (not English native, remember..:-))). Does this mean I can NMU or rather you ask me to temporarily avoid NMU's? I've better asking (and look like the dumb English speaker I am) rather than making mistakes...:-) I will look into options for making the repository more available to you (and I should take a second look at alioth.) Alioth, or elsewhere, by the way. Alioth is more convenient for general commit access to d-i translators but this could also be cvs.debian.org Aliotht system administation has received some criticisms recently, even by some d-i contributorsso I would perfectly understand if you're not confident with Alioth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of the shadow package
Quoting Sam Hartman ([EMAIL PROTECTED]): If you were annoyed that it took too long to deal with translation NMUs then you probably should have asked for permission to make arbitrary 0-day NMUs for translation purposes. Hmmm, wel I think I did ask. At least, I announced all NMU's and took the lack of answer as an agreement. So, it may seem to you there's no problem. However, I'm not comfortable in doing NMU's without explicit agreement and keep this situation going on. This was basically the reason I mailed again Karl and you. But as far as I can tell, Karl has dealt with the non-translation problems in a reasonably timely manner over the past year, although perhaps not as fast as you would like in the last two months. Well, the non-l10n things are OK to me. One one my fears also wasthat these l10n NMU's require a lot of work for building the appropriate patches to unsure that any of you both working in parallel to another build, for non-l10n issues, can still be able to re-apply the changes I made in my NMU's. All 28.* NMU's were very huge and required a lot of work for building patches. This is what I would like to avoid by asking for some kind of co-maintenance. We are already working this way as, in the last 2 months, I made these l10n NMU's. The progress we can currently make is by using appropriate tools. A simple commit access to an existing CVS or SVN repository would highly help. See, for instance, the work done on aptitude or popularity-contest packages. With agreement of their respective maintainers, I'm currently dealing with all l10n-related issues : as soon as a l10n bug is reported, I verify it, apply it to the respository, update the debian/changelog file and mark the bug as pending. The maintainer(s) are still responsible with the package uploads and everyone is happy. I hope you'll get my point : basically offering the maintainers, that is you and Karl, a way to just forget about l10n issues -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of the shadow package
Nikolai Prokoschenko wrote: [snip] Strings may have the same english wording, but are sometimes translated differently, depending on the context. I hoped you'd ask :) I've asked this question some time ago: http://lists.debian.org/debian-i18n/2004/05/msg1.html and have got the answer: http://lists.debian.org/debian-i18n/2004/05/msg4.html If there should be difference in the translation the same reasoning would apply to the english strings - - seems to me that the right way to fix this is to change the english strings to be more clear. Which means you have to beg the upstream author to change to output of his program without apparent reason (for him). Why should he care about some random other program which happens to use the same string in a different context? So I assume, this should be no problem after all? I mean, even if it's the case, we'd have a fuzzy string in a merged translation file, which has been considered an error all along... AFAICS the translation database needs some means to find the preferred translation for a given package in addition to the matching english string. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of the shadow package
Thiemo Seufer wrote: Which means you have to beg the upstream author to change to output of his program without apparent reason (for him). Why should he care about some random other program which happens to use the same string in a different context? If it is a different program and in a different context, then the domain (the file the translation is read from) should be different too. If two different programs use the same domain, without coordinating, then they are messing up the whole i18n/l10n system anyway. AFAICS the translation database needs some means to find the preferred translation for a given package in addition to the matching English string. If the database contains domain, C string, language code and translated string, then there shouldn't be unsurmountable problems. Jacob -- There is nothing worse than having only one drunk head. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of the shadow package
Christian == Christian Perrier [EMAIL PROTECTED] writes: Christian Quoting Sam Hartman ([EMAIL PROTECTED]): If you were annoyed that it took too long to deal with translation NMUs then you probably should have asked for permission to make arbitrary 0-day NMUs for translation purposes. Christian Hmmm, wel I think I did ask. At least, I announced all Christian NMU's and took the lack of answer as an agreement. Christian So, it may seem to you there's no problem. However, I'm Christian not comfortable in doing NMU's without explicit Christian agreement and keep this situation going on. This was Christian basically the reason I mailed again Karl and you. OK. I have no authority with the package so we're both waiting for Karl to deal. It's my opinion though that your NMU work is very easy to integrate because you generate single patches that can be cleanly applied. It seems like one of the two following ideas would work going forward: * Give you permission to upload translations as NMUs immediately. * Move the repository to alioth or something else where you can be given commit access. If we don't here from Karl on his thoughts on these issues within a day or two, I'll ask him in person to read this. --Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of the shadow package
OK. I have no authority with the package so we're both waiting for Karl to deal. It's my opinion though that your NMU work is very easy to integrate because you generate single patches that can be cleanly applied. It seems like one of the two following ideas would work going forward: * Give you permission to upload translations as NMUs immediately. * Move the repository to alioth or something else where you can be given commit access. If we don't here from Karl on his thoughts on these issues within a day or two, I'll ask him in person to read this. --Sam Christian: please NMU away. I will look into options for making the repository more available to you (and I should take a second look at alioth.) kcr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of the shadow package
Christian Perrier [EMAIL PROTECTED] writes: Hello Karl and Sam, During Debconf4, there has been some discussions within the d-i team and some maintainers of Custom Debian Distributions (mostly Skolelinux) about the status of the Debian package for shadow. As you have obviously noticed, I have NMU'ed the package four times last month, mostly for l10n considerations. The installer team has built a strong team of translators which have all made a huge work for bringing a lot of translations to core d-i and the related packages, including shadow. And I thank you, it's been a mess. [Actually, this has been causing me to conclude that we probably need a mechanism whereby translators can cause new translations to appear outside of the structure of the package itself. This is basically why I did these NMUs. I also fixed one or two usability bugs in passwd.config but tried to be very conservative there...(not enough, indeed, as I managed to break it once) The discussions we had lead to the conclusion that closer attention needs to be done with this package. We're currently considering building a project on alioth for the package maintenance so that more people may help maintaining itwhich of course includes you both. It's been difficult scare up the moral necesary to give it that much attention recently given that I don't believe Debian is ever going to successfully release a new stable. This is not a takeoveror at least not yet (well, if we do not get any answer, you may imagine some takeover will happen)but a proposal for a wider collaborative maintenance which should probably benefit all of us. Well, no, if you tell a package maintainer that it has been decided that you're going to use infrastructure that the maintainer refuses to rely on, that is most certainly a takeover. Indeed, several people over there in Brazil told me just take over this package, Christian. I don't want to, for two reasons: Nice of them to share their opinion with me. -my shoulders are a bit not wide enough and I can't add all this weight on them...:-) -I certainly don't want to be rude in any matter towards you and a simple takeover *would* be rude Thank you. What is your feeling about this? If you run short of time, please just drop a very short word so that we can have an idea of where we currently are going I very much would have liked to be part of the initial discussion, but I couldn't afford to make it to debconf4. Really, I think the right approach is to throw away the shadow codebase and replace it with something that isn't such a tangles mess of #ifdefs. Thorsten Kukuk at/with/and/? Suse seems to have made a good start at fixing the infrastructure for this stuff; see http://www.thkukuk.de/pam/ kcr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of the shadow package
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): Well, no, if you tell a package maintainer that it has been decided that you're going to use infrastructure that the maintainer refuses to rely on, that is most certainly a takeover. Hmmm, the point that you don't want to use the Alioth infrastructure was indeed missing for me. Oherwise, we would have considered this in the discussions we had. So, please, do no understand it has been decided that. The only conclusion at this time is that we highly depend on this package...:-) BTW, I've just seen Ruben report about the missing spanish translationsLooks like the i10n part needs some more work. I finally found a way to better handle the inclusion of gmo files from upstream without editing too much files. We're still left with some additionnal man pages which don'tmake it into the debs, however Indeed, my current concern is mostly the l10n handling. As the package is part of d-i statistics, translators are very active on it as you may have seen. So, at least an easier way for us/them to commit their work would highly help. I already do l10n commits for several d-i related packages (aptitude, popularity-contest...) and one more wouldn't be that much work. The proposal for alioth-maintained package was mostly because all d-i translators already have commit accounts there, which would help going further by giving them commit access the way we do in the d-i core project. You seem to be a bit disappointed about the way Debian is currently going, mostly because of release issue. I may understand this feeling of coursebut this shouldn't probably prevent all of us to take care of the current work. For sure, the shadow codebase is maybe messy (I don't have for skills for having a good advice on this and certainly not for a rewrite), but it is currently part of the whole systemso though a rewrite is maybe a way to explore, it will certainly be a long trip before it may replace the current code. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of the shadow package
I fail to see the problem here. The shadow package has needed a lot of translation work. You've done that work, you've done the NMUs. Everyone is happy. If you were annoyed that it took too long to deal with translation NMUs then you probably should have asked for permission to make arbitrary 0-day NMUs for translation purposes. But as far as I can tell, Karl has dealt with the non-translation problems in a reasonably timely manner over the past year, although perhaps not as fast as you would like in the last two months. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of the shadow package
On Fri, Jun 04, 2004 at 01:29:19PM -0400, [EMAIL PROTECTED] wrote: [Actually, this has been causing me to conclude that we probably need a mechanism whereby translators can cause new translations to appear outside of the structure of the package itself. This seems to me like an interesting idea considering a debian-l10n framework. It would be interesting to see some script called update-l10n (just like update-flashplugin and update-msttcorefonts), which would fetch the updated translations. I see following improvements: - Translations are not a part of the package anymore, so they can be a) worked on and b) released independently - The system could get more and more translated, even a stable one - imagine a computer class somewhere in India, which runs stable, has been completely English at the moment of installation and gets more and more translated after some Hindi translators have been found. - We will have no l10n-uploads anymore - I'm sitting on a 2 MBit/s DSL-channel and I'm sometimes really pissed off by my daily sid update logs, which tell me that some 10-MiB package has been only downloaded to update some debconf templates for the languages I never use anyway. - Flexibility considering installed languages - I can choose the languages I want (/me thinks of kde-i18n-* - NO, I DO NOT want *such* bundled packages, it must be more flexible). Drawbacks I see at the moment (Christian will most probably see thousands more ;)): - Organization. This method would presume that all translations are handled in the same way, most probably with some kind of big database of strings (I have some ideas for this database which I'll post later on, so it's not really a drawback to me ;)) - Distribution: how do we distribute initial translations (e.g. on a CD) and how do we update them effectively? What if no net access is given? (solvable) - If we integrate upstream templates (i.e. program translations), how do we synchronise with upstream? (tricky) -- Nikolai Prokoschenko [EMAIL PROTECTED] / Jabber: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of the shadow package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 04 June 2004 23:32, Nikolai Prokoschenko wrote: On Fri, Jun 04, 2004 at 01:29:19PM -0400, [EMAIL PROTECTED] wrote: Drawbacks I see at the moment (Christian will most probably see thousands more ;)): Another point that needs to be considered is version control between releases: the stable distribution needs different translations from testing and unstable. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAwO25gm/Kwh6ICoQRAhk1AKCUYitDD0h4f09N7wiPWIbYnPNneACePap8 2eAgPxBfq5cTAeWlPAZIks4= =zWNV -END PGP SIGNATURE-
Re: Status of the shadow package
On Fri, Jun 04, 2004 at 11:46:33PM +0200, Frans Pop wrote: Drawbacks I see at the moment (Christian will most probably see thousands more ;)): Another point that needs to be considered is version control between releases: the stable distribution needs different translations from testing and unstable. My idea of the whole includes that big database of strings, which will include the extracted strings from packages' .pot-files. That also means, that we can extract the strings from each distribution - if they are equal - good, translators won't have much work. If they are different, the strings are then added to the database and can get translated. Any greater problem I'm missing? ;) -- Nikolai Prokoschenko [EMAIL PROTECTED] / Jabber: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of the shadow package
Nikolai Prokoschenko wrote: On Fri, Jun 04, 2004 at 11:46:33PM +0200, Frans Pop wrote: Drawbacks I see at the moment (Christian will most probably see thousands more ;)): Another point that needs to be considered is version control between releases: the stable distribution needs different translations from testing and unstable. My idea of the whole includes that big database of strings, which will include the extracted strings from packages' .pot-files. That also means, that we can extract the strings from each distribution - if they are equal - good, translators won't have much work. If they are different, the strings are then added to the database and can get translated. Any greater problem I'm missing? ;) Strings may have the same english wording, but are sometimes translated differently, depending on the context. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of the shadow package
On Sat, Jun 05, 2004 at 12:03:55AM +0200, Thiemo Seufer wrote: Drawbacks I see at the moment (Christian will most probably see thousands more ;)): Another point that needs to be considered is version control between releases: the stable distribution needs different translations from testing and unstable. My idea of the whole includes that big database of strings, which will include the extracted strings from packages' .pot-files. That also means, that we can extract the strings from each distribution - if they are equal - good, translators won't have much work. If they are different, the strings are then added to the database and can get translated. Any greater problem I'm missing? ;) Strings may have the same english wording, but are sometimes translated differently, depending on the context. I hoped you'd ask :) I've asked this question some time ago: http://lists.debian.org/debian-i18n/2004/05/msg1.html and have got the answer: http://lists.debian.org/debian-i18n/2004/05/msg4.html If there should be difference in the translation the same reasoning would apply to the english strings - - seems to me that the right way to fix this is to change the english strings to be more clear. So I assume, this should be no problem after all? I mean, even if it's the case, we'd have a fuzzy string in a merged translation file, which has been considered an error all along... -- Nikolai Prokoschenko [EMAIL PROTECTED] / Jabber: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
