Re: Post-woody
* Chris Tillman | sure. Note that this is part of the ?consistency and polish? thing, | it's not needed for d-i to actually be able to do it's work. It's | needed in order not to confuse the user. | | My .02: By definition the installer is most new users' first contact | with Debian. We should not consider it to be 'working' if it confuses | the user. I totally agree, and I see that it was easy to misunderstand what I meant. I am not trying to say that the user experience is low priority, rather the reverse. However, some basic things have to be in place before we can begin to test usability in a sane manner. We can't use a easy-to-use installer which doesn't install anything and any testing will in reality be void. Having an installer with a bad UI still allows us to test whether the programs work as they should. (Things like having DEBCONF_DEBUG=5 in /sbin/debian-installer is a HCI nightmare, but it's there for debugging until d-i gets a bit more stable. :) I hope this clears things up. | Also, from a purely software engineering perspective, it's much easier | to build in a hook you don't need now than to retrofit a capability | you knew you needed later. IMHO at this point we should be building | as many hooks as possible, since this code will undoubtedly have a | life of many years. true. still, saying that «all frontends must be i18n-ed» now is a bit early, though we want to arrive there in the end. :) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
* Junichi Uekawa | Tollef Fog Heen [EMAIL PROTECTED] immo vero scripsit: | | | Are you saying that every debconf template file should be in UTF-8? | | How do you propose to accomplish the transition ? | | Every debconf template which is used in d-i, yes. Why not? It | shouldn't be that many templates. The others can be handled when the | time is due. | | Last time I looked, there is no charset signifier in | debconf templates, how does one know if the template is in | utf-8 or euc-jp? You don't need to do that if we decide that everything is utf8. And since d-i won't have umpteen packages it's not very much work to fix any non-conforming packages. Fixing it for the general case should be done, but is a lot more work. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
* (Denis Barbier) | I do not understand your answer, sorry. ok, we'll try again. :) | Consider the cvs/pserver template from cvs.templates: | Template: cvs/pserver | Type: boolean | Default: false | Description: Should the CVS pserver be enabled? | [...] |CVS pserver will be installed in inetd, using tcpd wrappers if you answer |yes to this question. | | As a translator, I cannot decide whether the 'yes' word has to be translated | or not, because button label depends upon the selected frontend, it might be | either 'yes' or its translation. I understand. | For instance whiptail is not i18n-ed, so when a German user has selected | dialog frontend, he is told to click on the 'Ja' button which does not exist! | In order to avoid this annoyance, I suggested to only accept i18n-ed | frontends. sure. Note that this is part of the «consistency and polish» thing, it's not needed for d-i to actually be able to do it's work. It's needed in order not to confuse the user. so, for the release, we want the frontends to be i18n-ed. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
On Tue, 2002-05-28 at 12:39, Tollef Fog Heen wrote: * Junichi Uekawa | Last time I looked, there is no charset signifier in | debconf templates, how does one know if the template is in | utf-8 or euc-jp? You don't need to do that if we decide that everything is utf8. And since d-i won't have umpteen packages it's not very much work to fix any non-conforming packages. Fixing it for the general case should be done, but is a lot more work. So, just to be clear, you're saying that all the debconf templates used by debian-installer are provided exclusively for its use (ie they are never used by packages that the user might install under any other circumstances)? p. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
* Philip Blundell (please respect my mail-followup-to) | On Tue, 2002-05-28 at 12:39, Tollef Fog Heen wrote: | * Junichi Uekawa | | Last time I looked, there is no charset signifier in | | debconf templates, how does one know if the template is in | | utf-8 or euc-jp? | | You don't need to do that if we decide that everything is utf8. And | since d-i won't have umpteen packages it's not very much work to | fix any non-conforming packages. Fixing it for the general case | should be done, but is a lot more work. | | So, just to be clear, you're saying that all the debconf templates used | by debian-installer are provided exclusively for its use (ie they are | never used by packages that the user might install under any other | circumstances)? Sorry if this gets too basic, but I am switching to teaspoon mode since it seems like I'm not able to get the message across. The units we are working with in debian-installer are udebs (really µdebs). They are debian packages, but they don't have to follow policy (why would we want docs and man pages on the installation media?). Those packages might include templates, like other debian packages. Since the set of packages in d-i and outside d-i is distinct it won't be a problem if we decide to migrate the templates in d-i before we migrate the templates in the rest of debian. The maintainer might have to maintain both utf8 and non-utf8 templates until we have changed debconf over to utf8. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
On Tue, May 28, 2002 at 01:42:28PM +0200, Tollef Fog Heen wrote: * (Denis Barbier) | I do not understand your answer, sorry. ok, we'll try again. :) | Consider the cvs/pserver template from cvs.templates: | Template: cvs/pserver | Type: boolean | Default: false | Description: Should the CVS pserver be enabled? | [...] |CVS pserver will be installed in inetd, using tcpd wrappers if you answer |yes to this question. | | As a translator, I cannot decide whether the 'yes' word has to be translated | or not, because button label depends upon the selected frontend, it might be | either 'yes' or its translation. I understand. | For instance whiptail is not i18n-ed, so when a German user has selected | dialog frontend, he is told to click on the 'Ja' button which does not exist! | In order to avoid this annoyance, I suggested to only accept i18n-ed | frontends. sure. Note that this is part of the ?consistency and polish? thing, it's not needed for d-i to actually be able to do it's work. It's needed in order not to confuse the user. My .02: By definition the installer is most new users' first contact with Debian. We should not consider it to be 'working' if it confuses the user. Also, from a purely software engineering perspective, it's much easier to build in a hook you don't need now than to retrofit a capability you knew you needed later. IMHO at this point we should be building as many hooks as possible, since this code will undoubtedly have a life of many years. -- *--v- Installing Debian GNU/Linux 3.0 v--* | http://www.debian.org/releases/woody/installmanual | | debian-imac (potato): http://debian-imac.sourceforge.net | |Chris Tillman[EMAIL PROTECTED] | | May the Source be with you | ** -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
Tollef Fog Heen [EMAIL PROTECTED] immo vero scripsit: The units we are working with in debian-installer are udebs (really policy (why would we want docs and man pages on the installation media?). Ah good. I forgot about udebs. The maintainer might have to maintain both utf8 and non-utf8 templates until we have changed debconf over to utf8. I think we really need to migrate from calling things like Description-ja_JP: to: Description-ja_JP.utf-8: The automatic conversion from native code to utf-8 support could be built into debconf-mergetemplate. Thoughts, joeyh? -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
Denis Barbier wrote: Consider the cvs/pserver template from cvs.templates: Template: cvs/pserver Type: boolean Default: false Description: Should the CVS pserver be enabled? [...] CVS pserver will be installed in inetd, using tcpd wrappers if you answer yes to this question. As a translator, I cannot decide whether the 'yes' word has to be translated or not, because button label depends upon the selected frontend, it might be either 'yes' or its translation. This is just an example of a bad template description. With some frontends you don't answer yes at all; you click on a check box or something. That's why template descriptions should avoid any references to the UI. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
* Joey Hess | Tollef Fog Heen wrote: | | As you may or may not know, I will no longer have a position of | | responsibility in the installation system after Woody. Joey Hess has | | volunteer for this position, or at least he did about 18 months ago. | | I assume he's still for it -- hopefully the folks on this list agree | | with that. | | Joey has offered me the position of technical lead on d-i, since he | has too many other things taking up his time, and I have said yes. | Assuming that nobody has any big objections, that is. | | I think that Tollef has been doing a great job already lately, and it's | only fair that he should be saddled with it officially. :-) I will | continue to participate with d-i of course, especially in helping with | design issues and the parts I am the maintainer of. Thanks. :) [...] | It feels to me like a recipe for putting us in exactly the position | we're in now, a year or however long later, once sarge has released. We | have to work on d-i *sometime*, and now is clearly the time. I feel that way as well, if we don't do it now, then when? | Of course I share aph's worries, particularly when all the architectures | are taken into account. absolutely. I have no idea what the problems we'll see on those archs which are very unlike PCs, like s/390. Feedback about possible problems would be appreciated. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
* Junichi Uekawa | Last time I checked (which is a long long time ago), debconf had a | design problem with utf-8 (the debconf templates are not in utf-8, | and it is not automatically obvious which character code they are in). | Does cdebconf inherit the same problem? Does it convert to utf-8 on the | fly? The charset in the templates are undefined, but if we decide that we want it to be UTF-8 then that won't be a problem. (Just a small policy decision.) The frontend would have to know how to convert it into something which displays properly, though. Does anybody have a problem with having the templates in UTF8? | What is a bogl frontend ? Is it very different from newt-utf8 that | boot-floppies uses? : tfheen@arabella ..heen/debian-installer/doc apt-cache show bogl-bterm Package: bogl-bterm [...] Description: Ben's Own Graphics Library - graphical terminal Ben's Own Graphics Library is a small framebuffer library, including basic widgets, support for text in multiple languages, and mouse handling. . This package contains bterm, a utf-enabled framebuffer terminal. Right now there is a ncurses and a slang frontend, I am not sure of the state of those, but it should be possible to link the better of them against something-utf8 or create a newt-utf8 frontend. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
On 27 May 2002 13:29:35 +0200 Tollef Fog Heen [EMAIL PROTECTED] wrote: The charset in the templates are undefined, but if we decide that we want it to be UTF-8 then that won't be a problem. (Just a small policy decision.) The frontend would have to know how to convert it into something which displays properly, though. Does anybody have a problem with having the templates in UTF8? Are you saying that every debconf template file should be in UTF-8? How do you propose to accomplish the transition ? -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
* Junichi Uekawa | On 27 May 2002 13:29:35 +0200 | Tollef Fog Heen [EMAIL PROTECTED] wrote: | | The charset in the templates are undefined, but if we decide that we | want it to be UTF-8 then that won't be a problem. (Just a small | policy decision.) The frontend would have to know how to convert it | into something which displays properly, though. | | Does anybody have a problem with having the templates in UTF8? | | Are you saying that every debconf template file should be in UTF-8? | How do you propose to accomplish the transition ? Every debconf template which is used in d-i, yes. Why not? It shouldn't be that many templates. The others can be handled when the time is due. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
On Mon, May 27, 2002 at 01:29:35PM +0200, Tollef Fog Heen wrote: [...] Right now there is a ncurses and a slang frontend, I am not sure of the state of those, but it should be possible to link the better of them against something-utf8 or create a newt-utf8 frontend. It would also be desirable to only support i18n-ed frontends, having English text (Yes/No/Back/Cancel etc.) in buttons is confusing: translators do not know if they have to write English or translated strings in descriptions, because displayed labels depend upon the user selected frontend. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
* (Denis Barbier) | On Mon, May 27, 2002 at 01:29:35PM +0200, Tollef Fog Heen wrote: | [...] | Right now there is a ncurses and a slang frontend, I am not sure of | the state of those, but it should be possible to link the better of | them against something-utf8 or create a newt-utf8 frontend. | | It would also be desirable to only support i18n-ed frontends, having | English text (Yes/No/Back/Cancel etc.) in buttons is confusing: | translators do not know if they have to write English or translated | strings in descriptions, because displayed labels depend upon the | user selected frontend. The way I have implemented the i18n is that they will fall back to non-translated strings if a translated string is not found. I don't see why the frontends shouldn't use the same method of getting the translations as well. A related problem would be how to choose which translations go into the boot-floppies; I am unsure how to fix that. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
On Mon, May 27, 2002 at 03:14:26PM +0200, Tollef Fog Heen wrote: * (Denis Barbier) | On Mon, May 27, 2002 at 01:29:35PM +0200, Tollef Fog Heen wrote: | [...] | Right now there is a ncurses and a slang frontend, I am not sure of | the state of those, but it should be possible to link the better of | them against something-utf8 or create a newt-utf8 frontend. | | It would also be desirable to only support i18n-ed frontends, having | English text (Yes/No/Back/Cancel etc.) in buttons is confusing: | translators do not know if they have to write English or translated | strings in descriptions, because displayed labels depend upon the | user selected frontend. The way I have implemented the i18n is that they will fall back to non-translated strings if a translated string is not found. I don't see why the frontends shouldn't use the same method of getting the translations as well. I do not understand your answer, sorry. Consider the cvs/pserver template from cvs.templates: Template: cvs/pserver Type: boolean Default: false Description: Should the CVS pserver be enabled? [...] CVS pserver will be installed in inetd, using tcpd wrappers if you answer yes to this question. As a translator, I cannot decide whether the 'yes' word has to be translated or not, because button label depends upon the selected frontend, it might be either 'yes' or its translation. For instance whiptail is not i18n-ed, so when a German user has selected dialog frontend, he is told to click on the 'Ja' button which does not exist! In order to avoid this annoyance, I suggested to only accept i18n-ed frontends. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
On Mon, May 27, 2002 at 11:06:26PM +0200, Denis Barbier wrote: [...] In order to avoid this annoyance, I suggested to only accept i18n-ed frontends. This suggestion does only make sense for interactive frontends, of course. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
On Mon, May 27, 2002 at 11:14:15PM +0200, Denis Barbier wrote: On Mon, May 27, 2002 at 11:06:26PM +0200, Denis Barbier wrote: [...] In order to avoid this annoyance, I suggested to only accept i18n-ed frontends. This suggestion does only make sense for interactive frontends, of course. Not really. Even people doing non-interactive installs might want to enter a name or some such with non-ascii characters. -- Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
Tollef Fog Heen [EMAIL PROTECTED] immo vero scripsit: | Are you saying that every debconf template file should be in UTF-8? | How do you propose to accomplish the transition ? Every debconf template which is used in d-i, yes. Why not? It shouldn't be that many templates. The others can be handled when the time is due. Last time I looked, there is no charset signifier in debconf templates, how does one know if the template is in utf-8 or euc-jp? Or am I misunderstanding what you mean by debconf templates completely? regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
* Junichi Uekawa | On 23 May 2002 10:31:32 +0200 | Tollef Fog Heen [EMAIL PROTECTED] wrote: | | I think we should move to debian-installer, even though it will take | longer time to work out. People want to do some new development, d-i | is getting closer to working (as in actually being able to install | systems in a mostly-reliable way) by the day and I don't think pushing | boot-floppies for yet another iteration would be good at all. IMO, | that is. | | I've had zero look at debian-installer. | I wonder if it would have CJK support. | Proper CJK support is a very difficult thing to achieve... It uses cdebconf as the frontend, and if somebody makes sure the bogl frontend is actually working and using the translated strings (look at the text frontend for information about how I've chosen to do it internally.) If there is more that needs to be done, you'll have to tell me about it. :) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
* Christian T. Steigies | On Thu, May 23, 2002 at 10:31:32AM +0200, Tollef Fog Heen wrote: | | I think we should move to debian-installer, even though it will take | longer time to work out. People want to do some new development, d-i | is getting closer to working (as in actually being able to install | systems in a mostly-reliable way) by the day and I don't think pushing | boot-floppies for yet another iteration would be good at all. IMO, | that is. | | getting closer to working... on i386? yes, since that is the arch I have at home. Once I have that working, I'll look into SPARC at least, maybe ppc as well. Unless somebody beats me to it, obviously. :) | Or has it been tested on other arches as well? I've never heard much | about d-i other than the commit messages. Just speaking for myself | here, but I think it has never been tested on m68k, and we do not | want to get rid of our oldest port just yet, do we? ;-) of course we won't, but most of the code should be portable. Except for the «install boot loader stuff» and make bootable floppy and those steps. | If you think its semi-usable, maybe you could send some instructions on what | to check out, special build instructions, usage documentation, estimated | build time, ... I would give it a shot in a free moment. it builds in a couple of minutes on my PIII-800 (laptop - very bad IO). It's in debian-boot's cvs, module name is debian-installer. Take a look at build/README and doc/. If things aren't explained well there, ask here or ask me on irc (nick's Mithrandir, #debian-devel or #debian-boot, OPN) and we'll work it out and document it. It's in the state that more people might hack on it at least, but don't expect too much yet. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
Tollef Fog Heen [EMAIL PROTECTED] immo vero scripsit: | I've had zero look at debian-installer. | I wonder if it would have CJK support. | Proper CJK support is a very difficult thing to achieve... It uses cdebconf as the frontend, and if somebody makes sure the bogl frontend is actually working and using the translated strings (look at the text frontend for information about how I've chosen to do it internally.) Last time I checked (which is a long long time ago), debconf had a design problem with utf-8 (the debconf templates are not in utf-8, and it is not automatically obvious which character code they are in). Does cdebconf inherit the same problem? Does it convert to utf-8 on the fly? What is a bogl frontend ? Is it very different from newt-utf8 that boot-floppies uses? regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
On 23 May 2002 10:31:32 +0200 Tollef Fog Heen [EMAIL PROTECTED] wrote: I think we should move to debian-installer, even though it will take longer time to work out. People want to do some new development, d-i is getting closer to working (as in actually being able to install systems in a mostly-reliable way) by the day and I don't think pushing boot-floppies for yet another iteration would be good at all. IMO, that is. I've had zero look at debian-installer. I wonder if it would have CJK support. Proper CJK support is a very difficult thing to achieve... regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
* Adam Di Carlo | Anthony Towns [EMAIL PROTECTED] writes: | | I just wanted to give y'all a heads up that I'd like you all to stick | around post woody, and keep/start working on CDs and installation stuff | for the next release. This doesn't change anything about debian-installer, | it'd just be helpful if you don't all wander off for four to six months | like usually happens :) | | As you may or may not know, I will no longer have a position of | responsibility in the installation system after Woody. Joey Hess has | volunteer for this position, or at least he did about 18 months ago. | I assume he's still for it -- hopefully the folks on this list agree | with that. Joey has offered me the position of technical lead on d-i, since he has too many other things taking up his time, and I have said yes. Assuming that nobody has any big objections, that is. | However, that is not to say I'm going to completely wander off after | Woody -- rather, I'm expecting to continue work on the boot-floppies | for 3.0rX point releases. Bug fixes, internationalization, bad | cosmetics fixes, and doc fixes only, of course. | | Hopefully this arrangement will let us | | (a) continue maintenance mode on the legacy boot-floppies system, and | | (b) simultaneously work out debian-installer (or pgi or whatever you | end up using for Woody+1) and get it in shape for *production* | use in, say, 6 months. | | I worry whether debian-installer can have the maturity for a Woody+1 | release, supposing we were going for a shorter release cycle of 6 | months. You have to consider that the testing period is at least 3 | months, apparently, and that would mean that we would have a | feature-complete debian-installer in 3 months, aka 12 weeks, which I | don't think is long enough. I think we should move to debian-installer, even though it will take longer time to work out. People want to do some new development, d-i is getting closer to working (as in actually being able to install systems in a mostly-reliable way) by the day and I don't think pushing boot-floppies for yet another iteration would be good at all. IMO, that is. | Anyhow, Anthony, I would suggest that you put your cards on the table | when you are expecting a feature complete new installation system | (alpha) and ready as a release candidate for more testing (beta). aj? | I also think we need to seriously consider not just | internationalization goals, but also disabled persons accessability | (e.g., U.S. Section 508), whether X or fbdev installer is desirable, | and what port might be included (especially if you're considering | the hurd). True, and I believe d-i will have the needed flexibility. | A little planning now will make for smoother waters in the future... very, very true. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
Tollef Fog Heen wrote: | As you may or may not know, I will no longer have a position of | responsibility in the installation system after Woody. Joey Hess has | volunteer for this position, or at least he did about 18 months ago. | I assume he's still for it -- hopefully the folks on this list agree | with that. Joey has offered me the position of technical lead on d-i, since he has too many other things taking up his time, and I have said yes. Assuming that nobody has any big objections, that is. I think that Tollef has been doing a great job already lately, and it's only fair that he should be saddled with it officially. :-) I will continue to participate with d-i of course, especially in helping with design issues and the parts I am the maintainer of. | I worry whether debian-installer can have the maturity for a Woody+1 | release, supposing we were going for a shorter release cycle of 6 | months. You have to consider that the testing period is at least 3 | months, apparently, and that would mean that we would have a | feature-complete debian-installer in 3 months, aka 12 weeks, which I | don't think is long enough. I think we should move to debian-installer, even though it will take longer time to work out. People want to do some new development, d-i is getting closer to working (as in actually being able to install systems in a mostly-reliable way) by the day and I don't think pushing boot-floppies for yet another iteration would be good at all. IMO, that is. It feels to me like a recipe for putting us in exactly the position we're in now, a year or however long later, once sarge has released. We have to work on d-i *sometime*, and now is clearly the time. Of course I share aph's worries, particularly when all the architectures are taken into account. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Post-woody
Hi guys, I just wanted to give y'all a heads up that I'd like you all to stick around post woody, and keep/start working on CDs and installation stuff for the next release. This doesn't change anything about debian-installer, it'd just be helpful if you don't all wander off for four to six months like usually happens :) Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif msg18784/pgp0.pgp Description: PGP signature
