Another thought I had was that I think that it should be possible for the repository to hold modules for both well known places in the tree (such as Protocols.HTTP.*) as well as a sort of Public area (such as the PRAWN.* namespace :)).
Modules that want to get into a well known location would have to jump through more hoops, from both a sanity and quality perspective. There'd be less control over the Public location, and you'd basically be able to get a whole subtree such as PRAWN.Protocols.BillsJabberClient or PRAWN.Parser.PigLatin.
Any thoughts?
Bill
Hello,
Assuming you already have an author login/handle for the system one might consider using Author.<authorhandle>.* as a location for any non-registered modules that author has uploaded, thus allowing users to start using/testing someone's module before it has gone through the entire review/acceptance process. Afterwards it would be a simple matter of search/replace when it does get accepted into the main tree.
ex: Author.Peter27.JabberClient
My two cents.
Peter.
-----Original Message----- From: pike-devel-admin@lists.lysator.liu.se [mailto:pike-devel-admin@lists.lysator.liu.se] On Behalf Of Bill Welliver Sent: donderdag 16 oktober 2003 20:28 To: pike-devel@lists.lysator.liu.se Subject: more module repository ramblings
Another thought I had was that I think that it should be possible for the repository to hold modules for both well known places in the tree (such as Protocols.HTTP.*) as well as a sort of Public area (such as the PRAWN.* namespace :)).
Modules that want to get into a well known location would have to jump through more hoops, from both a sanity and quality perspective. There'd be less control over the Public location, and you'd basically be able to get a whole subtree such as PRAWN.Protocols.BillsJabberClient or PRAWN.Parser.PigLatin.
Any thoughts?
Bill
That's actually a clever idea, but it causes problems because currently, the module name is specified in the module build files. Presumably, the author will not make the module available before he has a place for it, but it would certainly be simple to browse for modules by author.
Bill
On Thu, 16 Oct 2003, Peter M. Lemmen wrote:
Hello,
Assuming you already have an author login/handle for the system one might consider using Author.<authorhandle>.* as a location for any non-registered modules that author has uploaded, thus allowing users to start using/testing someone's module before it has gone through the entire review/acceptance process. Afterwards it would be a simple matter of search/replace when it does get accepted into the main tree.
ex: Author.Peter27.JabberClient
My two cents.
Peter.
-----Original Message----- From: pike-devel-admin@lists.lysator.liu.se [mailto:pike-devel-admin@lists.lysator.liu.se] On Behalf Of Bill Welliver Sent: donderdag 16 oktober 2003 20:28 To: pike-devel@lists.lysator.liu.se Subject: more module repository ramblings
Another thought I had was that I think that it should be possible for the repository to hold modules for both well known places in the tree (such as Protocols.HTTP.*) as well as a sort of Public area (such as the PRAWN.* namespace :)).
Modules that want to get into a well known location would have to jump through more hoops, from both a sanity and quality perspective. There'd be less control over the Public location, and you'd basically be able to get a whole subtree such as PRAWN.Protocols.BillsJabberClient or PRAWN.Parser.PigLatin.
Any thoughts?
Bill
Hello,
Hmm, I would assume that accepting a module into the main tree is a non-trivial operation anyway. (Moving the sources, changing authorization, possibly changing the license/ownership of the code...) Modifying a make file is just one more step. (Which no doubt could be automated if necessary.)
Also, I could imagine certain modules, while perfectly usable, will never make it into the main tree because of code quality, documentation or licensing issues. For instance, Al might want to write a great module and allow it to be distributed, but as long as he doesn't sign over ownership to IDA it won't get into the main tree. Having your own personal space in the module tree would still allow this module to be distributed with the same tools as the main ones are.
Another two cents.
Peter.
-----Original Message----- From: pike-devel-admin@lists.lysator.liu.se [mailto:pike-devel-admin@lists.lysator.liu.se] On Behalf Of Bill Welliver Sent: donderdag 16 oktober 2003 20:46 To: peter@lemmen.net Cc: pike-devel@lists.lysator.liu.se Subject: RE: more module repository ramblings
That's actually a clever idea, but it causes problems because currently, the module name is specified in the module build files. Presumably, the author will not make the module available before he has a place for it, but it would certainly be simple to browse for modules by author.
Bill
On Thu, 16 Oct 2003, Peter M. Lemmen wrote:
Hello,
Assuming you already have an author login/handle for the system one might consider using Author.<authorhandle>.* as a location for any non-registered modules that author
has uploaded,
thus allowing users to start using/testing someone's module
before it
has gone through the entire review/acceptance process. Afterwards it would be a simple matter of search/replace when it does get accepted into the main tree.
ex: Author.Peter27.JabberClient
My two cents.
Peter.
-----Original Message----- From: pike-devel-admin@lists.lysator.liu.se [mailto:pike-devel-admin@lists.lysator.liu.se] On Behalf Of Bill Welliver Sent: donderdag 16 oktober 2003 20:28 To: pike-devel@lists.lysator.liu.se Subject: more module repository ramblings
Another thought I had was that I think that it should be possible for the repository to hold modules for both well known places in the tree (such as Protocols.HTTP.*) as well as a sort of Public area (such as the PRAWN.* namespace :)).
Modules that want to get into a well known location would
have to jump
through more hoops, from both a sanity and quality perspective. There'd be less control over the Public location, and you'd basically be able to get a whole subtree such as PRAWN.Protocols.BillsJabberClient or PRAWN.Parser.PigLatin.
Any thoughts?
Bill
I meant "main tree" as in "not in the PUMA/PRAWN/whatever namespace". It's an entirely different story to get a module in the "core" of pike. I would think that availability of a working repository would make it even more difficult.
Bill
On Thu, 16 Oct 2003, Peter M. Lemmen wrote:
Hello,
Hmm, I would assume that accepting a module into the main tree is a non-trivial operation anyway. (Moving the sources, changing authorization, possibly changing the license/ownership of the code...) Modifying a make file is just one more step. (Which no doubt could be automated if necessary.)
Also, I could imagine certain modules, while perfectly usable, will never make it into the main tree because of code quality, documentation or licensing issues. For instance, Al might want to write a great module and allow it to be distributed, but as long as he doesn't sign over ownership to IDA it won't get into the main tree. Having your own personal space in the module tree would still allow this module to be distributed with the same tools as the main ones are.
Another two cents.
Peter.
-----Original Message----- From: pike-devel-admin@lists.lysator.liu.se [mailto:pike-devel-admin@lists.lysator.liu.se] On Behalf Of Bill Welliver Sent: donderdag 16 oktober 2003 20:46 To: peter@lemmen.net Cc: pike-devel@lists.lysator.liu.se Subject: RE: more module repository ramblings
That's actually a clever idea, but it causes problems because currently, the module name is specified in the module build files. Presumably, the author will not make the module available before he has a place for it, but it would certainly be simple to browse for modules by author.
Bill
On Thu, 16 Oct 2003, Peter M. Lemmen wrote:
Hello,
Assuming you already have an author login/handle for the system one might consider using Author.<authorhandle>.* as a location for any non-registered modules that author
has uploaded,
thus allowing users to start using/testing someone's module
before it
has gone through the entire review/acceptance process. Afterwards it would be a simple matter of search/replace when it does get accepted into the main tree.
ex: Author.Peter27.JabberClient
My two cents.
Peter.
-----Original Message----- From: pike-devel-admin@lists.lysator.liu.se [mailto:pike-devel-admin@lists.lysator.liu.se] On Behalf Of Bill Welliver Sent: donderdag 16 oktober 2003 20:28 To: pike-devel@lists.lysator.liu.se Subject: more module repository ramblings
Another thought I had was that I think that it should be possible for the repository to hold modules for both well known places in the tree (such as Protocols.HTTP.*) as well as a sort of Public area (such as the PRAWN.* namespace :)).
Modules that want to get into a well known location would
have to jump
through more hoops, from both a sanity and quality perspective. There'd be less control over the Public location, and you'd basically be able to get a whole subtree such as PRAWN.Protocols.BillsJabberClient or PRAWN.Parser.PigLatin.
Any thoughts?
Bill
No, we can have modules of any license in the main tree from a namespace point of view. They might not be located on the same server as e.g Stdio and String, but that should be unimportant in the future.
/ Martin Nilsson (saturator)
Previous text:
2003-10-16 21:54: Subject: RE: more module repository ramblings
Hello,
Hmm, I would assume that accepting a module into the main tree is a non-trivial operation anyway. (Moving the sources, changing authorization, possibly changing the license/ownership of the code...) Modifying a make file is just one more step. (Which no doubt could be automated if necessary.)
Also, I could imagine certain modules, while perfectly usable, will never make it into the main tree because of code quality, documentation or licensing issues. For instance, Al might want to write a great module and allow it to be distributed, but as long as he doesn't sign over ownership to IDA it won't get into the main tree. Having your own personal space in the module tree would still allow this module to be distributed with the same tools as the main ones are.
Another two cents.
Peter.
-----Original Message----- From: pike-devel-admin@lists.lysator.liu.se [mailto:pike-devel-admin@lists.lysator.liu.se] On Behalf Of Bill Welliver Sent: donderdag 16 oktober 2003 20:46 To: peter@lemmen.net Cc: pike-devel@lists.lysator.liu.se Subject: RE: more module repository ramblings
That's actually a clever idea, but it causes problems because currently, the module name is specified in the module build files. Presumably, the author will not make the module available before he has a place for it, but it would certainly be simple to browse for modules by author.
Bill
On Thu, 16 Oct 2003, Peter M. Lemmen wrote:
Hello,
Assuming you already have an author login/handle for the system one might consider using Author.<authorhandle>.* as a location for any non-registered modules that author
has uploaded,
thus allowing users to start using/testing someone's module
before it
has gone through the entire review/acceptance process. Afterwards it would be a simple matter of search/replace when it does get accepted into the main tree.
ex: Author.Peter27.JabberClient
My two cents.
Peter.
-----Original Message----- From: pike-devel-admin@lists.lysator.liu.se [mailto:pike-devel-admin@lists.lysator.liu.se] On Behalf Of Bill Welliver Sent: donderdag 16 oktober 2003 20:28 To: pike-devel@lists.lysator.liu.se Subject: more module repository ramblings
Another thought I had was that I think that it should be possible for the repository to hold modules for both well known places in the tree (such as Protocols.HTTP.*) as well as a sort of Public area (such as the PRAWN.* namespace :)).
Modules that want to get into a well known location would
have to jump
through more hoops, from both a sanity and quality perspective. There'd be less control over the Public location, and you'd basically be able to get a whole subtree such as PRAWN.Protocols.BillsJabberClient or PRAWN.Parser.PigLatin.
Any thoughts?
Bill
/ Brevbäraren
No, it will always be important which modules get installed by default, and distribution and hence licenses is part of that.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-10-16 22:00: Subject: RE: more module repository ramblings
No, we can have modules of any license in the main tree from a namespace point of view. They might not be located on the same server as e.g Stdio and String, but that should be unimportant in the future.
/ Martin Nilsson (saturator)
right, of course modules that are installed by default need to have the right license, but other modules may still live in the main namespace tree without a matching license.
greetings, martin.
the way debian organizes packages may have some ideas here:
debs are part of: base, main, contrib, or non-free. pike might have: core, main, contrib
core is what is in pike cvs now. main is everything that fits in the main namespace tree, and contrib is the rest.
debs have a priority of: required, standard, optional, recommended... pike modules could have the same.
required would be everything necesary to have a working pike. standard everything we want installed by default optional the rest
then there is of course the issue of dependencies...
greetings, martin.
required would be everything necesary to have a working pike.
Define "working pike". Is it enough to be able to start Hilfe, or what level of functionality should we aim for here?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-10-17 16:48: Subject: Re: more module repository ramblings
the way debian organizes packages may have some ideas here:
debs are part of: base, main, contrib, or non-free. pike might have: core, main, contrib
core is what is in pike cvs now. main is everything that fits in the main namespace tree, and contrib is the rest.
debs have a priority of: required, standard, optional, recommended... pike modules could have the same.
required would be everything necesary to have a working pike. standard everything we want installed by default optional the rest
then there is of course the issue of dependencies...
greetings, martin.
/ Brevbäraren
that would be one thing we need to work out. i guess those that have been trying to use pike on small machines should speak up here.
what is the minimum necessary to have a working pike?
greetings, martin.
no, the main tree here is just the main tree of classes. not the core pike source tree.
the point is that you can have an 'official' Protocols.NNTP.Client, without it being part of the pike core.
in fact i expect that some things may be moved away from the core once this is set up and working.
so acceptance into the main tree would only be a renaming nothing else.
greetings, martin.
pike-devel@lists.lysator.liu.se
-
Bill Welliver -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum -
Martin Baehr -
Martin Nilsson (saturator) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Peter M. Lemmen