From: Michael S. <mi...@st...> - 2013-02-23 13:59:04
|
I realized that the install instructions are not on the wiki where I do have edit permissions. The windows install instructions need to be freshened up a bit. What is the process to update those pages (e.g. http://misterhouse.sourceforge.net/install.html) Thank you, Michael |
From: Lieven H. <li...@li...> - 2013-02-23 14:14:31
|
Hi Michael, the wiki on the github account is available for editing to everybody who has a github account. https://github.com/hollie/misterhouse/wiki It might make sense to start from fresh there? The easier the editing is, the more chance people will actually edit. Removing the barrier of asking permission to edit is a plus according to me. Kind regards, Lieven. Op 23-feb.-2013, om 15:00 heeft "Michael Stovenour" <mi...@st...> het volgende geschreven: > I realized that the install instructions are not on the wiki where I do have edit permissions. The windows install instructions need to be freshened up a bit. What is the process to update those pages (e.g. http://misterhouse.sourceforge.net/install.html) > > Thank you, > Michael > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > |
From: Michael S. <mi...@st...> - 2013-02-23 14:45:16
|
Hi Lieven, I'm not convinced that starting over on the documentation is the right approach; I certainly cannot justify my time to participate. If someone agrees to put in the time to move the pages and be the primary editor it might help convince me. There is nothing fundamentally wrong with the wikispaces service; we are just lacking people willing to update the material. Moving the location of the documentation will not fix the resource issue. If we want to move the handful of pages on sourceforge to a wiki, I propose that should be the wikispaces wiki so at least we could have all the documentation in one place. But I think that someone willing to do the work should make the decision. Sincerely, Michael -----Original Message----- From: Lieven Hollevoet [mailto:li...@li...] Sent: Saturday, February 23, 2013 8:14 AM To: Michael Stovenour Cc: mis...@li... Subject: Re: [mh] Permissions to update sourceforge HTML pages Hi Michael, the wiki on the github account is available for editing to everybody who has a github account. https://github.com/hollie/misterhouse/wiki It might make sense to start from fresh there? The easier the editing is, the more chance people will actually edit. Removing the barrier of asking permission to edit is a plus according to me. Kind regards, Lieven. Op 23-feb.-2013, om 15:00 heeft "Michael Stovenour" <mi...@st...> het volgende geschreven: > I realized that the install instructions are not on the wiki where I do have edit permissions. The windows install instructions need to be freshened up a bit. What is the process to update those pages (e.g. http://misterhouse.sourceforge.net/install.html) > > Thank you, > Michael > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > |
From: Lieven H. <li...@li...> - 2013-02-24 10:13:31
|
Hello Michael, maybe my wording was not completely correct: with 'starting from fresh' I don't mean writing everything from scratch. We can of course take over existing material, but it would be nice if everything would be grouped in a central place where everybody can contribute with as little hassle as possible. We also don't need to move over everything at once, but of we decide to 'freshen' a certain section a bit, me can consider moving it to the wiki that goes together with the codebase. I already tried to make a start here: https://github.com/hollie/misterhouse/wiki and I add stuff as I encounter it when extending my MH setup. However, I don't have Insteon hardware and I don't run on Windows, so I can't be much of help documenting those parts. Best regards, Lieven. Op 23-feb.-2013, om 15:46 heeft "Michael Stovenour" <mi...@st...> het volgende geschreven: > Hi Lieven, > I'm not convinced that starting over on the documentation is the right approach; I > certainly cannot justify my time to participate. If someone agrees to put in the time to > move the pages and be the primary editor it might help convince me. There is nothing > fundamentally wrong with the wikispaces service; we are just lacking people willing to > update the material. Moving the location of the documentation will not fix the resource > issue. > > If we want to move the handful of pages on sourceforge to a wiki, I propose that should be > the wikispaces wiki so at least we could have all the documentation in one place. But I > think that someone willing to do the work should make the decision. > > Sincerely, > Michael > > -----Original Message----- > From: Lieven Hollevoet [mailto:li...@li...] > Sent: Saturday, February 23, 2013 8:14 AM > To: Michael Stovenour > Cc: mis...@li... > Subject: Re: [mh] Permissions to update sourceforge HTML pages > > Hi Michael, > > the wiki on the github account is available for editing to everybody who has a github > account. > https://github.com/hollie/misterhouse/wiki > > It might make sense to start from fresh there? The easier the editing is, the more chance > people will actually edit. Removing the barrier of asking permission to edit is a plus > according to me. > > Kind regards, > Lieven. > > Op 23-feb.-2013, om 15:00 heeft "Michael Stovenour" <mi...@st...> het volgende > geschreven: > >> I realized that the install instructions are not on the wiki where I do have edit > permissions. The windows install instructions need to be freshened up a bit. What is the > process to update those pages (e.g. http://misterhouse.sourceforge.net/install.html) >> >> Thank you, >> Michael >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> > http://p.sf.net/sfu/appdyn_d2d_feb________________________________________________________ >> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 >> > |
From: Eloy P. <pe...@ch...> - 2013-02-24 13:30:35
|
Hello, On 02/24/2013 05:13 AM, Lieven Hollevoet wrote: > Hello Michael, > > maybe my wording was not completely correct: with 'starting from > fresh' I don't mean writing everything from scratch. We can of course > take over existing material, but it would be nice if everything would > be grouped in a central place where everybody can contribute with as > little hassle as possible. > > We also don't need to move over everything at once, but of we decide > to 'freshen' a certain section a bit, me can consider moving it to > the wiki that goes together with the codebase. > > I already tried to make a start here: > https://github.com/hollie/misterhouse/wiki and I add stuff as I > encounter it when extending my MH setup. However, I don't have > Insteon hardware and I don't run on Windows, so I can't be much of > help documenting those parts. We are not doing anyone a favor by maintaining documentation in two places so we need to decide where we are going to keep documentation and stick with it. Personally I do not have any preference but I tend to favor wikispaces because there is a lot of documentation there already. Unless, as Michael says, someone takes on the task of moving things from wikispaces to github. Cheers, Eloy Paris.- > Op 23-feb.-2013, om 15:46 heeft "Michael Stovenour" <mi...@st...> het volgende geschreven: > >> Hi Lieven, >> I'm not convinced that starting over on the documentation is the right approach; I >> certainly cannot justify my time to participate. If someone agrees to put in the time to >> move the pages and be the primary editor it might help convince me. There is nothing >> fundamentally wrong with the wikispaces service; we are just lacking people willing to >> update the material. Moving the location of the documentation will not fix the resource >> issue. >> >> If we want to move the handful of pages on sourceforge to a wiki, I propose that should be >> the wikispaces wiki so at least we could have all the documentation in one place. But I >> think that someone willing to do the work should make the decision. >> >> Sincerely, >> Michael >> >> -----Original Message----- >> From: Lieven Hollevoet [mailto:li...@li...] >> Sent: Saturday, February 23, 2013 8:14 AM >> To: Michael Stovenour >> Cc: mis...@li... >> Subject: Re: [mh] Permissions to update sourceforge HTML pages >> >> Hi Michael, >> >> the wiki on the github account is available for editing to everybody who has a github >> account. >> https://github.com/hollie/misterhouse/wiki >> >> It might make sense to start from fresh there? The easier the editing is, the more chance >> people will actually edit. Removing the barrier of asking permission to edit is a plus >> according to me. >> >> Kind regards, >> Lieven. >> >> Op 23-feb.-2013, om 15:00 heeft "Michael Stovenour" <mi...@st...> het volgende >> geschreven: >> >>> I realized that the install instructions are not on the wiki where I do have edit >> permissions. The windows install instructions need to be freshened up a bit. What is the >> process to update those pages (e.g. http://misterhouse.sourceforge.net/install.html) >>> >>> Thank you, >>> Michael |
From: Marc M. <ma...@me...> - 2013-02-24 15:18:19
|
On Sun, Feb 24, 2013 at 08:29:55AM -0500, Eloy Paris wrote: > We are not doing anyone a favor by maintaining documentation in two > places so we need to decide where we are going to keep documentation and > stick with it. > > Personally I do not have any preference but I tend to favor wikispaces > because there is a lot of documentation there already. Unless, as > Michael says, someone takes on the task of moving things from wikispaces > to github. I kind of agree that having docs in 3 places doesn't make sense. Getting access to sf.net is "work" because you need an account and an invite. Getting access to wikispaces is easy, and lots of our docs are there, why not keep that? Github, I have nothing against, but I'm just not convinced that we need to move docs there from wikispaces. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Michael S. <mi...@st...> - 2013-02-24 15:48:58
|
All, I've stayed away from writing this email for many years. Mostly because I believe that if I have an opinion about improving something I should put up the time to get involved, but sadly I don't have enough motivation to get involved in documentation work. That being said, against my better judgment, I'll throw out a bit of history as I recall it (disclaimer) and offer some solutions that I think may have broad appeal to the list (maybe even Lieven J). If any of this is inflammatory, please accept my apologies; I didn't intend that. That being said feel free to say STFU and I'll go back to my selfish pursuit of Insteon support. The documentation, well... I think that Bruce Winter (the original MH developer) wrote most all of the "official" documentation. That is what you find on sourceforge.net (and redirected by misterhouse.net). Bruce still owns and maintains the misterhouse.net domain but as you can see it only forwards requests; I'm sure we can get him to forward that to any location and might even talk him out of the ownership if someone wants to pay the ICAN and DNS fees. Since Bruce there have been few if any attempts to keep the core documentation up to date; there has been an occasional attempt or two to add developer POD documentation for the code. One of us even made a big step forward in that area; but the user documentation is horribly out of date. Here's a broad categorization of the types of documentation available and some suggestions for each: Let me start by saying that I'm agnostic about "where" the documentation lives but I believe that someone needs to recreate/move "most all" of it from one of the three locations below if we are going to make a change. I do not think ignoring it all and starting over is the right thing to do as easy as it might sound because I believe will in fact make the problem worse. First I'll categorize the "types" of MH documentation, its purpose, and audience. There are currently three primary documentation sets each with a unique purpose: 1) User documentation: This is the documentation currently at http://misterhouse.sourceforge.net (and http://misterhouse.net). This documentation is also included in the source; so you can point your browser at: http://localhost:8080/ia5/index.shtml to see it. This documentation is aimed at the new user for installation and writing the user's own code. For the most part this is not "developer" documentation. This is the projects "official" documentation and should (I say this with a big grin) be the most accurate / stable. This documentation is horribly out of date (circa 2005) but wouldn't be that hard to clean up. 2) User "contributed" documentation: This is the documentation currently at http://misterhouse.wikispaces.com/. There are two types of documentation here: 1) user contributed documentation for user related tasks like how to enable some particular device; 2) a smidgen of developer documentation. 3) Developer documentation: This is mostly POD comments in the code. Like I said one of us made a lot of headway adding POD comments. There is a MH module to generate the POD docs. If that is running on your system you can see the docs here: http://localhost:8085/docs/objects.html, http://localhost:8085/docs/modules.html, http://localhost:8085/docs/items.html. In addition some of us have attempted to document various aspects of MH as we've discovered them. This documentation is in the wikispaces wiki and recently also in the Github wiki. Generally there isn't much of this type of documentation. OK, what do we do with all this? I don't think it is wise to attempt to throw it all out and start over. In addition there are few if any volunteers to improve it. What does that leave us with? 1) For official user documentation, this is included in the source and could stay there but needs a really good scrub if folks like Phil are going to have a better experience. a. Maybe someone could volunteer to just delete all the horribly old and difficult to maintain parts (e.g. the release changes). b. Maybe others could agree to be responsive to users on the mail list updating parts those users find wrong, misleading, or missing. c. Maybe someone could figure out how to automate displaying this in the Github wiki? "That" would be a great win for the project. i.e. clean it up but keep most of it, keep it in the source tree so developers can easily modify it, and automating the web display. I think this is in the spirit of Lieven's Github concept. This is also in the spirit of my concept where we move "most all" of a category and keep many excellent pages of documentation. 2) For user contributed documentation, I think we should leave this on a wiki with broad access so anyone (that isn't a spammer) can contribute. It will be a mess, wikis always are but that is part of the wiki experience. There are some options here: a. Leave it on wikispaces b. Move it "all" to Github, however it needs to be clear where the "official" documentation ends and user contributed (i.e. suspect) documentation starts. c. Either way maybe someone could volunteer to play editor and reorganize it a bit possibly tossing some of the oldest least accurate parts. d. Regardless I do volunteer to rework the landing page to make this clear distinction of documentation locations and purpose once we all agree on the direction. 3) For the developer documentation, there is so little it shouldn't be hard to consolidate it where ever we choose. It should be a combination of POD generated documentation and wiki for more general descriptions. a. Maybe this is the single best use of the Github wiki. If we put the official project documentation 1) there as well, then it needs to be clear where the user docs stop and the developer docs start. b. Maybe someone could figure out how to automate displaying this in the Github wiki? In summary I'm not implying that we need 3 "locations" for documentation just that we have 3 separate "types" that should be clearly delineated to avoid confusion. I think where we keep each should be based on 1st on the altruism of someone willing to edit it and 2nd on the ease of maintaining it. I believe we should address 1) above before looking at the others so newcomers like Phil will have a much easier time. I am very interested in a lively discussion on this topic especially by those that have in the past or will now volunteer to help out. Sincerely, Michael -----Original Message----- From: Marc MERLIN [mailto:ma...@me...] Sent: Sunday, February 24, 2013 9:18 AM To: Eloy Paris Cc: mis...@li... Subject: Re: [mh] Permissions to update sourceforge HTML pages On Sun, Feb 24, 2013 at 08:29:55AM -0500, Eloy Paris wrote: > We are not doing anyone a favor by maintaining documentation in two > places so we need to decide where we are going to keep documentation and > stick with it. > > Personally I do not have any preference but I tend to favor wikispaces > because there is a lot of documentation there already. Unless, as > Michael says, someone takes on the task of moving things from wikispaces > to github. I kind of agree that having docs in 3 places doesn't make sense. Getting access to sf.net is "work" because you need an account and an invite. Getting access to wikispaces is easy, and lots of our docs are there, why not keep that? Github, I have nothing against, but I'm just not convinced that we need to move docs there from wikispaces. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: <http://marc.merlins.org/> http://marc.merlins.org/ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: <http://p.sf.net/sfu/appdyn_d2d_feb> http://p.sf.net/sfu/appdyn_d2d_feb ________________________________________________________ To unsubscribe from this list, go to: <http://sourceforge.net/mail/?group_id=1365> http://sourceforge.net/mail/?group_id=1365 |
From: Michael S. <mi...@st...> - 2013-02-24 16:48:29
|
Does anyone know the process Bruce used to maintain the .pod and .html files in /docs "and" get those updates into SVN and the sourceforge page? It is easy enough to invent new processes but I'm wondering if someone had it written down. From: Michael Stovenour [mailto:mi...@st...] Sent: Sunday, February 24, 2013 9:49 AM To: mis...@li... Subject: Re: [mh] Permissions to update sourceforge HTML pages All, I've stayed away from writing this email for many years. Mostly because I believe that if I have an opinion about improving something I should put up the time to get involved, but sadly I don't have enough motivation to get involved in documentation work. That being said, against my better judgment, I'll throw out a bit of history as I recall it (disclaimer) and offer some solutions that I think may have broad appeal to the list (maybe even Lieven J). If any of this is inflammatory, please accept my apologies; I didn't intend that. That being said feel free to say STFU and I'll go back to my selfish pursuit of Insteon support. The documentation, well... I think that Bruce Winter (the original MH developer) wrote most all of the "official" documentation. That is what you find on sourceforge.net (and redirected by misterhouse.net). Bruce still owns and maintains the misterhouse.net domain but as you can see it only forwards requests; I'm sure we can get him to forward that to any location and might even talk him out of the ownership if someone wants to pay the ICAN and DNS fees. Since Bruce there have been few if any attempts to keep the core documentation up to date; there has been an occasional attempt or two to add developer POD documentation for the code. One of us even made a big step forward in that area; but the user documentation is horribly out of date. Here's a broad categorization of the types of documentation available and some suggestions for each: Let me start by saying that I'm agnostic about "where" the documentation lives but I believe that someone needs to recreate/move "most all" of it from one of the three locations below if we are going to make a change. I do not think ignoring it all and starting over is the right thing to do as easy as it might sound because I believe will in fact make the problem worse. First I'll categorize the "types" of MH documentation, its purpose, and audience. There are currently three primary documentation sets each with a unique purpose: 1) User documentation: This is the documentation currently at http://misterhouse.sourceforge.net (and http://misterhouse.net). This documentation is also included in the source; so you can point your browser at: http://localhost:8080/ia5/index.shtml to see it. This documentation is aimed at the new user for installation and writing the user's own code. For the most part this is not "developer" documentation. This is the projects "official" documentation and should (I say this with a big grin) be the most accurate / stable. This documentation is horribly out of date (circa 2005) but wouldn't be that hard to clean up. 2) User "contributed" documentation: This is the documentation currently at http://misterhouse.wikispaces.com/. There are two types of documentation here: 1) user contributed documentation for user related tasks like how to enable some particular device; 2) a smidgen of developer documentation. 3) Developer documentation: This is mostly POD comments in the code. Like I said one of us made a lot of headway adding POD comments. There is a MH module to generate the POD docs. If that is running on your system you can see the docs here: http://localhost:8085/docs/objects.html, http://localhost:8085/docs/modules.html, http://localhost:8085/docs/items.html. In addition some of us have attempted to document various aspects of MH as we've discovered them. This documentation is in the wikispaces wiki and recently also in the Github wiki. Generally there isn't much of this type of documentation. OK, what do we do with all this? I don't think it is wise to attempt to throw it all out and start over. In addition there are few if any volunteers to improve it. What does that leave us with? 1) For official user documentation, this is included in the source and could stay there but needs a really good scrub if folks like Phil are going to have a better experience. a. Maybe someone could volunteer to just delete all the horribly old and difficult to maintain parts (e.g. the release changes). b. Maybe others could agree to be responsive to users on the mail list updating parts those users find wrong, misleading, or missing. c. Maybe someone could figure out how to automate displaying this in the Github wiki? "That" would be a great win for the project. i.e. clean it up but keep most of it, keep it in the source tree so developers can easily modify it, and automating the web display. I think this is in the spirit of Lieven's Github concept. This is also in the spirit of my concept where we move "most all" of a category and keep many excellent pages of documentation. 2) For user contributed documentation, I think we should leave this on a wiki with broad access so anyone (that isn't a spammer) can contribute. It will be a mess, wikis always are but that is part of the wiki experience. There are some options here: a. Leave it on wikispaces b. Move it "all" to Github, however it needs to be clear where the "official" documentation ends and user contributed (i.e. suspect) documentation starts. c. Either way maybe someone could volunteer to play editor and reorganize it a bit possibly tossing some of the oldest least accurate parts. d. Regardless I do volunteer to rework the landing page to make this clear distinction of documentation locations and purpose once we all agree on the direction. 3) For the developer documentation, there is so little it shouldn't be hard to consolidate it where ever we choose. It should be a combination of POD generated documentation and wiki for more general descriptions. a. Maybe this is the single best use of the Github wiki. If we put the official project documentation 1) there as well, then it needs to be clear where the user docs stop and the developer docs start. b. Maybe someone could figure out how to automate displaying this in the Github wiki? In summary I'm not implying that we need 3 "locations" for documentation just that we have 3 separate "types" that should be clearly delineated to avoid confusion. I think where we keep each should be based on 1st on the altruism of someone willing to edit it and 2nd on the ease of maintaining it. I believe we should address 1) above before looking at the others so newcomers like Phil will have a much easier time. I am very interested in a lively discussion on this topic especially by those that have in the past or will now volunteer to help out. Sincerely, Michael -----Original Message----- From: Marc MERLIN [mailto:ma...@me...] Sent: Sunday, February 24, 2013 9:18 AM To: Eloy Paris Cc: mis...@li... Subject: Re: [mh] Permissions to update sourceforge HTML pages On Sun, Feb 24, 2013 at 08:29:55AM -0500, Eloy Paris wrote: > We are not doing anyone a favor by maintaining documentation in two > places so we need to decide where we are going to keep documentation and > stick with it. > > Personally I do not have any preference but I tend to favor wikispaces > because there is a lot of documentation there already. Unless, as > Michael says, someone takes on the task of moving things from wikispaces > to github. I kind of agree that having docs in 3 places doesn't make sense. Getting access to sf.net is "work" because you need an account and an invite. Getting access to wikispaces is easy, and lots of our docs are there, why not keep that? Github, I have nothing against, but I'm just not convinced that we need to move docs there from wikispaces. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: <http://marc.merlins.org/> http://marc.merlins.org/ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: <http://p.sf.net/sfu/appdyn_d2d_feb> http://p.sf.net/sfu/appdyn_d2d_feb ________________________________________________________ To unsubscribe from this list, go to: <http://sourceforge.net/mail/?group_id=1365> http://sourceforge.net/mail/?group_id=1365 |
From: Lieven H. <li...@li...> - 2013-02-25 19:07:37
|
Hello, Op 25-feb.-2013, om 02:26 heeft "Michael Stovenour" <mi...@st...> het volgende geschreven: > [..] > >> Code: gi...@gi...:hollie/misterhouse.git >> wiki : gi...@gi...:hollie/misterhouse.wiki.git >> >> But both are regular git repos and can be cloned as you wish. >> https://github.com/blog/699-making-github-more-open-git-backed-wikis >> >> I just don't know if pull requests and the like are supported on the wiki.git like they >> are supported for the codebase. > > The link above says they support push and pull. > Yes, push and pull are supported. But not pull requests through the web interface that we use to merge incoming requests. Not that this is a problem according to me, but just so that you know. > You mentioned support for pod in the wiki; do you know how that works? If the pod is in > the source code how do we get it into the wiki? > You checkout the misterhouse wiki git clone (hollie/misterhouse.wiki.git) and you add POD files and you commit them. They are then nicely rendered in the wiki. I just added a dummy example file here: https://github.com/hollie/misterhouse/wiki/Example-page-in-POD Kind regards, Lieven. |
From: Vargster <var...@gm...> - 2013-02-26 16:32:33
|
Right... let me clear this up... I will be (slowly) updating the info on the misterhouse.sourceforge.netwebsite. The main drivers for this are 1) the sourceforge page is the no.1 hit on Google, and 2) it looks *REALLY* bad that the last modified date is in 2008... There is a lot of very interesting info on there describing the depth/breadth of Misterhouse, which I think is good background reading for a newbie. That said, there are also a lot of dead links which I will try to update or remove. Where it starts getting into specifics of things like installation, I'm going to just remove them, and point to the wiki. If Michael can update the Windows Installation Instructions on the wiki that would be great. I've recently installed Mh on a fresh Ubuntu server box, so I've got notes for that which I'll use to bring the Ubuntu Installation Instructions up to date. I was also thinking of pressing the need to use the GIT repo, but also have a the GIT .zip download listed on the site? Thoughts? Lee On Mon, Feb 25, 2013 at 11:13 PM, Michael Stovenour <mi...@st...>wrote: > On Feb 25, 2013 1:05 PM Lieven wrote, > > > > Hi Michael, > > > > Op 25-feb.-2013, om 02:26 heeft "Michael Stovenour" < > mi...@st...> het volgende > > geschreven: > > [..] > > > > > You mentioned support for pod in the wiki; do you know how that works? > If the pod is > > > in the source code how do we get it into the wiki? > > > > > > > You checkout the misterhouse wiki git clone > (hollie/misterhouse.wiki.git) and you add > > POD files and you commit them. They are then nicely rendered in the > wiki. I just added a > > dummy example file here: > > https://github.com/hollie/misterhouse/wiki/Example-page-in-POD > > That is a great example. I think this can be easily integrated in the > existing "user" > documentation in /docs with just a simple maintenance script and someone > with write access > to both repositories (code and wiki). All the maintenance script would > need to do is > create the .html files for the "local user" documentation and copy the > .pod files across > (not sure where the source .pod files should live yet). For the > "developer" documentation > I'm not sure yet how we could pull the pod from the source code over to > the wiki just yet; > I assume there are probably existing tools for that. This just leaves the > wikispaces > wiki. It sounds like we have some volunteers to copy the stuff over; > which meets my > criteria for a rubber stamp. > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > ________________________________________________________ > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 > > |
From: Neil C. <nc...@li...> - 2013-02-26 17:41:46
|
On 02/26/2013 11:31 AM, Vargster wrote: > Right... let me clear this up... > > I will be (slowly) updating the info on the misterhouse.sourceforge.net > <http://misterhouse.sourceforge.net> website. > The main drivers for this are 1) the sourceforge page is the no.1 hit on Google, and 2) it > looks *REALLY* bad that the last modified date is in 2008... Yes, it's tough to tell folks who would be users (not developers) that they need to go to git or svn to get the latest software and that the project isn't dead. One additional thing to be careful of: don't remove a page instead redirect them. A lot of web sites that are only partially maintained jump to older MH web pages. Also a pretty welcome page is needed for the new users. The default SF web pages probably scare off more potential users than anything else. -- Linux Home Automation Neil Cherry nc...@li... http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog Author of: Linux Smart Homes For Dummies |
From: Michael S. <mi...@st...> - 2013-02-27 17:37:58
|
Ok, but realize that the sourceforge pages (i.e. "user" documentation) were created directly from the .html files in the /docs directory of the misterhouse source code. Those .html files were created from .pod files in the same directory. My recommendation is to: 1) correct the .pod files 2) run pod2html 3) check in the changes to Github hollie/misterhouse 4) sftp the .html files to the sourceforge server hosting the web pages Do you agree, disagree, or have modifications for this process? BTW the windows install instructions that new users find are not on the wiki, they are on the sourceforge.net pages: http://misterhouse.sourceforge.net/install.html. Those are the pages I intend to correct and I plan to use the process above unless we come up with a better one. Sincerely, Michael From: Vargster [mailto:var...@gm...] Sent: Tuesday, February 26, 2013 10:31 AM Cc: The main list for the MisterHouse home automation program Subject: Re: [mh] Permissions to update sourceforge HTML pages Right... let me clear this up... I will be (slowly) updating the info on the misterhouse.sourceforge.net website. The main drivers for this are 1) the sourceforge page is the no.1 hit on Google, and 2) it looks *REALLY* bad that the last modified date is in 2008... There is a lot of very interesting info on there describing the depth/breadth of Misterhouse, which I think is good background reading for a newbie. That said, there are also a lot of dead links which I will try to update or remove. Where it starts getting into specifics of things like installation, I'm going to just remove them, and point to the wiki. If Michael can update the Windows Installation Instructions on the wiki that would be great. I've recently installed Mh on a fresh Ubuntu server box, so I've got notes for that which I'll use to bring the Ubuntu Installation Instructions up to date. I was also thinking of pressing the need to use the GIT repo, but also have a the GIT .zip download listed on the site? Thoughts? Lee On Mon, Feb 25, 2013 at 11:13 PM, Michael Stovenour <mi...@st...> wrote: On Feb 25, 2013 1:05 PM Lieven wrote, > > Hi Michael, > > Op 25-feb.-2013, om 02:26 heeft "Michael Stovenour" <mi...@st...> het volgende > geschreven: > [..] > > > You mentioned support for pod in the wiki; do you know how that works? If the pod is > > in the source code how do we get it into the wiki? > > > > You checkout the misterhouse wiki git clone (hollie/misterhouse.wiki.git) and you add > POD files and you commit them. They are then nicely rendered in the wiki. I just added a > dummy example file here: > https://github.com/hollie/misterhouse/wiki/Example-page-in-POD That is a great example. I think this can be easily integrated in the existing "user" documentation in /docs with just a simple maintenance script and someone with write access to both repositories (code and wiki). All the maintenance script would need to do is create the .html files for the "local user" documentation and copy the .pod files across (not sure where the source .pod files should live yet). For the "developer" documentation I'm not sure yet how we could pull the pod from the source code over to the wiki just yet; I assume there are probably existing tools for that. This just leaves the wikispaces wiki. It sounds like we have some volunteers to copy the stuff over; which meets my criteria for a rubber stamp. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ________________________________________________________ To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 |
From: Marc M. <ma...@me...> - 2013-02-23 23:02:38
|
On Sat, Feb 23, 2013 at 08:00:05AM -0600, Michael Stovenour wrote: > I realized that the install instructions are not on the wiki where I do have edit > permissions. The windows install instructions need to be freshened up a bit. What is the > process to update those pages (e.g. http://misterhouse.sourceforge.net/install.html) Unfortunately, that one, I don't have access to. http://sourceforge.net/projects/misterhouse/?source=directory shows that people with access are: dnorwood2, gliming, mattrwilliams, tbs007, winter you should be able to Email them all with us...@us... and ask for access. If you don't get anywhere, let me know. I'll see if Gregg can give me access to sourceforge, and I'll give you access then. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Timothy S. <spa...@ic...> - 2013-02-24 00:42:08
|
Hi Marc, You are now a project admin for MH on SF. -----Original Message----- From: Marc MERLIN [mailto:ma...@me...] Sent: Saturday, February 23, 2013 6:02 PM To: Michael Stovenour Cc: mis...@li... Subject: Re: [mh] Permissions to update sourceforge HTML pages On Sat, Feb 23, 2013 at 08:00:05AM -0600, Michael Stovenour wrote: > I realized that the install instructions are not on the wiki where I > do have edit permissions. The windows install instructions need to be > freshened up a bit. What is the process to update those pages (e.g. > http://misterhouse.sourceforge.net/install.html) Unfortunately, that one, I don't have access to. http://sourceforge.net/projects/misterhouse/?source=directory shows that people with access are: dnorwood2, gliming, mattrwilliams, tbs007, winter you should be able to Email them all with us...@us... and ask for access. If you don't get anywhere, let me know. I'll see if Gregg can give me access to sourceforge, and I'll give you access then. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ________________________________________________________ To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 |
From: Marc M. <ma...@me...> - 2013-02-24 01:07:00
|
On Sun, Feb 24, 2013 at 12:27:31AM +0000, Timothy Spaulding wrote: > Hi Marc, > > You are now a project admin for MH on SF. Cool, much appreciated. Michael, if you don't have one, make an sf.net account, Email it to me off list, and I'll hook you up too so that you can update the windows page like you wanted. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Kevin R. K. <ke...@kr...> - 2013-02-24 15:40:20
|
My two cents after editing a lot on wikispaces. Wiki spaces is not a very good wiki system. For whatever reason evertime I paste something while editing, the text gets pasted in the correct spot, but my cursor moves to some random spot on the page. Annoying. I at least have no ability to rename pages or setup redirects, which is rough if I am going to clean up the pages we have. The save function is slow and tedious which discourages incremental saves. In all, the editing of things at wikispaces leaves a lot to be desired, especially for a website that specializes in wikis. With that said there is a lot of documentation at wikispaces. Moving that would be a real chore, plus who knows how many links exist out there. This is contrary to my prior position, but I am in favor of staying with wikispaces. Bad documentation is better than none. Plus of we all put some work into it, I think it could be converted into a good resource. On Feb 24, 2013 7:19 AM, "Marc MERLIN" <ma...@me...> wrote: > On Sun, Feb 24, 2013 at 08:29:55AM -0500, Eloy Paris wrote: > > We are not doing anyone a favor by maintaining documentation in two > > places so we need to decide where we are going to keep documentation and > > stick with it. > > > > Personally I do not have any preference but I tend to favor wikispaces > > because there is a lot of documentation there already. Unless, as > > Michael says, someone takes on the task of moving things from wikispaces > > to github. > > I kind of agree that having docs in 3 places doesn't make sense. > > Getting access to sf.net is "work" because you need an account and an > invite. > > Getting access to wikispaces is easy, and lots of our docs are there, why > not keep that? > > Github, I have nothing against, but I'm just not convinced that we need to > move docs there from wikispaces. > > Marc > -- > "A mouse is a device used to point at the xterm you want to type in" - > A.S.R. > Microsoft is to operating systems .... > .... what McDonalds is to gourmet > cooking > Home page: http://marc.merlins.org/ > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > ________________________________________________________ > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 > > |
From: Marc M. <ma...@me...> - 2013-02-24 15:54:16
|
On Sun, Feb 24, 2013 at 07:39:59AM -0800, Kevin Robert Keegan wrote: > My two cents after editing a lot on wikispaces. Wiki spaces is not a very > good wiki system. For whatever reason evertime I paste something while > editing, the text gets pasted in the correct spot, but my cursor moves to > some random spot on the page. Annoying. I noticed that once, although I usually edit in ascii using the wiki words, and inside itsalltext plugin (which means inside of gvim), so it's not been a big issue for me :) > The save function is slow and tedious which discourages incremental saves. Note that it auto saves drafts for you, and will recover the last unsaved draft if need be, so no need to save too often. By the way, thanks for the documention updates. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Lieven H. <li...@li...> - 2013-02-24 16:31:10
|
Hello all, at the risk of Michael calling me stubborn ;-) : an advantage of using git is that you can do: git clone gi...@gi...:hollie/misterhouse.wiki.git And you have all the pages of the wiki locally on your computer. You can then obviously edit them using your favorite editor instead of through an (in my opinion) non-so-efficient web interface. People who really insist on using a web-based interface to edit the wiki pagescan still do so, but there is a way around it if you prefer it. And to be clear: proposing the git wiki was just a suggestion. I'll follow whatever solution is selected. I just find myself editing the git wiki more easily compared to the wikispaces pages. Kind regards, Lieven. Op 24-feb.-2013, om 16:53 heeft Marc MERLIN <ma...@me...> het volgende geschreven: > On Sun, Feb 24, 2013 at 07:39:59AM -0800, Kevin Robert Keegan wrote: >> My two cents after editing a lot on wikispaces. Wiki spaces is not a very >> good wiki system. For whatever reason evertime I paste something while >> editing, the text gets pasted in the correct spot, but my cursor moves to >> some random spot on the page. Annoying. > > I noticed that once, although I usually edit in ascii using the wiki words, > and inside itsalltext plugin (which means inside of gvim), so it's not been > a big issue for me :) > >> The save function is slow and tedious which discourages incremental saves. > > Note that it auto saves drafts for you, and will recover the last unsaved > draft if need be, so no need to save too often. > > By the way, thanks for the documention updates. > > Marc > -- > "A mouse is a device used to point at the xterm you want to type in" - A.S.R. > Microsoft is to operating systems .... > .... what McDonalds is to gourmet cooking > Home page: http://marc.merlins.org/ > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > |
From: Michael S. <mi...@st...> - 2013-02-24 16:46:06
|
On Feb, 24 10:31 AM Lieven wrote, > > at the risk of Michael calling me stubborn ;-) : an advantage of using git is that you > can do: Lieven I welcome all your ideas and comments. You have single handily breathed a whole new life into the project for which I thank you. It is your vision and stubbornness that got us onto Github for the code base and I find that a welcome change. There is nothing wrong with stirring the documentation pot a little. Maybe it will encourage some action which IMO is better than no action at this point. Sincerely, Michael |
From: Phil M. <ph...@ph...> - 2013-02-24 18:18:47
|
> > And to be clear: proposing the git wiki was just a suggestion. I'll follow > whatever solution is selected. I just find myself editing the git wiki more > easily compared to the wikispaces pages. > After following all the threads about this documentation and the project in general it seems that everyone wants to have one place for everything but nobody is taking on the task of doing it. I am a newbie to Git but have caught on pretty well... Seems to me that Git is the correct choice to use as it makes it easy for everyone to submit updates and additions. Of course this is just my opinion but the project really needs one place to go and not have links all over the place leading a new user in different directions which in many cases is wrong! Would it be possible to get misterhouse.net to forward to Git? Is there anyone who is willing to be the project leader? I for one would be glad to help with consolidating all docs, etc to one location so that we as a group can have a place where anyone can find the project and all the details which would be accurate and up to date. Also it seems that most of the development/docs are geared toward Linux which is fine but a Windows centric page and how to would be really good to have as well as a latest compiled version for Windows. So that all being said I would be willing to move all the current docs to Git and then we can slowly update them there. Of course since I am new to MH I don't really know what is outdated or not so I would need help in editing. Lastly there seems like much back and forth about where the project should live but nobody is actually doing something about it. Should a vote be setup to see where it lives? I personally don't think leaving docs in one place, downloads in another would be any good. A nice landing page on the misterhouse.net domain that points to either Git or SVN would be the desired way to go in my opinion. Sorry if I am being to brash for a newcomer but I see the potential in MH and hate to see it just flounder like it is currently... Regards, Phil |
From: Michael S. <mi...@st...> - 2013-02-24 19:10:19
|
Phil, How about if you try "exposing" the existing "user documentation" on Github? See my earlier email for what I mean by "user documentation". The documentation is in .pod and .html files in the /docs directory. These are the pages that show up on sourceforge now. Lieven indicates that it is possible to have the wiki pages in a Github repository; I wonder if that means in the "same" repository as the code files? If so then maybe you can search Github for instructions? If you are willing, I think this approach might work: 1) Create your own Github account, if you don't already have one 2) Clone the MH repository 3) Explore, learn, and experiment with the wiki and the documentation on your repository until you figure out how to expose the /docs directory on your the wiki 4) Let those of us on the list take a look If the list likes what you have created we can then: 5) Pull your changes and repository configuration into hollie/misterhouse 6) Ask to have misternouse.net redirected to the Github landing page you created Bing.. Done and developers can easily update the user docs now. Sincerely, Michael From: Phil McDonnell [mailto:ph...@ph...] Sent: Sunday, February 24, 2013 12:18 PM To: mis...@li... Subject: Re: [mh] Permissions to update sourceforge HTML pages And to be clear: proposing the git wiki was just a suggestion. I'll follow whatever solution is selected. I just find myself editing the git wiki more easily compared to the wikispaces pages. After following all the threads about this documentation and the project in general it seems that everyone wants to have one place for everything but nobody is taking on the task of doing it. I am a newbie to Git but have caught on pretty well... Seems to me that Git is the correct choice to use as it makes it easy for everyone to submit updates and additions. Of course this is just my opinion but the project really needs one place to go and not have links all over the place leading a new user in different directions which in many cases is wrong! Would it be possible to get misterhouse.net to forward to Git? Is there anyone who is willing to be the project leader? I for one would be glad to help with consolidating all docs, etc to one location so that we as a group can have a place where anyone can find the project and all the details which would be accurate and up to date. Also it seems that most of the development/docs are geared toward Linux which is fine but a Windows centric page and how to would be really good to have as well as a latest compiled version for Windows. So that all being said I would be willing to move all the current docs to Git and then we can slowly update them there. Of course since I am new to MH I don't really know what is outdated or not so I would need help in editing. Lastly there seems like much back and forth about where the project should live but nobody is actually doing something about it. Should a vote be setup to see where it lives? I personally don't think leaving docs in one place, downloads in another would be any good. A nice landing page on the misterhouse.net domain that points to either Git or SVN would be the desired way to go in my opinion. Sorry if I am being to brash for a newcomer but I see the potential in MH and hate to see it just flounder like it is currently... Regards, Phil |
From: Lieven H. <li...@li...> - 2013-02-24 19:25:24
|
Hi Michael, nope the wiki is not the same repo as the code files. Code: gi...@gi...:hollie/misterhouse.git wiki : gi...@gi...:hollie/misterhouse.wiki.git But both are regular git repos and can be cloned as you wish. https://github.com/blog/699-making-github-more-open-git-backed-wikis I just don't know if pull requests and the like are supported on the wiki.git like they are supported for the codebase. On the other hand: I would have no problem if Phil (or somebody else :-) would start adding content to the wiki on hollie/misterhouse.wiki.git. The permission settings for the wiki are 'permissive' as in that everybody is able to edit right now. Since it is still a repo, not much harm can happen. If we would need to revert to a previous version due to some people misbehaving, then it is a simple one-liner. Kind regards, Lieven. Op 24-feb.-2013, om 20:10 heeft "Michael Stovenour" <mi...@st...> het volgende geschreven: > Phil, > How about if you try “exposing” the existing “user documentation” on Github? See my earlier email for what I mean by “user documentation”. The documentation is in .pod and .html files in the /docs directory. These are the pages that show up on sourceforge now. Lieven indicates that it is possible to have the wiki pages in a Github repository; I wonder if that means in the “same” repository as the code files? If so then maybe you can search Github for instructions? If you are willing, I think this approach might work: > > 1) Create your own Github account, if you don’t already have one > 2) Clone the MH repository > 3) Explore, learn, and experiment with the wiki and the documentation on your repository until you figure out how to expose the /docs directory on your the wiki > 4) Let those of us on the list take a look > > If the list likes what you have created we can then: > 5) Pull your changes and repository configuration into hollie/misterhouse > 6) Ask to have misternouse.net redirected to the Github landing page you created > > Bing…. Done and developers can easily update the user docs now. > > Sincerely, > Michael > > > From: Phil McDonnell [mailto:ph...@ph...] > Sent: Sunday, February 24, 2013 12:18 PM > To: mis...@li... > Subject: Re: [mh] Permissions to update sourceforge HTML pages > > And to be clear: proposing the git wiki was just a suggestion. I'll follow whatever solution is selected. I just find myself editing the git wiki more easily compared to the wikispaces pages. > > After following all the threads about this documentation and the project in general it seems that everyone wants to have one place for everything but nobody is taking on the task of doing it. > > I am a newbie to Git but have caught on pretty well... Seems to me that Git is the correct choice to use as it makes it easy for everyone to submit updates and additions. Of course this is just my opinion but the project really needs one place to go and not have links all over the place leading a new user in different directions which in many cases is wrong! > > Would it be possible to get misterhouse.net to forward to Git? Is there anyone who is willing to be the project leader? I for one would be glad to help with consolidating all docs, etc to one location so that we as a group can have a place where anyone can find the project and all the details which would be accurate and up to date. > > Also it seems that most of the development/docs are geared toward Linux which is fine but a Windows centric page and how to would be really good to have as well as a latest compiled version for Windows. > > So that all being said I would be willing to move all the current docs to Git and then we can slowly update them there. Of course since I am new to MH I don't really know what is outdated or not so I would need help in editing. > > Lastly there seems like much back and forth about where the project should live but nobody is actually doing something about it. Should a vote be setup to see where it lives? I personally don't think leaving docs in one place, downloads in another would be any good. A nice landing page on the misterhouse.net domain that points to either Git or SVN would be the desired way to go in my opinion. > > Sorry if I am being to brash for a newcomer but I see the potential in MH and hate to see it just flounder like it is currently... > > Regards, > Phil > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 |
From: Michael S. <mi...@st...> - 2013-02-25 01:26:32
|
On Feb 24, 2013 1:25 PM Lieven wrote, > > nope the wiki is not the same repo as the code files. OK, so then we just need a short process to create the local documentation .html files and copy the .pod file to the wiki repository. I suppose this will require keeping two separate repositories on the same development system. Then commit each one separately to update the documentation. > Code: gi...@gi...:hollie/misterhouse.git > wiki : gi...@gi...:hollie/misterhouse.wiki.git > > But both are regular git repos and can be cloned as you wish. > https://github.com/blog/699-making-github-more-open-git-backed-wikis > > I just don't know if pull requests and the like are supported on the wiki.git like they > are supported for the codebase. The link above says they support push and pull. You mentioned support for pod in the wiki; do you know how that works? If the pod is in the source code how do we get it into the wiki? |
From: Vargster <var...@gm...> - 2013-02-25 15:14:01
|
As the open source saying goes, if you don't like, fix it. OK, I'll put myself forward to fix/update the misterhouse.net/misterhouse.com websites if anyone can get access to it. Personally I love the website, but it needs pruning of all the misleading stuff, and some new pointers to the GIT repo. So, I'll fix it, if I can get access, or even host it if needed. Lee On Mon, Feb 25, 2013 at 1:26 AM, Michael Stovenour <mi...@st...>wrote: > On Feb 24, 2013 1:25 PM Lieven wrote, > > > > nope the wiki is not the same repo as the code files. > > OK, so then we just need a short process to create the local documentation > .html files and > copy the .pod file to the wiki repository. I suppose this will require > keeping two > separate repositories on the same development system. Then commit each > one separately to > update the documentation. > > > Code: gi...@gi...:hollie/misterhouse.git > > wiki : gi...@gi...:hollie/misterhouse.wiki.git > > > > But both are regular git repos and can be cloned as you wish. > > https://github.com/blog/699-making-github-more-open-git-backed-wikis > > > > I just don't know if pull requests and the like are supported on the > wiki.git like they > > are supported for the codebase. > > The link above says they support push and pull. > > You mentioned support for pod in the wiki; do you know how that works? If > the pod is in > the source code how do we get it into the wiki? > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > ________________________________________________________ > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 > > |
From: Marc M. <ma...@me...> - 2013-02-25 15:19:05
|
On Mon, Feb 25, 2013 at 03:13:34PM +0000, Vargster wrote: > As the open source saying goes, if you don't like, fix it. > > OK, I'll put myself forward to fix/update the > misterhouse.net/misterhouse.com websites if anyone can get access to it. > Personally I love the website, but it needs pruning of all the misleading > stuff, and some new pointers to the GIT repo. > So, I'll fix it, if I can get access, or even host it if needed. Email me your sf.net login and I can give you access. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |