Re: Bug#378404: installation guide: one more additional proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frans Pop wrote: On Friday 21 July 2006 14:57, Geert Stappers wrote: * Why leave typos in the original text? Why should translators all see (or ignore) the same typo? Because updating it now would force _all_ translators to update their translation again. A freeze is exactly to avoid that. I am sure that for such a change (typo) the translations can be unfuzzied (I don't know how this should be done for pure XML translations, but I suspect it can be done ;-). - -- Regards, EddyP = Imagination is more important than knowledge A.Einstein -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEwe6pY8Chqv3NRNoRApmyAKCmk8b/TKwxvcRCCYIG6NbnoyZ0ZgCg4XQt AE0Qkd8/lz8qpPdMkdmKybI= =7dbD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#378404: installation guide: one more additional proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Jul 21, 2006 at 06:23:19PM +0200, Frans Pop wrote: On Friday 21 July 2006 14:57, Geert Stappers wrote: What I don't get is the long term policy. I only have questions about it. * Would a state flag help to indicate a status like a freeze? So that when a 'update translations' message is skipped/missed/whatever there is still the state flag. Perhaps also include that flag in /topic? Do you honestly mean you would really have looked for a state flag? Such things only work if everybody knows where to look for them and I doubt there is one location that would work for that. Important is to realize that a project has sideline contributors. Slapping them with a URL like http://lists.debian.org/debian-boot/2006/07/msg00405.html implies a demand that _all_ mailinglist message should be read by them. Cluebatting a sideline contributor with a URL like http://wiki.debian.org/DebianInstaller/#State will stick better. /topic IMO abused enough already and will only get too long and unreadable when stuff like this is added. Fine. It's much better that _you_ take the responsibility to know what you are doing before doing it instead of just going ahead because it looks easy. That changed the tone from Only full-time hardcore contributors needed into sideline contributors should find their way in the project Probably was / is the whole E-mail about Do it better. That I did read last warning, my gun is aimed at you, no understanding for mistakes, you have failed before is my problem, my point of view. * How much revert work was/is needed after a considered harmless Hey, this patch shouldn't be ignored action? Telling all the things that need to be done for a cleanup, shows how much harm actually was done. Because it is fairly complex and requires a real understanding of the build system, the way translators work and revision versioning. The only way to learn about that is to really get involved yourself, not by me providing simplistic recipes. A question like How much revert work? could be answered with: | * find out the previous version of the file | * get time stamp information from that version. | * revert the change | * apply time stamp information on it | * inject the original version into the repository | * notify all the translators about a to be expected hickup | | All of this revert work could have been avoided with: | Why is this easy patch ignored for 36 hours? * What about a Hey, you created this mess, follow the procedure at URL to clean it up approach? Or Your action harmed this list of people, say sorry to them? Or another thing that has much learning in itself. The problem as I see it is that your involvement with d-i is only on the sidelines. You are not involved or committed enough to anything so that you know the status _because_ you are involved. Instead you pick things that look easy and do them without considering the consequences. That misses Or another thing that has much learning in itself. If the lesson was Do nothing breaks nothing, then it was a sad lesson. Cheers Geert Stappers -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEwgTTOSINbgwa/7sRAqOBAKColRZD4Od4d1UybXF8ikMR+psekwCfd2tX LPCtp/NGz6dyGvE/XFVs8vs= =6voM -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#378404: installation guide: one more additional proposal
On Sat, Jul 22, 2006 at 12:58:27PM +0200, Geert Stappers wrote: On Fri, Jul 21, 2006 at 06:23:19PM +0200, Frans Pop wrote: Important is to realize that a project has sideline contributors. I fully agree! I really well remember comments like: do not touch it at all even for such simple stuff as fixing typos and unfuzzying translations. And now he really does not want to even release slightly outdated translation, without even explaining the reasons. [1], [2] Maybe there exist reasons for this, but as long they are not published the do not count! It's much better that _you_ take the responsibility to know what you are doing before doing it instead of just going ahead because it looks easy. Maybe it's much better, but we all make errors and we would learn a lot during the attempt to fix it. A rule similar to Once you make it wrong (or even try it), I will revoke your SVN access is one of the worst solutions I can imagine. Why haven't you, Frans, not just explained the reason and let Geert, or anyone else who wants (e.g. me) fix it (by unfuzzying translations)? * How much revert work was/is needed after a considered harmless Hey, this patch shouldn't be ignored action? Telling all the things that need to be done for a cleanup, shows how much harm actually was done. Because it is fairly complex and requires a real understanding of the build system, the way translators work and revision versioning. The only way to learn about that is to really get involved yourself, not by me providing simplistic recipes. But you do not allow to get involved, did you forgot this? Jens [1] http://lists.debian.org/debian-i18n/2006/07/msg00095.html [2] http://lists.debian.org/debian-i18n/2006/07/msg00096.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#378404: installation guide: one more additional proposal
On Saturday 22 July 2006 12:58, Geert Stappers wrote: A question like How much revert work? could be answered with: | * find out the previous version of the file | * get time stamp information from that version. | * revert the change | * apply time stamp information on it | * inject the original version into the repository | * notify all the translators about a to be expected hickup As I said before, it is not so simplistic. Unfuzzying as Eddy mentioned is possible, just not very easy. There is also avoiding unnecessary daily builds for unfuzzied languages, which is something only I can do as I do the daily builds. | All of this revert work could have been avoided with: | Why is this easy patch ignored for 36 hours? It was not ignored, it was just not applied. If the lesson was Do nothing breaks nothing, then it was a sad lesson. No, the lesson was: make sure you no harm by talking to the person who is normally responsible _before_ committing random stuff instead of making assumptions that turn out false and thus creating extra work for that person. You could have asked: is there a reason this easy patch was not applied, either on IRC or private mail by me. You did write a comment on IRC and I did see it. Problem is that you did not highlight me _and_ you did not wait for an answer. I have no objection to people helping out, but I much prefer if they do it right over creating extra work for others. I also don't mind cleaning up sometimes if someone makes an honest mistake. What I do get a bit pissed about is the same person making similar mistakes several times. You did the same (committing to the manual during a freeze) before [1] and the recent uncoordinated upload of quik-installer was similar. [1] http://lists.debian.org/debian-boot/2006/04/msg00744.html r36614 | fjp | 2006-04-22 14:15:53 +0200 (Sat, 22 Apr 2006) | 1 line Revert commit from stappers r36613 | stappers | 2006-04-22 13:24:27 +0200 (Sat, 22 Apr 2006) | 2 lines added '--initrd' as reported by Daniel Schellhammer to [EMAIL PROTECTED] pgpZ0TtWtdnJT.pgp Description: PGP signature
Re: Bug#378404: installation guide: one more additional proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Jul 20, 2006 at 02:54:14PM +0200, Frans Pop wrote: On Thursday 20 July 2006 11:37, Geert Stappers wrote: On Tue, Jul 18, 2006 at 11:23:13PM +0200, Holger Wansing wrote: --- partman-crypto.xml2006-07-09 21:21:07.0 +0200 +++ partman-crypto.xml.workingcopy2006-07-18 -First, let's have a look at available options available when you +First, let's have a look at the options available when you That is applied. As was announced in [1], the manual us currently frozen for its next release. This means _no_ commits to the English original. Because of that I have reverted this commit (and had to do several other things to minimize the effect on the status of translations). I will apply the patch again _after_ the release. Geert, I know your intentions are good, but unfortunately this is not the first time commits by you to the SVN repository cause more work than that they help. Please do not do random things you pick up from the mailing lists just because you think hey, I can do this when there are normally other people who take care of them _before talking to those other people_. The next time something like this happens, I will be forced to revoke your commit access to the repository. Cheers, FJP [1] http://lists.debian.org/debian-boot/2006/07/msg00405.html I understand only the short term message. [2] What I don't get is the long term policy. I only have questions about it. * How to tag a bugreport like #378404 with 'fix after string freeze' * Why leave typos in the original text? Why should translators all see (or ignore) the same typo? * Why leave out additions like 'or userinputfb=true/userinput for short.' from the original text? Why not allow the improvement in the translations. * Why a very very strict string freeze? ( Proposal: allow the Release Manager to modify strings during a freeze ) * Would a state flag help to indicate a status like a freeze? So that when a 'update translations' message is skipped/missed/whatever there is still the state flag. Perhaps also include that flag in /topic? * How much revert work was/is needed after a considered harmless Hey, this patch shouldn't be ignored action? Telling all the things that need to be done for a cleanup, shows how much harm actually was done. * What about a Hey, you created this mess, follow the procedure at URL to clean it up approach? Or Your action harmed this list of people, say sorry to them? Or another thing that has much learning in itself. My appology for the harm I did. Geert Stappers [2] Nevertheless the good reason you had for your action, the impact wasn't that good. Because there are no resources to explain what went wrong, it is chosen to kick _you_ out, it will prevent further harm from _you_. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEwM82OSINbgwa/7sRAu/AAJ0SXw69Xfle0/T+/x/dqVa7AQdvNwCeJUQo 4HXDr8W6ttzKv/dq47wLIm4= =F4Lo -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378404: installation guide: one more additional proposal
On Thu, Jul 20, 2006 at 11:37:37AM +0200, Geert Stappers wrote: On Tue, Jul 18, 2006 at 11:23:13PM +0200, Holger Wansing wrote: --- partman-crypto.xml 2006-07-09 21:21:07.0 +0200 +++ partman-crypto.xml.workingcopy 2006-07-18 -First, let's have a look at available options available when you +First, let's have a look at the options available when you That is applied. And reverted, due freeze of the manual -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#378404: installation guide: one more additional proposal
On Friday 21 July 2006 14:57, Geert Stappers wrote: I understand only the short term message. [2] What I don't get is the long term policy. I only have questions about it. * How to tag a bugreport like #378404 with 'fix after string freeze' You don't. I have it in my post-freeze TODO list. Which is part of my job as RM for the installation guide. * Why leave typos in the original text? Why should translators all see (or ignore) the same typo? Because updating it now would force _all_ translators to update their translation again. A freeze is exactly to avoid that. * Why leave out additions like 'or userinputfb=true/userinput for short.' from the original text? Why not allow the improvement in the translations. Same. * Why a very very strict string freeze? ( Proposal: allow the Release Manager to modify strings during a freeze ) Same. * Would a state flag help to indicate a status like a freeze? So that when a 'update translations' message is skipped/missed/whatever there is still the state flag. Perhaps also include that flag in /topic? Do you honestly mean you would really have looked for a state flag? Such things only work if everybody knows where to look for them and I doubt there is one location that would work for that. /topic IMO abused enough already and will only get too long and unreadable when stuff like this is added. It's much better that _you_ take the responsibility to know what you are doing before doing it instead of just going ahead because it looks easy. * How much revert work was/is needed after a considered harmless Hey, this patch shouldn't be ignored action? Telling all the things that need to be done for a cleanup, shows how much harm actually was done. Because it is fairly complex and requires a real understanding of the build system, the way translators work and revision versioning. The only way to learn about that is to really get involved yourself, not by me providing simplistic recipes. * What about a Hey, you created this mess, follow the procedure at URL to clean it up approach? Or Your action harmed this list of people, say sorry to them? Or another thing that has much learning in itself. The problem as I see it is that your involvement with d-i is only on the sidelines. You are not involved or committed enough to anything so that you know the status _because_ you are involved. Instead you pick things that look easy and do them without considering the consequences. Another example is the cloning of Rick's installation report today over the lspci issue: - you cloned it without reassigning it, so it is still lost in the mountain of installation reports - the reason you did not reassign it is probably because you have no clue where to reassign it - just cloning a BR like this does not really help the project; what _would_ help is doing some research: - can you reproduce the problem - it used to be installed in earlier images, so what used to be responsible for that This should give you enough information to reassign it properly with a suggested solution. Note though that installing lspci in the installed system is not so necessary anymore as current installation images already save the lspci info in /var/log/installer as part of the finish install step, or whenever the user selects save logs. pgpeHVHk4xDex.pgp Description: PGP signature
Bug#378404: installation guide: one more additional proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Jul 18, 2006 at 11:23:13PM +0200, Holger Wansing wrote: --- partman-crypto.xml2006-07-09 21:21:07.0 +0200 +++ partman-crypto.xml.workingcopy2006-07-18 -First, let's have a look at available options available when you +First, let's have a look at the options available when you That is applied. (The changes for the boot-installer.po not ) Cheers Geert Stappers P.S. Holger Wansing: Thanks for the patch and especial for bringing #378404 to our attention. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEv07gOSINbgwa/7sRAq46AJ9ve11yoP3TYhvyojpvaTFsyqGWFQCcDjh0 IuolirtX+5wLnYJAFx6QAzA= =/mPh -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#378404: installation guide: one more additional proposal
On Thursday 20 July 2006 11:37, Geert Stappers wrote: On Tue, Jul 18, 2006 at 11:23:13PM +0200, Holger Wansing wrote: --- partman-crypto.xml 2006-07-09 21:21:07.0 +0200 +++ partman-crypto.xml.workingcopy 2006-07-18 -First, let's have a look at available options available when you +First, let's have a look at the options available when you That is applied. As was announced in [1], the manual us currently frozen for its next release. This means _no_ commits to the English original. Because of that I have reverted this commit (and had to do several other things to minimize the effect on the status of translations). I will apply the patch again _after_ the release. Geert, I know your intentions are good, but unfortunately this is not the first time commits by you to the SVN repository cause more work than that they help. Please do not do random things you pick up from the mailing lists just because you think hey, I can do this when there are normally other people who take care of them _before talking to those other people_. The next time something like this happens, I will be forced to revoke your commit access to the repository. Cheers, FJP [1] http://lists.debian.org/debian-boot/2006/07/msg00405.html pgpbQcL1yCtXk.pgp Description: PGP signature
Bug#378404: installation guide: one more additional proposal
--- partman-crypto.xml 2006-07-09 21:21:07.0 +0200 +++ partman-crypto.xml.workingcopy 2006-07-18 16:29:09.0 +0200 @@ -62,7 +62,7 @@ /parapara -First, let's have a look at available options available when you +First, let's have a look at the options available when you select userinputDevice-mapper (dm-crypt)/userinput as the encryption method. As always: when in doubt, use the defaults, because they have been carefully chosen with security in mind. Best Holger -- == Created with Sylpheed 2.2.2 under Debian GNU/LINUX 3.1 »Sarge« http://counter.li.org/, Registered LinuxUser #311290 Spamfiltering by bogofilter.sourceforge.net = -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
