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
> - 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)?
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.