From: Earnie B. <ear...@ya...> - 2002-02-15 12:42:24
|
I need a developer consensus on this. I received private mail asking for mingw-utils instead of MinGWutils. So I would like to hear votes. [ ] MinGWutils [ ] mingwutils [ ] mingw-utils [ ] Other, please specify ____________________________________________ Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Wu Y. <ad...@ne...> - 2002-02-25 05:56:27
|
I need a developer consensus on this. I received private mail asking for mingw-utils instead of MinGWutils. So I would like to hear votes. [x] mingw-utils ... -------------------------- It is the Unix convention and is consistent with other directory names. Best regards, Wu Yongwei |
From: F. <j_r...@ya...> - 2002-02-25 11:52:02
|
Earnie, Could you make the CVS root directory for this? Before I commit the agreed stuff I'll make a zip file so that the directory structure can be further discussed by everyone before it's done. Regards, José Fonseca _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: F. <j_r...@ya...> - 2002-02-15 12:51:49
|
On 2002.02.15 12:41 Earnie Boyd wrote: > I need a developer consensus on this. I received private mail asking > for mingw-utils instead of MinGWutils. So I would like to hear votes. > > [ ] MinGWutils > > [ ] mingwutils > > [X] mingw-utils (as in mingw-runtime...) > > [ ] Other, please specify ____________________________________________ > > Earnie. > Regards, José Fonseca PS: By coincidence I was at this moment writing an email to this list about what should figure on a package like this. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Earnie B. <ear...@ya...> - 2002-02-15 13:07:13
|
José Fonseca wrote: > > PS: By coincidence I was at this moment writing an email to this list > about what should figure on a package like this. > I've given this some thoughts too. By all rights it should be complete with autoconf/automake configurations. I'd say a subdir named scripts for all scripts and one named src for any compilable source. I would prefer the license to be either Public Domain or BSD without advertisment. Comments? Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: F. <j_r...@ya...> - 2002-02-15 13:26:06
|
On 2002.02.15 13:06 Earnie Boyd wrote: > José Fonseca wrote: > > > > PS: By coincidence I was at this moment writing an email to this list > > about what should figure on a package like this. > > > > I've given this some thoughts too. By all rights it should be complete > with autoconf/automake configurations. I'd say a subdir named scripts > for all scripts and one named src for any compilable source. I would I agree totally with you on the directory structure. > prefer the license to be either Public Domain or BSD without > advertisment. > You mean of the whole package? Why is that? My script is in GPL, but I don't know what are the licenses of the stuff I've suggested in my previous email. > Comments? > > Earnie. > Regards, José Fonseca _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Earnie B. <ear...@ya...> - 2002-02-15 13:39:51
|
José Fonseca wrote: > > On 2002.02.15 13:06 Earnie Boyd wrote: > > José Fonseca wrote: > > > > > > PS: By coincidence I was at this moment writing an email to this list > > > about what should figure on a package like this. > > > > > > > I've given this some thoughts too. By all rights it should be complete > > with autoconf/automake configurations. I'd say a subdir named scripts > > for all scripts and one named src for any compilable source. I would > > I agree totally with you on the directory structure. > > > prefer the license to be either Public Domain or BSD without > > advertisment. > > > > You mean of the whole package? Why is that? > I mean things you've written, but I'm not dead set against any other license unless it affects the output of the tool. As to the why, the mingw-runtime is PD and w32api is free for use with notification. > My script is in GPL, but I don't know what are the licenses of the stuff > I've suggested in my previous email. > Tools that we have no control over the license is something we have no right to change. Tools we write we do have control over and can decide on a license. In short, it doesn't matter what the Open Source license is unless it forces the user to use the same license for his product. That by all means is what we want to avoid as it is the impetus for MinGW's existence. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: F. <j_r...@ya...> - 2002-02-15 13:51:00
|
On 2002.02.15 13:39 Earnie Boyd wrote: > José Fonseca wrote: > > > > On 2002.02.15 13:06 Earnie Boyd wrote: > > > .... I would > > > prefer the license to be either Public Domain or BSD without > > > advertisment. > > > > > > > You mean of the whole package? Why is that? > > > > I mean things you've written, but I'm not dead set against any other > license unless it affects the output of the tool. As to the why, the > mingw-runtime is PD and w32api is free for use with notification. > > > My script is in GPL, but I don't know what are the licenses of the > stuff > > I've suggested in my previous email. > > > > Tools that we have no control over the license is something we have no > right to change. Tools we write we do have control over and can decide > on a license. > > In short, it doesn't matter what the Open Source license is unless it > forces the user to use the same license for his product. That by all > means is what we want to avoid as it is the impetus for MinGW's > existence. > > Earnie. > Okay. I'll put them on Public Domain. Is there any place from where I can read what terms should I use on PD licenses (www.opensource.org doesn't mention it) or should I base upon mingw-runtime's README? Regards, José Fonseca _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Earnie B. <ear...@ya...> - 2002-02-15 15:24:08
|
José Fonseca wrote: > > Okay. I'll put them on Public Domain. Is there any place from where I can > read what terms should I use on PD licenses (www.opensource.org doesn't > mention it) or should I base upon mingw-runtime's README? > The MinGW-runtime's README as an example should suffice. I would have suggested www.opensource.org and since you've already searched there ... Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Steve D. P. <mai...@st...> - 2002-02-15 13:19:26
|
> [X] MinGWutils I really couldn't care less whether or not you include a hyphen between the "MinGW" and the "utils". However, I do prefer the recently-adopted standard of capitalization in "MinGW"... and would not want to see an all-lowercase "mingw" used. Steve |
From: Artem K. <ka...@co...> - 2002-02-15 18:54:30
|
> [ ] MinGWutils > > [ ] mingwutils > > [X] mingw-utils (for me, much easier to read, type and remember what the proper capitalization is) > > [ ] Other, please specify ____________________________________________ > |
From: <dan...@ya...> - 2002-02-15 19:14:40
|
> > [ ] MinGWutils > > [ ] mingwutils > > [X] mingw-utils > There are some newbie type samples in the mingw-runtime source. Should they be separated out as an 'mingw-examples' package for greater accessibility. The samples may need updating. They also could easily be extended with contributions. I don't think generic code snippets belong here, just things like dllhelpers, maybe some of Mumit's old examples that are specific to mingw. Danny _ _____________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr http://greetings.yahoo.com.au - Yahoo! Greetings - Send your Valentines love online. |
From: Earnie B. <ear...@ya...> - 2002-02-15 19:25:04
|
Danny Smith wrote: > > There are some newbie type samples in the mingw-runtime source. Should > they be separated out as an 'mingw-examples' package for greater > accessibility. The samples may need updating. They also could easily be > extended with contributions. I don't think generic code snippets belong > here, just things like dllhelpers, maybe some of Mumit's old examples that > are specific to mingw. > Yes, good idea. Then all of the examples and how to documentation could go to that package. Jose` has GNU documentation converted to CMH/HLP should that be a part of mingw-examples, mingw-utils or mingw-gnudoc? Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Jose F. <j_r...@ya...> - 2002-02-15 19:45:17
|
On Fri, 2002-02-15 at 19:24, Earnie Boyd wrote: > Danny Smith wrote: > > > > There are some newbie type samples in the mingw-runtime source. Should > > they be separated out as an 'mingw-examples' package for greater > > accessibility. The samples may need updating. They also could easily be > > extended with contributions. I don't think generic code snippets belong > > here, just things like dllhelpers, maybe some of Mumit's old examples that > > are specific to mingw. > > > > Yes, good idea. Then all of the examples and how to documentation could > go to that package. Jose` has GNU documentation converted to CMH/HLP > should that be a part of mingw-examples, mingw-utils or mingw-gnudoc? > > Earnie. > I'm in favor of a separate mingw-gnudoc. Even more due to the fact that, although I don't have the sources anymore (they took too much space at a time than I didn't have it) as we add/update more manuals it will be a good idea to keep the source in a mingw-gnudoc-src package to facilitate its maintenance. Jose' Fonseca |
From: <dan...@ya...> - 2002-02-16 00:41:54
|
--- Jose Fonseca <j_r...@ya...> wrote: > On Fri, 2002-02-15 at 19:24, Earnie Boyd wrote: > > I'm in favor of a separate mingw-gnudoc. Even more due to the fact that, > although I don't have the sources anymore (they took too much space at a > time than I didn't have it) as we add/update more manuals it will be a > good idea to keep the source in a mingw-gnudoc-src package to facilitate > its maintenance. > > Jose' Fonseca > > I hope this doesn't create confusion but I'm still not sure about the bundling of docs and their sources. Here is my impression of mingw: MinGW | +---GCC | +---C | | \---docs | +---C++ | | \---docs | +---Fortran | | \---docs | +---ObjC | | \---docs | +---Ada | | \---docs | (+---Java) | | \---docs | +---Extra support libs | | +---Boehm-GC | | \---docs | \---(gcc-doc-collection = all of the gcc docs) | +---binutils (all - no need to split up, is there?) | \---binutils-docs (all) | +---mingw-runtime | \---mingw-runtime-docs | +---w32api | \---w32api-docs | +mingw-utils | +---make | | \---make-docs | +---Joses' utils | | \---Joses'-utils-docs | +---more utils | | \---more-utils-docs | | | \---mingw-utils-doc-collection (= all the utils docs) | +mingw-gdb | \---mingw-gdb-docs | +mingw-samples | +mingw-doc-collection +---one-mingw-ring-to-bind-them-all-docs +---gcc-docs +---binutils-docs +---mingw-runtime-docs +---w32api-docs +---mingw-utils-docs \---mingw-gdb-docs Every subcomponent distributed as a package has its own docs. In addition, there is an omnibus doc package that collects all the docs. The gcc and binutils docs must be distributed with their sources also available since the are GPLd binaries. In the case of the STL and libiberty for example, docs are generated in part from comments in the source header files. This is not a problem for the individual components, but it means a bit of extra work for an omnibus doc collection. Danny Danny Danny http://movies.yahoo.com.au - Yahoo! Movies - Vote for your nominees in our online Oscars pool. |
From: F. <j_r...@ya...> - 2002-02-16 02:31:53
|
On 2002.02.16 00:41 Danny Smith wrote: > --- Jose Fonseca <j_r...@ya...> wrote: > On Fri, 2002-02-15 > at > 19:24, Earnie Boyd wrote: > > > > I'm in favor of a separate mingw-gnudoc. Even more due to the fact > that, > > although I don't have the sources anymore (they took too much space at > a > > time than I didn't have it) as we add/update more manuals it will be a > > good idea to keep the source in a mingw-gnudoc-src package to > facilitate > > its maintenance. > > > > Jose' Fonseca > > > > > I hope this doesn't create confusion but I'm still not sure about the > bundling of docs and their sources. > Here is my impression of mingw: > > MinGW > | > ... > Yes. Your view of mingw tree is the same as mine. Except perhaps, that it would be interesting put not only the documentation of the gnu programs included with the standard mingw but the standard gnu/unix tools documentation (which are also included in MSYS) since a mingw user interested in unix/win32 portability would also be interested on them. > Every subcomponent distributed as a package has its own docs. In > addition, > there is an omnibus doc package that collects all the docs. The gcc and The sources of the "omnibus" doc package won't be mainly the texinfo files because as you pointed out, some of the texinfo documentation is generated automatically from the sources. What I would like to have seperately in that source package would be the intermediate HTML files for the generation of the .CHM. The reason for this is that the generation of the .CHM is partially automated by tools, but so far I haven't managed to fully automate the process so it involves some hand editing. And having to uncompress e.g. glibc and do the process all over again everytime we want to change the parameters of the CHM is rather painful. > binutils docs must be distributed with their sources also available since > the are GPLd binaries. In the case of the STL and libiberty for example, This is no problem, since GPL allow to give just a link to the sources - and they are all in the ftp.gnu.org since we aren't modifying them. > docs are generated in part from comments in the source header files. This > is not a problem for the individual components, but it means a bit of > extra work for an omnibus doc collection. > > Danny Since I don't have these intermediate HTML files anymore, I plan to review the perl script to convert from .texi to .html+ch? to see if things can be fully automated without going into much trouble. And once all mingw documentation is settled perhaps these intermediate .html have no more need to be, but until then, there is a long road ahead. I hope this has given a little more of light on this subject. Regards, José Fonseca _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: <dan...@ya...> - 2002-02-16 05:30:57
|
--- José Fonseca <j_r...@ya...> wrote: > On 2002.02.16 00:41 Danny Smith wrote: > > Yes. Your view of mingw tree is the same as mine. Except perhaps, that it > > would be interesting put not only the documentation of the gnu programs > included with the standard mingw but the standard gnu/unix tools > documentation (which are also included in MSYS) since a mingw user > interested in unix/win32 portability would also be interested on them. > I agree. > <snip> > automatically from the sources. What I would like to have seperately in > that source package would be the intermediate HTML files for the > generation of the .CHM. > Yes, I agree here too. Those can be generated (usually) with a simple 'makeinfo --html' but sometimes there is some hand-editing to clean up the top. > The reason for this is that the generation of the .CHM is partially > automated by tools, but so far I haven't managed to fully automate the > process so it involves some hand editing. And having to uncompress e.g. > glibc and do the process all over again everytime we want to change the > parameters of the CHM is rather painful. > > <snip> > > Since I don't have these intermediate HTML files anymore, I plan to > review > the perl script to convert from .texi to .html+ch? to see if things can > be > fully automated without going into much trouble. And once all mingw > documentation is settled perhaps these intermediate .html have no more > need to be, but until then, there is a long road ahead. > There is a long road. That's the part I like. Once everthing is settled, as you say, I'll look for a new road. > I hope this has given a little more of light on this subject. Yes, thank you. Danny > Regards, > > José Fonseca > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > http://movies.yahoo.com.au - Yahoo! Movies - Vote for your nominees in our online Oscars pool. |
From: Steve D. P. <mai...@st...> - 2002-02-15 20:05:13
|
> Yes, good idea. Then all of the examples and how to documentation could > go to that package. Jose` has GNU documentation converted to CMH/HLP > should that be a part of mingw-examples, mingw-utils or mingw-gnudoc? Wow, let's pause to catch our breath here... everytime I check my email over the past 24 hours, there's a new MinGW subpackage on the drawing board and about to go in production! A few brief thoughts/questions: - Are we talking about organizing all MinGW materials into some appropriate subpackage... or will "make", "binutils", and so forth continue to float out there as "loose cannon packages"? If the former approach is used, which "mingw-XXX" package(s) would these loose items get rolled into? - Does it really make sense to have a subpackage as specific as "mingw-gnudoc", when work is underway on MinGW-specific documentation? Perhaps it would be advisable to broaden this subpackage's scope (i.e. "mingw-doc") and have it include general GNU as well as MinGW-specific documentation? - There was some conversation a couple of weeks ago about the practicality of individual maintainer(s) being responsible for managing all production-released changes to each particular subpackage. Was any resolution ever reached with this? What effect (if any) will these packaging changes have on how development in organized and managed? - I keep referring to these subpackages as "SUB"-packages, because I have this vision in my head of the main "MinGW" release being a glued-together composite of all the subpackage snapshots taken at the time of release. Is that vision in sync with what others are thinking... or are we thinking about going back to the model where users install MinGW by just downloading all the latest individual packages they're interested in... or will the main "MinGW" release be some separate entity/concept (i.e. a glued together composite of only certain "required" subpackages)? Steve |
From: Jose F. <j_r...@ya...> - 2002-02-15 20:50:23
|
On Fri, 2002-02-15 at 20:02, Steve D. Perkins wrote: > > Yes, good idea. Then all of the examples and how to documentation could > > go to that package. Jose` has GNU documentation converted to CMH/HLP > > should that be a part of mingw-examples, mingw-utils or mingw-gnudoc? > > > Wow, let's pause to catch our breath here... everytime I check my email > over the past 24 hours, there's a new MinGW subpackage on the drawing board > and about to go in production! A few brief thoughts/questions: > > - Are we talking about organizing all MinGW materials into some appropriate > subpackage... or will "make", "binutils", and so forth continue to float out > there as "loose cannon packages"? If the former approach is used, which > "mingw-XXX" package(s) would these loose items get rolled into? > > - Does it really make sense to have a subpackage as specific as > "mingw-gnudoc", when work is underway on MinGW-specific documentation? > Perhaps it would be advisable to broaden this subpackage's scope (i.e. > "mingw-doc") and have it include general GNU as well as MinGW-specific > documentation? > > - There was some conversation a couple of weeks ago about the practicality > of individual maintainer(s) being responsible for managing all > production-released changes to each particular subpackage. Was any > resolution ever reached with this? What effect (if any) will these > packaging changes have on how development in organized and managed? > > - I keep referring to these subpackages as "SUB"-packages, because I have > this vision in my head of the main "MinGW" release being a glued-together > composite of all the subpackage snapshots taken at the time of release. Is > that vision in sync with what others are thinking... or are we thinking > about going back to the model where users install MinGW by just downloading > all the latest individual packages they're interested in... or will the main > "MinGW" release be some separate entity/concept (i.e. a glued together > composite of only certain "required" subpackages)? > > Steve > I see these packages mainly as components that are developed separately, living in different CVS modules, and probably maintained by different set of people. In no away this means that they also must be distributed separately. They can be all bundled in a mingw release. Individual packages may be available as updates or for those who already have a previous release and don't want to download the whole bundled release, that as matter of fact, it's gonna get quite big with all gnu documentation... Regarding the separate mingw-gnudoc I agree with you that all can be in a single mingw-doc. We can even take advantage of the CHM features and make big help documentation system with the same scheme of Platform SDK documentation, e.g., linking the mingw manual with the gcc manual, etc. If that fits what you've planned for the mingw documentation, of course. Regards, Jose Fonseca |
From: <dan...@ya...> - 2002-02-15 20:41:02
|
--- "Steve D. Perkins" <mai...@st...> wrote: > > Yes, good idea. Then all of the examples and how to documentation > could > > go to that package. Jose` has GNU documentation converted to CMH/HLP > > should that be a part of mingw-examples, mingw-utils or mingw-gnudoc? > > > Wow, let's pause to catch our breath here... everytime I check my > email > over the past 24 hours, there's a new MinGW subpackage on the drawing > board > and about to go in production! A few brief thoughts/questions: > > - Are we talking about organizing all MinGW materials into some > appropriate > subpackage... or will "make", "binutils", and so forth continue to float > out > there as "loose cannon packages"? If the former approach is used, which > "mingw-XXX" package(s) would these loose items get rolled into? > The value of the loose cannon, from my perspective, is that it facilitates the "release soon, release often" approach. The full mingw package (gccm binutils, runtime, w32api) with gcc 3.1 on my hd is 104 MB. That does not include gdb or msys or any utils. That will be cut considerably after I strip out the debugging info but still it will be significantly bigger than before. For me, uploading something that big can be a problem. For others, downloading somthing that big can be a problem. Not everyone has the latest and greatest telecommunications. My connection sometimes is broken when a lamb bounces into an electic fence that crosses the buried telephone line. Some packages change more frequently than others, eg w32api > binutils> gcc. Some gcc sub-packages are add-ons that not every one want: ObjC, Ada (in 3.1 release) and hopefully, in time, Java. Okay we want a full package for new users. For others we want to be able to do incremntal upgrades. What is base distro? My idea is that it is C, C++ and Fortran compilres plus binutils plus w32api plus runtime. Plus a readme. No frills. What is full distro? Above plus gdb plus mingw-utils plus mingw-doc plus mingw-samples? What is super distro: Above plus ObjC plus Ada (plus maybe Java), plus Boehm-GC libs. Now where does msys fit? Those are the binaries. Then lets think about source distros. Do we really need to bundle them? Danny http://greetings.yahoo.com.au - Yahoo! Greetings - Send your Valentines love online. |
From: Steve D. P. <mai...@st...> - 2002-02-15 22:05:56
|
> The value of the loose cannon, from my perspective, is that it facilitates > the "release soon, release often" approach.... I apologize for the miscommunication. By "loose cannon", my gripe was directed at the naming convention rather than the particular package content. I was simply saying that if there's going to be this drive towards a consistent naming convention with MinGW subpackages... do we want to alter the legacy subpackages to use this naming convention? If some of these loose cannon packages are logically related and we want to bundle them togther, fine. If we want to keep them seperate, that's fine too. It's fine with me if there are a thousand MinGW packages of an average 100 kilobytes or less each in size... it would just strike me as odd to have some of them use a common naming convention and others not. > Okay we want a full package for new users. For others we want to be able > to do incremntal upgrades. I like this idea, which is consistent with what we are doing now. > What is base distro? My idea is that it is C, C++ and Fortran compilres > plus binutils plus w32api plus runtime. Plus a readme. No frills. I agree, and support the seperation of "required" subpackages from "option" ones (documentation and samples)... the main "MinGW" release being a pre-bundled composite of only the "required" ones. > What is full distro? Above plus gdb plus mingw-utils plus mingw-doc plus > mingw-samples? > > What is super distro: Above plus ObjC plus Ada (plus maybe Java), plus > Boehm-GC libs. I agree with these definitions, but do we want to waste the effort and disk space with maintaing pre-bundled realeases for all three of these categories (base, full, and super)? I'd vote for making the main "MinGW" release the base distro... and having these other two just be concepts on paper that users can implement for themselves by downloading the necessary individual files. Anyone advanced enough to NEEDS the "super distro" will probably be non-newbie and able to pick up on the packaging system concepts anyway. > Now where does msys fit? As a totally seperate entity, as I see it. It's just an optional shell environment in which MinGW can be used... similar to how the Dev-C++ IDE is a popular shell designed to act as a MinGW wrapper. In this particular situation I'm not even sure that it should conform to the MinGW package naming convention, it really ISN'T a package or even part of MinGW at all. Steve |
From: <dan...@ya...> - 2002-02-15 22:39:25
|
--- "Steve D. Perkins" <mai...@st...> wrote: > > The value of the loose cannon, from my perspective, is that it > facilitates > > the "release soon, release often" approach.... > > I apologize for the miscommunication. By "loose cannon", my gripe > was > directed at the naming convention rather than the particular package > content. I was simply saying that if there's going to be this drive > towards > a consistent naming convention with MinGW subpackages... do we want to > alter > the legacy subpackages to use this naming convention? > A standardised naming convention would be good. I don't think we should rename the existing subpackages since that would cause confusion. That should wait until mingw-1.2 release. But as a template, how would you see the current components being named? I foresee that when 3.1 is released, users will find windows-specific or w95 specific bugs that are not being tested in the gcc dejagnu testsuite or in my test bed. Thus, there will very probably need to be a series of betas or pre-releases before we want to put 3.1 into a new mingw base package. We will probably also want to retain the 2.95 branch of gcc since it is very stable and, in the case of iostream-dependent code, has much faster compile time. How do handle alternative gccs in 'base' distro? Danny http://greetings.yahoo.com.au - Yahoo! Greetings - Send your Valentines love online. |
From: Earnie B. <ear...@ya...> - 2002-02-15 21:40:45
|
"Steve D. Perkins" wrote: > > > Yes, good idea. Then all of the examples and how to documentation could > > go to that package. Jose` has GNU documentation converted to CMH/HLP > > should that be a part of mingw-examples, mingw-utils or mingw-gnudoc? > > Wow, let's pause to catch our breath here... everytime I check my email > over the past 24 hours, there's a new MinGW subpackage on the drawing board > and about to go in production! A few brief thoughts/questions: > > - Are we talking about organizing all MinGW materials into some appropriate > subpackage... or will "make", "binutils", and so forth continue to float out > there as "loose cannon packages"? If the former approach is used, which > "mingw-XXX" package(s) would these loose items get rolled into? > To smoothly accomplish this a top-level directory containing each package with proper autoconfiguration to build the subdirectories would be needed. Yes, doable and advisable. > - Does it really make sense to have a subpackage as specific as > "mingw-gnudoc", when work is underway on MinGW-specific documentation? > Perhaps it would be advisable to broaden this subpackage's scope (i.e. > "mingw-doc") and have it include general GNU as well as MinGW-specific > documentation? > Good point. A name such as mingw-doc would be better served. > - There was some conversation a couple of weeks ago about the practicality > of individual maintainer(s) being responsible for managing all > production-released changes to each particular subpackage. Was any > resolution ever reached with this? What effect (if any) will these > packaging changes have on how development in organized and managed? > Well, I agreed to write up a standards specification for contributed packages. I've not had the round tuits due to a major migration that I've been working since June '01 and finally implemented. Hopefully by the end of March. I think we've proven that having one individual as a release manager isn't really doable. We'll just have to keep each other in check. > - I keep referring to these subpackages as "SUB"-packages, because I have > this vision in my head of the main "MinGW" release being a glued-together > composite of all the subpackage snapshots taken at the time of release. Is > that vision in sync with what others are thinking... or are we thinking > about going back to the model where users install MinGW by just downloading > all the latest individual packages they're interested in... or will the main > "MinGW" release be some separate entity/concept (i.e. a glued together > composite of only certain "required" subpackages)? > Yes, but the subpackage release is good for those who want to update only that package. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |