Are we talking days, weeks or months before this 7.5/7.7 split? I've got a few non-core items that I think I (or others) need to address before 7.6:
1. Autodocs: there are a number of modules and or functions that aren't documented well or at all (the readline and termcap stuff comes to mind). Also, one of the biggest complaints about the modref is that there are so few examples. If everyone could just take an hour or two to document or expand the documentation for a few functions, it would be a great help.
2. Modules: is there a general feeling about how big a deal external modules are going to be for 7.6? Do we need to test the procedures out more, and have documentation about how developers/end users go about creating and installing them? Should I try to finish my "module grab and install" code? The "server side" of this is almost finished, but the client end is barely started. Anyone want to help out with this?
Bill
I'm aiming for in a week or two.
- Autodocs:
That's a non-issue. Any documentation that gets checked in appears on the website when the next doc dump is made, which usually happens within days of major improvements. We've tried numerous different ways to get people to contribute documentation, but it is fairly obvious that it isn't something people are interested in doing. We could perhaps fold back the five or so examples contributed to the caudium documentation site...
My bet is that readline and terminfo will remain undocumented until grubba, you or I decides to endure the pain for the benefit of mankind.
- Modules:
This is more of an issue. The important thing is that the module package "API" is good enough that we can live with it at least until 7.8. Is there a concise description of how a package should look like and the procedures for installing it? Such documentation is possibly a blocker, so that everyone gets the chance discover why it wouldn't work for them. Aspects to consider are
- Stand alone source package (downloaded from the Great External Module Storage (GEMS) or Pike Module Storage).
- Source and binary packages for the major package formats (rpm, deb, gentoo).
- Binary packages for Windows.
/ Martin Nilsson (provokatör)
Previous text:
2004-03-22 05:20: Subject: 7.6
Are we talking days, weeks or months before this 7.5/7.7 split? I've got a few non-core items that I think I (or others) need to address before 7.6:
- Autodocs: there are a number of modules and or functions that aren't
documented well or at all (the readline and termcap stuff comes to mind). Also, one of the biggest complaints about the modref is that there are so few examples. If everyone could just take an hour or two to document or expand the documentation for a few functions, it would be a great help.
- Modules: is there a general feeling about how big a deal external
modules are going to be for 7.6? Do we need to test the procedures out more, and have documentation about how developers/end users go about creating and installing them? Should I try to finish my "module grab and install" code? The "server side" of this is almost finished, but the client end is barely started. Anyone want to help out with this?
Bill
/ Brevbäraren
On Mon, Mar 22, 2004 at 05:50:02AM +0100, Martin Nilsson (provokatör) @ Pike (-) developers forum wrote:
This is more of an issue. The important thing is that the module package "API" is good enough that we can live with it at least until 7.8.
The only problem with that is documentation - huge part of this API is not (really) documented, even briefly (like get_all_args() etc)...
Even short reference would be good [function(args): purpose], but existing docs cover only very limited subset (actually, an overview).
Regards, /Al
That is not the API I was talking about. You are talking about the module API (what functions are available), not the package API (what options to use when compiling, where to put files etc).
/ Martin Nilsson (provokatör)
Previous text:
2004-03-22 07:49: Subject: Re: 7.6
On Mon, Mar 22, 2004 at 05:50:02AM +0100, Martin Nilsson (provokatör) @ Pike (-) developers forum wrote:
This is more of an issue. The important thing is that the module package "API" is good enough that we can live with it at least until 7.8.
The only problem with that is documentation - huge part of this API is not (really) documented, even briefly (like get_all_args() etc)...
Even short reference would be good [function(args): purpose], but existing docs cover only very limited subset (actually, an overview).
Regards, /Al
/ Brevbäraren
That's a non-issue. Any documentation that gets checked in appears on the website when the next doc dump is made, which usually happens within days of major improvements. We've tried numerous different ways to get people to contribute documentation, but it is fairly obvious that it isn't something people are interested in doing. We could perhaps fold back the five or so examples contributed to the caudium documentation site...
My bet is that readline and terminfo will remain undocumented until grubba, you or I decides to endure the pain for the benefit of mankind.
I guess I was suggesting that a "day of documentation" might be a good thing to consider. I personally hate writing documentation, but I know what it's a necessary evil and so occasionally "bit the bullet".
- Modules:
This is more of an issue. The important thing is that the module package "API" is good enough that we can live with it at least until 7.8. Is there a concise description of how a package should look like and the procedures for installing it? Such documentation is possibly a blocker, so that everyone gets the chance discover why it wouldn't work for them.
I've written a few modules that use the new "API", but I certainly don't think it's finished or tested well enough just yet. I don't think it would take a whole lot of work to do it, but I could use a little help.
Aspects to consider are
- Stand alone source package (downloaded from the Great External Module Storage (GEMS) or Pike Module Storage).
As a standalone module that's been downloaded to the local host, it seems to work well, provided it follows the "rules" from this document:
http://steam.iaeste.at/Pike/ExternalModules/PikeModules.html
I have a few things I'd like to do, such as:
include recommendations for more "metadata files" such as AUTHORS, LICENSE, etc.
add a target that prepares a module for "distribution": builds a module documentation, cleans up unnecessary files, checks for recommended metadata files, etc.
I've got a basic "repository" website set up, if anyone wants to take a look.
http://modules.gotpike.org:8000/test.html
Feel free to take a look.
- Source and binary packages for the major package formats (rpm, deb, gentoo).
Is this something that should be tied to a release? That is, are there things that need to be added in order to generate these sorts of packages, or is the idea to make them available for download along with the source? Is this even a good idea (it seems like a slippery slope; spending lots of time working on making binary packages when we could be better spending our limited time?) Just thought I'd present a potentially opposing viewpoint.
- Binary packages for Windows.
Will pike -x module even work on Windows? Perhaps under cygwin? I can understand the need for Windows binary packages, as most windows users won't have a compiler environment installed.
Bill
I've written a few modules that use the new "API", but I certainly don't think it's finished or tested well enough just yet. I don't think it would take a whole lot of work to do it, but I could use a little help.
How about pike-code only modules? Most of the external modules would be of this kind, so requiring e.g. configure.in is a bit redundant.
Is this even a good idea (it seems like a slippery slope; spending lots of time working on making binary packages when we could be better spending our limited time?)
The issue was really if there is an issue... Is there anything in the "API" that needs to be aware of binary and source distributions with other package systems.
/ Martin Nilsson (provokatör)
Previous text:
2004-03-22 17:39: Subject: Re: 7.6
That's a non-issue. Any documentation that gets checked in appears on the website when the next doc dump is made, which usually happens within days of major improvements. We've tried numerous different ways to get people to contribute documentation, but it is fairly obvious that it isn't something people are interested in doing. We could perhaps fold back the five or so examples contributed to the caudium documentation site...
My bet is that readline and terminfo will remain undocumented until grubba, you or I decides to endure the pain for the benefit of mankind.
I guess I was suggesting that a "day of documentation" might be a good thing to consider. I personally hate writing documentation, but I know what it's a necessary evil and so occasionally "bit the bullet".
- Modules:
This is more of an issue. The important thing is that the module package "API" is good enough that we can live with it at least until 7.8. Is there a concise description of how a package should look like and the procedures for installing it? Such documentation is possibly a blocker, so that everyone gets the chance discover why it wouldn't work for them.
I've written a few modules that use the new "API", but I certainly don't think it's finished or tested well enough just yet. I don't think it would take a whole lot of work to do it, but I could use a little help.
Aspects to consider are
- Stand alone source package (downloaded from the Great External Module Storage (GEMS) or Pike Module Storage).
As a standalone module that's been downloaded to the local host, it seems to work well, provided it follows the "rules" from this document:
http://steam.iaeste.at/Pike/ExternalModules/PikeModules.html
I have a few things I'd like to do, such as:
include recommendations for more "metadata files" such as AUTHORS, LICENSE, etc.
add a target that prepares a module for "distribution": builds a module documentation, cleans up unnecessary files, checks for recommended metadata files, etc.
I've got a basic "repository" website set up, if anyone wants to take a look.
http://modules.gotpike.org:8000/test.html
Feel free to take a look.
- Source and binary packages for the major package formats (rpm, deb, gentoo).
Is this something that should be tied to a release? That is, are there things that need to be added in order to generate these sorts of packages, or is the idea to make them available for download along with the source? Is this even a good idea (it seems like a slippery slope; spending lots of time working on making binary packages when we could be better spending our limited time?) Just thought I'd present a potentially opposing viewpoint.
- Binary packages for Windows.
Will pike -x module even work on Windows? Perhaps under cygwin? I can understand the need for Windows binary packages, as most windows users won't have a compiler environment installed.
Bill
/ Brevbäraren
pike-devel@lists.lysator.liu.se
-
Alexander Demenshin -
Bill Welliver -
Martin Nilsson (provokat�r) ＠ Pike (-) developers forum