From jonpryor at vt.edu Wed Jan 2 13:25:50 2008 From: jonpryor at vt.edu (Jonathan Pryor) Date: Wed, 02 Jan 2008 13:25:50 -0500 Subject: [Mono-docs-list] [Mono-dev] Can not checkout trunk on windows In-Reply-To: <1198683174.11168.172.camel@erandi.boston.ximian.com> References: <47716040.4090405@lanwin.de> <1198658399.29665.11.camel@lina.magi.jprl.com> <1198683174.11168.172.camel@erandi.boston.ximian.com> Message-ID: <1199298350.3676.23.camel@lina.magi.jprl.com> On Wed, 2007-12-26 at 10:32 -0500, Miguel de Icaza wrote: > > Suggestions? All I can suggest is that namespace XML files should > > contain some character/string that namespaces are highly unlikely to > > contain, e.g. instead of "en/System.xml" for the XML documentation on > > the System namespace, use "en/Namespace-System.xml". Any such > > character/string *must* be usable on Windows, so no ':' or similar > > characters can be used. > > We should add support for a different name like: > > ns-System.xml > > And then we can rename the files for the docs that we maintain. This has been done. Mike Kestner suggested using a namespaces.xml file; I chose not to do this as it made the migration of monodocer/monodocs2html/ecma-provider easier. > And keep the old code for documentation that might be out that has not > been updated by us. Monodoc will currently look for the older filename and rename accordingly; ecma-provider will check for both, with a preference for the non ns-prefixed name. monodocs2html currently requires the ns- prefixed files, as I couldn't think of an easy way to do the fallback within the XSLT. - Jon From jonpryor at vt.edu Wed Jan 2 23:20:16 2008 From: jonpryor at vt.edu (Jonathan Pryor) Date: Wed, 02 Jan 2008 23:20:16 -0500 Subject: [Mono-docs-list] [Mono-dev] Can not checkout trunk on windows In-Reply-To: <477C04C9.80708@lanwin.de> References: <47716040.4090405@lanwin.de> <1198658399.29665.11.camel@lina.magi.jprl.com> <1198683174.11168.172.camel@erandi.boston.ximian.com> <1199298350.3676.23.camel@lina.magi.jprl.com> <477C04C9.80708@lanwin.de> Message-ID: <1199334016.4581.0.camel@lina.magi.jprl.com> This file has been removed. Any other issues with a Win32 checkout? - Jon On Wed, 2008-01-02 at 22:40 +0100, Steve Wagner wrote: > Sorry but it isnt totaly solved. Now ive got the following error: > > Cant check out path > 'C:\mono-svn\monodoc\class\System.Web\en\System.Web\<>c__CompilerGenerated2+<>c__CompilerGenerated13.xml': > > Bad syntax for filename, directoryname or drivename > > * This is free text translated from german windows > > Steve > > Jonathan Pryor schrieb: > > On Wed, 2007-12-26 at 10:32 -0500, Miguel de Icaza wrote: > >>> Suggestions? All I can suggest is that namespace XML files should > >>> contain some character/string that namespaces are highly unlikely to > >>> contain, e.g. instead of "en/System.xml" for the XML documentation on > >>> the System namespace, use "en/Namespace-System.xml". Any such > >>> character/string *must* be usable on Windows, so no ':' or similar > >>> characters can be used. > >> We should add support for a different name like: > >> > >> ns-System.xml > >> > >> And then we can rename the files for the docs that we maintain. > > > > This has been done. Mike Kestner suggested using a namespaces.xml file; > > I chose not to do this as it made the migration of > > monodocer/monodocs2html/ecma-provider easier. > > > >> And keep the old code for documentation that might be out that has not > >> been updated by us. > > > > Monodoc will currently look for the older filename and rename > > accordingly; ecma-provider will check for both, with a preference for > > the non ns-prefixed name. > > > > monodocs2html currently requires the ns- prefixed files, as I couldn't > > think of an easy way to do the fallback within the XSLT. > > > > - Jon > > > > From lists at lanwin.de Wed Jan 2 16:40:25 2008 From: lists at lanwin.de (Steve Wagner) Date: Wed, 02 Jan 2008 22:40:25 +0100 Subject: [Mono-docs-list] [Mono-dev] Can not checkout trunk on windows In-Reply-To: <1199298350.3676.23.camel@lina.magi.jprl.com> References: <47716040.4090405@lanwin.de> <1198658399.29665.11.camel@lina.magi.jprl.com> <1198683174.11168.172.camel@erandi.boston.ximian.com> <1199298350.3676.23.camel@lina.magi.jprl.com> Message-ID: <477C04C9.80708@lanwin.de> Sorry but it isnt totaly solved. Now ive got the following error: Cant check out path 'C:\mono-svn\monodoc\class\System.Web\en\System.Web\<>c__CompilerGenerated2+<>c__CompilerGenerated13.xml': Bad syntax for filename, directoryname or drivename * This is free text translated from german windows Steve Jonathan Pryor schrieb: > On Wed, 2007-12-26 at 10:32 -0500, Miguel de Icaza wrote: >>> Suggestions? All I can suggest is that namespace XML files should >>> contain some character/string that namespaces are highly unlikely to >>> contain, e.g. instead of "en/System.xml" for the XML documentation on >>> the System namespace, use "en/Namespace-System.xml". Any such >>> character/string *must* be usable on Windows, so no ':' or similar >>> characters can be used. >> We should add support for a different name like: >> >> ns-System.xml >> >> And then we can rename the files for the docs that we maintain. > > This has been done. Mike Kestner suggested using a namespaces.xml file; > I chose not to do this as it made the migration of > monodocer/monodocs2html/ecma-provider easier. > >> And keep the old code for documentation that might be out that has not >> been updated by us. > > Monodoc will currently look for the older filename and rename > accordingly; ecma-provider will check for both, with a preference for > the non ns-prefixed name. > > monodocs2html currently requires the ns- prefixed files, as I couldn't > think of an easy way to do the fallback within the XSLT. > > - Jon > > From mkestner at novell.com Thu Jan 10 22:12:48 2008 From: mkestner at novell.com (Mike Kestner) Date: Thu, 10 Jan 2008 21:12:48 -0600 Subject: [Mono-docs-list] State of Mono Documentation Message-ID: <1200021168.3803.362.camel@t61p.site> Submitted for your reading pleasure, a dissertation on documentation. As discussed during the holidays, I'm going to be joining the effort to improve our documentation framework this year. As maintainer of the Gtk# documentation I am also a significant user. In order to get the ball rolling, I figured I would start by summarizing my perception of the strengths and weaknesses of the current system, and then share my current thoughts on how to improve it. I welcome your feedback. === Where we are === The foundation of the system is the monodoc XML format. Building on an XML document gives a nice base, with easy integration to existing source management systems via plain text files, access to XSLT to produce consumable content, and XML schemas for content validation. Our format has remained stable and our transformation to HTML content is fairly robust. This has provided a nice viewing capability. Web-based content rendering is solid. The offline rendering capability using gecko or gtkhtml has been somewhat problematic of late. The portability of gecko and gtkhtml is currently an issue. These appear to be primarily packaging issues on linux distributions, but they also impede the availability of local documentation viewing on Windows and Mac. The document maintenance side is not as rosy as the viewing side, however. The fragmentation of the system into numerous tools makes it challenging to use. There is no online editing/contribution capability, and the offline editing capability built in to the browser is not WYSIWYG. The contribution mechanism requires manual intervention introducing an administration bottleneck. Despite these limitations, we have had many community contributors to the documentation, for which we are grateful. It is unclear how much the above limitations have impacted the potential contributor base, but they certainly aren't helping matters, and they are impacting the productivity of the existing contributor base and maintainers. The document validater lists several TODO items in the header which appear significant. Being solely schema-based, it also lacks features like element reference validation. Integrating it into a documentation editor for on-the-fly validation would be another big gain. Document updating/stubbing is done via the monodocer tool. The tool is fairly robust, but can be very noisy. For example, I have frozen at an old revision of monodocer in Gtk# because of some changes which generated an avalanche of "whitespace" into the Gtk# documents like reordering of member nodes. These types of issues just add churn to the change management footprint, and make it hard to distinguish real changes from noise in a project the size of Gtk#. A typical documentation session for me in Gtk# looks something like this: 1) Run monodocer via a make target, since I can never remember the monodocer command switches I need. Read through the diff and commit whitespace changes resulting from the use of conflicting XML writers in tools like the contributions admin tool, one of my Gtk# automated signal documenters, or from internal changes to monodocer itself. 2) Edit a monodoc xml file with vim to fill in stubs for recent API changes. I manually add markup and crefs by memory, usually with only partial success on the markup and memory front. 3) Maybe run the validater if I think of it, but usually not. I guess I could improve the frequency by adding it to one of the make targets... 4) Run the assembler via a make target. 5) Fix any reported markup issues, make && make install to my private monodoc prefix and run monodoc to see if I got the crefs right. 6) Fix all the crefs I got wrong, and then commit. 7) Wait for the next monodoc release or Gtk# release, or Miguel's next manual push of the resulting docs to the website to have the new documents show up for users. I mention number 7 since documentation in many cases should not necessarily be tied to product release schedules. For Gtk# and the mono class libs, if a documentation change is accepted into the change management system it probably ought to be user-visible immediately if it validates. This could be considered a Mono/Gtk# process issue, but it would be nice to have infrastructure to facilitate faster documentation publishing than the glacial speed of software releases. In summary, we have a lot of room for improvement in our documentation production environment. === Where we could go === Since my elbow hurts from casting stones, I'll offer some thoughts on how I'd like to see the system improved. On-line editing of documentation is an intriguing idea which has been discussed in the past. The technology would essentially be focused on enticing users to fill in stubs in existing documentation. While this is a nice idea, I'm not convinced in the return on investment. It also would do little to help maintainers add documentation for new API to existing catalogs. I want to focus instead on the offline side to put better tools in the hands of library authors and project teams. My ultimate goal would be to integrate monodocer, validater, and assembler into a WYSIWYG editor and documentation administration tool. That rather large goal can be segmented into several intermediate milestones. First milestone would be a WYSIWYG editor for the monodoc XML format. It would be written as a thin wrapper app around a few custom widgets: a catalog tree widget to navigate a document catalog directory tree, and one or more document views to edit a given XML document. The document views would probably be DrawingArea subclasses utilizing inserted TextViews for editing. These widgets could be exposed as a library for use by a standalone editor as well as a MonoDevelop plugin for project documentation. The doc view could be used in an inert mode to display external documentation. This library would resolve the portability issues of the existing html widgets. Once the above widgets are complete, I would probably move next to integrated validation and assembly, and providing a completion-like capability for elements, like what you get typing in a source editor in a modern IDE. Validation would be completely under the hood, notifying the user immediately when they do something that fails validation and assembly. The next milestone would be integrating monodocer functionality into the editor. My vision for this is to associate a set of assemblies with a documentation catalog, and instead of generating stub documentation in the catalog directory itself, the editor could identify undocumented types and members in a special pane or tree node. It would also tag superfluous documentation for removal. At this point, the assembler would be fully integrated into the tool as well, so any necessary stubs needed for an assembled doc catalog could be generated on the fly instead of putting them out on disk and into the change management system. === On Contributions and Review === Documentation review is not much like code review. Unfortunately, that's what we've got right now. Reviewing a contributed documentation patch is an exercise in scanning XML markup. My understanding is that the web service admin tool has a rendered diff capability, but I'd like to see this capability integrated into the documentation editor. I want to be able to open a diff, see a marked up version of the change complete with spell checking, and merge it to my tree if it looks good. That would be sweet. This capability will be useful for organizations with a formal documentation review process. They usually need to distribute change-highlighted formatted documentation in print or electronic form to reviewers. === On Updates === Catalog updating would be a cool capability to add to the offline viewer so that users could opt to receive updates to installed catalogs when they are connected. We could have a web service interface to advertise the current revision stamp and provide patch downloads to requesting clients. The web service could also be configured with repository information so that it could pull documentation updates from the change management system, so that live or at least periodic batch updates of the documentation catalog could be pushed. This could also remove the manual interaction required to update an online web catalog. === Final Thoughts === I was going to invest a few paragraphs here heading off likely questions, opinions, and criticisms here, but you are probably tired of me already, so if you made it this far... Thanks for reading, I await your feedback. -- Mike Kestner From jonpryor at vt.edu Fri Jan 11 05:51:51 2008 From: jonpryor at vt.edu (Jonathan Pryor) Date: Fri, 11 Jan 2008 05:51:51 -0500 Subject: [Mono-docs-list] State of Mono Documentation In-Reply-To: <1200021168.3803.362.camel@t61p.site> References: <1200021168.3803.362.camel@t61p.site> Message-ID: <1200048711.4616.17.camel@lina.magi.jprl.com> On Thu, 2008-01-10 at 21:12 -0600, Mike Kestner wrote: > Document updating/stubbing is done via the monodocer tool. The tool is > fairly robust, but can be very noisy. For example, I have frozen at an > old revision of monodocer in Gtk# because of some changes which > generated an avalanche of "whitespace" into the Gtk# documents like > reordering of member nodes. These types of issues just add churn to the > change management footprint, and make it hard to distinguish real > changes from noise in a project the size of Gtk#. I must apologize for this (being the one to make this change). I modified monodocer to sort the nodes (based on @MemberName, number of parameters, return type, etc.), as originally monodocer generated output in System.Reflection order, which is (1) completely unspecified, and (2) can change on the whim of Reflection/mcs/etc. I figured that sorting the output would *reduce* the amount of _future_ ordering changes. It also helps with making it easier to find duplicated members, as they'll be next to each other. (I've found numerous instances of "bad" duplicate member checking in monodocer -- some fixed only 2 weeks ago -- where the same member would be present multiple times within an XML file. I found it easier to see these duplicated nodes when they were sorted next to each other.) > I want to focus instead on the offline side to put better tools in the > hands of library authors and project teams. My ultimate goal would be > to integrate monodocer, validater, and assembler into a WYSIWYG editor > and documentation administration tool. That rather large goal can be > segmented into several intermediate milestones. I like, depending on how far you go. :-) My own personal plan at the moment is to write an umbrella command-line program 'mdoc' to better associate the current programs. For example: Old: New: --- --- mdassembler mdoc assemble monodocs2html mdoc export-html monodocs2slashdoc mdoc export-slashdoc mdnormalizer mdoc normalize monodocer mdoc update mdvalidater mdoc validate mod mdoc view I wouldn't remove the old programs, but the idea is that this would allow a "naming" framework for new programs that wouldn't continually "pollute" $PATH. It would also bring some mental consistency; the name "monodocer" doesn't really make it easily associated with any of the other apps as seen through e.g. shell tab completion. :-) I also want to update the command-line arguments of these apps to increase consistency, e.g. -o vs. -dest or -path, etc. So my fear is that your integrated WYSIWYG editor would obsolete this idea. I like the idea of a WYSIWYG editor, but I don't want to lose the ability to do separate command-line updates. I also want to avoid code duplication. (For example, `mdoc' will simply execute the existing $prefix/lib/monodoc/*.exe programs, NOT re-implement them.) Otherwise, I love the idea. :-) - Jon From mkestner at novell.com Fri Jan 11 11:32:14 2008 From: mkestner at novell.com (Mike Kestner) Date: Fri, 11 Jan 2008 10:32:14 -0600 Subject: [Mono-docs-list] State of Mono Documentation In-Reply-To: <1200048711.4616.17.camel@lina.magi.jprl.com> References: <1200021168.3803.362.camel@t61p.site> <1200048711.4616.17.camel@lina.magi.jprl.com> Message-ID: <1200069134.3803.387.camel@t61p.site> On Fri, 2008-01-11 at 05:51 -0500, Jonathan Pryor wrote: > I must apologize for this (being the one to make this change). You weren't the first to add "whitespace" diffs to monodocer. You won't be the last. To be honest, I've seen more whitespace coming from System.Xml changes than from monodocer changes. We could probably solve most of these issues by exposing a stable monodoc XMLWriter so that every tool that touches a monodoc file can use it. My larger goal is to only touch a monodoc file when there's a real documentation change going in, as opposed to all the on-disk stubbing we are doing now. > My own personal plan at the moment is to write an umbrella command-line > program 'mdoc' to better associate the current programs. > > For example: > Old: New: > --- --- > mdassembler mdoc assemble > monodocs2html mdoc export-html The monodoc script already does many of these: monodoc --assemble monodoc --validate etc... > I also want to update the command-line arguments of these apps to > increase consistency, e.g. -o vs. -dest or -path, etc. Consistency is good, but obviously I'm focused on the non-xterm using community. My suspicion is that the majority of potential documentation contributors would prefer to not know what an xterm is. > So my fear is that your integrated WYSIWYG editor would obsolete this > idea. >From a platform stability standpoint, I don't think we could remove the scripts even if I wanted to, which I don't. Any functionality which is needed from the base scripts would be extracted into a library assembly that could be used by the editor as well as the scripts. -- Mike Kestner From lists at lanwin.de Thu Jan 3 16:27:11 2008 From: lists at lanwin.de (Steve Wagner) Date: Thu, 03 Jan 2008 22:27:11 +0100 Subject: [Mono-docs-list] [Mono-dev] Can not checkout trunk on windows In-Reply-To: <1199334016.4581.0.camel@lina.magi.jprl.com> References: <47716040.4090405@lanwin.de> <1198658399.29665.11.camel@lina.magi.jprl.com> <1198683174.11168.172.camel@erandi.boston.ximian.com> <1199298350.3676.23.camel@lina.magi.jprl.com> <477C04C9.80708@lanwin.de> <1199334016.4581.0.camel@lina.magi.jprl.com> Message-ID: <477D532F.70704@lanwin.de> Ok, now the checkout works perfectly. I inform you when ive got the next problem ;-) Steve Jonathan Pryor schrieb: > This file has been removed. > > Any other issues with a Win32 checkout? > > - Jon > > On Wed, 2008-01-02 at 22:40 +0100, Steve Wagner wrote: >> Sorry but it isnt totaly solved. Now ive got the following error: >> >> Cant check out path >> 'C:\mono-svn\monodoc\class\System.Web\en\System.Web\<>c__CompilerGenerated2+<>c__CompilerGenerated13.xml': >> >> Bad syntax for filename, directoryname or drivename >> >> * This is free text translated from german windows >> >> Steve >> >> Jonathan Pryor schrieb: >>> On Wed, 2007-12-26 at 10:32 -0500, Miguel de Icaza wrote: >>>>> Suggestions? All I can suggest is that namespace XML files should >>>>> contain some character/string that namespaces are highly unlikely to >>>>> contain, e.g. instead of "en/System.xml" for the XML documentation on >>>>> the System namespace, use "en/Namespace-System.xml". Any such >>>>> character/string *must* be usable on Windows, so no ':' or similar >>>>> characters can be used. >>>> We should add support for a different name like: >>>> >>>> ns-System.xml >>>> >>>> And then we can rename the files for the docs that we maintain. >>> This has been done. Mike Kestner suggested using a namespaces.xml file; >>> I chose not to do this as it made the migration of >>> monodocer/monodocs2html/ecma-provider easier. >>> >>>> And keep the old code for documentation that might be out that has not >>>> been updated by us. >>> Monodoc will currently look for the older filename and rename >>> accordingly; ecma-provider will check for both, with a preference for >>> the non ns-prefixed name. >>> >>> monodocs2html currently requires the ns- prefixed files, as I couldn't >>> think of an easy way to do the fallback within the XSLT. >>> >>> - Jon >>> >>> > From jonpryor at vt.edu Fri Jan 25 14:14:50 2008 From: jonpryor at vt.edu (Jonathan Pryor) Date: Fri, 25 Jan 2008 14:14:50 -0500 Subject: [Mono-docs-list] monodoc Licensing Message-ID: <1201288491.25514.145.camel@lina.magi.jprl.com> Joshua et al, You wrote and contributed to the monodoc module & many related utilities, such as monodocer, monodocs2html, etc., in addition to monodoc/engine and related documentation providers. The monodoc module currently claims to be under the GPL, as does `monodocer --version` and monodocs2html. How would you feel about relicensing these contributions under MIT/X11? No major reason, aside from an eventual simplification of Mono's licensing policy from GPL/LGPL/MIT-X11 to LGPL/MIT-X11, and I don't see much reason to prevent non-GPL-compliant reuse of these libraries and apps... Thanks, - Jon From jit at occams.info Fri Jan 25 14:31:02 2008 From: jit at occams.info (Joshua Tauberer) Date: Fri, 25 Jan 2008 14:31:02 -0500 Subject: [Mono-docs-list] monodoc Licensing In-Reply-To: <1201288491.25514.145.camel@lina.magi.jprl.com> References: <1201288491.25514.145.camel@lina.magi.jprl.com> Message-ID: <479A38F6.1040009@occams.info> Jonathan Pryor wrote: > Joshua et al, > > You wrote and contributed to the monodoc module & many related > utilities, such as monodocer, monodocs2html, etc., in addition to > monodoc/engine and related documentation providers. > > The monodoc module currently claims to be under the GPL, as does > `monodocer --version` and monodocs2html. > > How would you feel about relicensing these contributions under MIT/X11? > > No major reason, aside from an eventual simplification of Mono's > licensing policy from GPL/LGPL/MIT-X11 to LGPL/MIT-X11, and I don't see > much reason to prevent non-GPL-compliant reuse of these libraries and > apps... Hey, Jon. I'm fine with anything, and simplification is my middle name (or, at least, the point of my domain name). You can consider any of my contributions to monodoc in the public domain. Best, -- - Josh Tauberer http://razor.occams.info "Yields falsehood when preceded by its quotation! Yields falsehood when preceded by its quotation!" Achilles to Tortoise (in "G?del, Escher, Bach" by Douglas Hofstadter) From raf at ophion.org Fri Jan 25 15:13:33 2008 From: raf at ophion.org (Rafael Ferreira) Date: Fri, 25 Jan 2008 13:13:33 -0700 Subject: [Mono-docs-list] monodoc Licensing In-Reply-To: <479A38F6.1040009@occams.info> References: <1201288491.25514.145.camel@lina.magi.jprl.com> <479A38F6.1040009@occams.info> Message-ID: I'm totally ok with MIT/X11. - raf On 1/25/08, Joshua Tauberer wrote: > > Jonathan Pryor wrote: > > Joshua et al, > > > > You wrote and contributed to the monodoc module & many related > > utilities, such as monodocer, monodocs2html, etc., in addition to > > monodoc/engine and related documentation providers. > > > > The monodoc module currently claims to be under the GPL, as does > > `monodocer --version` and monodocs2html. > > > > How would you feel about relicensing these contributions under MIT/X11? > > > > No major reason, aside from an eventual simplification of Mono's > > licensing policy from GPL/LGPL/MIT-X11 to LGPL/MIT-X11, and I don't see > > much reason to prevent non-GPL-compliant reuse of these libraries and > > apps... > > Hey, Jon. > > I'm fine with anything, and simplification is my middle name (or, at > least, the point of my domain name). You can consider any of my > contributions to monodoc in the public domain. > > Best, > > -- > - Josh Tauberer > > http://razor.occams.info > > "Yields falsehood when preceded by its quotation! Yields > falsehood when preceded by its quotation!" Achilles to > Tortoise (in "G?del, Escher, Bach" by Douglas Hofstadter) > _______________________________________________ > Mono-docs-list maillist - Mono-docs-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-docs-list > -- Uva Software Open Educational Middleware www.uvasoftware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-docs-list/attachments/20080125/14e8da04/attachment.html From bmaurer at andrew.cmu.edu Fri Jan 25 14:42:42 2008 From: bmaurer at andrew.cmu.edu (Ben Maurer) Date: Fri, 25 Jan 2008 14:42:42 -0500 (EST) Subject: [Mono-docs-list] monodoc Licensing In-Reply-To: <1201288491.25514.145.camel@lina.magi.jprl.com> References: <1201288491.25514.145.camel@lina.magi.jprl.com> Message-ID: Hi Jon, Long time, no talk. I hope you are doing well. MIT/X11 is fine for anything I've written in monodoc. -b On Fri, 25 Jan 2008, Jonathan Pryor wrote: > Joshua et al, > > You wrote and contributed to the monodoc module & many related > utilities, such as monodocer, monodocs2html, etc., in addition to > monodoc/engine and related documentation providers. > > The monodoc module currently claims to be under the GPL, as does > `monodocer --version` and monodocs2html. > > How would you feel about relicensing these contributions under MIT/X11? > > No major reason, aside from an eventual simplification of Mono's > licensing policy from GPL/LGPL/MIT-X11 to LGPL/MIT-X11, and I don't see > much reason to prevent non-GPL-compliant reuse of these libraries and > apps... > > Thanks, > - Jon > > > > From amit_yaron at yahoo.com Thu Jan 31 02:44:09 2008 From: amit_yaron at yahoo.com (Amit Yaron) Date: Wed, 30 Jan 2008 23:44:09 -0800 (PST) Subject: [Mono-docs-list] Adding Articles Message-ID: <171555.6330.qm@web58706.mail.re1.yahoo.com> Hello, I have composed a document that explains how to use classes within ASP.NET pages. The document is based on the page Sharing Code Between Pages found in the ASP.NET Quick Start Tutorials. I would like to contribute this document to the Mono project, and will appreciate any help on how to do it. Thanks, Amit Yaron ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-docs-list/attachments/20080130/7230cbad/attachment.html From eric at extremeboredom.net Fri Jan 25 16:06:59 2008 From: eric at extremeboredom.net (Eric Butler) Date: Fri, 25 Jan 2008 13:06:59 -0800 Subject: [Mono-docs-list] monodoc Licensing In-Reply-To: References: <1201288491.25514.145.camel@lina.magi.jprl.com> Message-ID: <479A4F73.5050009@extremeboredom.net> Fine with me too. - Eric Ben Maurer wrote: > Hi Jon, > > Long time, no talk. I hope you are doing well. MIT/X11 is fine for > anything I've written in monodoc. > > -b > > On Fri, 25 Jan 2008, Jonathan Pryor wrote: > >> Joshua et al, >> >> You wrote and contributed to the monodoc module & many related >> utilities, such as monodocer, monodocs2html, etc., in addition to >> monodoc/engine and related documentation providers. >> >> The monodoc module currently claims to be under the GPL, as does >> `monodocer --version` and monodocs2html. >> >> How would you feel about relicensing these contributions under MIT/X11? >> >> No major reason, aside from an eventual simplification of Mono's >> licensing policy from GPL/LGPL/MIT-X11 to LGPL/MIT-X11, and I don't see >> much reason to prevent non-GPL-compliant reuse of these libraries and >> apps... >> >> Thanks, >> - Jon >> >> >> >>