[Serdev] Re: SER experimental

Tue Dec 5 14:21:30 UTC 2006

Hi Bogdan,
Thanks for your thoughtful comments. The issue was discussed on serdev a 
while back, but there is probably still room for change. The modules 
have each been assigned a status (http://iptel.org/views/moduledocs), 
but the make updates have not been done yet.

See inline.

>> So, what we proposed, was the following:
>> 1. main modules directory is opened up to modules of all development
>> levels
>> 2. as cvs makes it hard to move with history, making a modules dir
>> tree was not wanted. Instead the modules get classified as having a
>> status (see SER-177) and the make should be updated to allow modules
>> of a certain status to be targeted for compilation. The status are:
>> standard, stable, other, and experimental (see SER-177 for details)
>>     
>
> I'm not sure how well on track the module splitting is (in getting
> acceptance), but I would challenge it; some observations:
>
> * (SER-177:) "Modules with external library dependencies should be of
> very core nature to be included as a standard module. "
> I don't want to comment till I don't see the set you would consider as
> matching the above definition (or some examples). But just some blind
> observations from personal packaging experience:
>   - (as you probably know) the external dependent modules were excluded
> to avoid SER having to install a large base into a distribution package
> scenario.
>   - there isn't significant drawback in having to: install an extra
> package _or_ know that you have to compile with extra options
> (equivalent of well established and accepted autoconf's "--with-module").
>
>   
I think the basic idea was that it should be possible to get a SER up 
and running with the standard modules without a lot of dependencies. How 
"core" a module can be considered to be, IMHO, is based on the number of 
setups using it. I dare not try to set a percentage. I think it should 
be up to the developers to decide whether a module is to be considered 
as standard or not. 

My only take is that the standard modules should be a guidance for new 
users, so that they can compile SER with the "standard modules" and 
expect the resulting SER to do something meaningful (defined as 
something expected to a majority of new users).  If you like, you can 
use the hello world-cfg from SER - Getting Started doc as a definition 
of standard, or maybe the callfwd-features.cfg.  I don't know, it's 
debatable.
> * the difference between "standard" and "stable" is too thin -
> considering what the quote above suggests - and I fail to see the benefit:
>   - when building for some distribution, they will probably end up as
> being both groups included;
>   
yes, probably, or standard + a subset of stable.  I don't see these 
categories as meaningful from a packaging point of view. Developers and 
those packaging can very well continue to target explicit modules (and 
probably will).
I would expect that SER w/ standard modules is pretty easy to build, 
while I would expect that I had to satisfy some dependencies when 
including stable.
>   - when self building, people will most certainly build both groups: 1.
> "Why not?" 2. "I'm not really sure what I need."
>   
Well, if the compile fails due to dependencies that cannot be satisfies, 
I would expect people either to start installing the dependencies or 
remove modules with dependencies until they have a subset that does not 
have dependencies (i.e. you have standard).  I don't like to install 
lots of dependencies that I don't really know whether I need. 
Dependencies have a tendency to make my day a bit longer...
> * (SER-177:) " other are modules that are in general use, but were not
> enough experience has been gained to include it in stable"
> The definition (partially, but considerably) overlaps 'experimental':
>   - having degrees of "experimentalness" doesn't help too much, neither
> in maintaining, nor in usage;
>   
Yes, in usage. You can expect modules in other to perform according to 
the documentation, while the experimental would probably be lacking in 
documentation, completeness, and stability. Thus, you would as a user 
look for modules solving a specific task in other and you would test 
your config a bit more thoroughly.  You would probably not put an 
experimental module in production.
>   - I don't imagine anyone trying '$ make include_modules=group-others'
> or '... =group-experimental', but rather specify the exact set of
> modules one needs.
>   
Yes, you are maybe right, but you actually here give argument 
contradicting your argument above. I would imagine somebody testing out 
SER would probably add group-others just in case they are needed, and 
then later in the search for what is on the bleeding edge do a make 
=group-experimental to compile those as 

Also, as you can see from the module doc link I gave above, this 
categorization is not only about the build system, but also for 
communicating some sort of status to users. 
> Right now we have 'stable+standard' and
> 'with_depenencies+not_yet_mature' (=excluded); the latter is maybe not
> so clean from administrative point of view. To be added:
> 'some_more_not_yet_mature'.
> I would dare to suggest that three categories suffice (naming as hint):
> *  standard:
>   - dependency free and stable
>   - would be built by '$ make all/modules'
>   - would end up into SER's distribution package.
> * standard-dep:
>   - dependency tied
>   - would require the 'include_modules' directive (as now)
>   - each would end up as a package (or grouped into packages, if
> logically/functionally bound)
> * experimental:
>   - require 'include_modules' directive
>   - never package distributed
>   (- would also have to respect doc/cvs-commit-rules.txt [to hopefully
> be changed to some other non fossil XXX-commint-rules])
>   
Well, I think this is a good suggestion for sharpening up the 
definition. Mostly I agree, except that I would like to have a fourth 
stable category that can hold modules like osp, which is arguably not 
standard in any way, but which would not benefit (nor deserve) being 
classified as experimental.
g-)
> This is not the ideal split: there are cases where dependency free
> modules only make sense together with dependency tied ones; presence
> modules form such a group. But I think we can assume this irregularity.
>
> The makefiles already supports this split, but lacks explicit group
> naming (which is arguably bad).
>
>
>   Bogdan.
>
>
>   
>> 3. We have a system established at iptel.org for contributions
>> (http://www.iptel.org/ser/contributions)
>> Modules that are not natural to maintain in ser's modules directory
>> can be hosted by other repositories (if they are a project in their
>> own right like openIMS) or on a case-by-case basis, we can allow
>> hosting for projects (in a separate CVS module like experimental) that
>> just need cvs and that may or may not want to be included in the main
>> modules directory
>>
>> This means that the oracle module would just reside in experimental
>> CVS module for now and if you are not able to update it to Ottendorf
>> before release, you can make a source package and add it at
>> http://www.iptel.org/ser/contributions
>>
>> Makes sense?
>> g-)
>>
>> Dmitry Semyonov wrote:
>>     
>>> Greger,
>>>
>>> On Wed, 29 Nov 2006 at 13:42 +0100, Greger V. Teigre wrote:
>>>
>>>   
>>>       
>>>> I believe I remember that we agreed at one point way back that it 
>>>> would be appropriate to move the modules (still in active 
>>>> maintenance) into the main modules tree.
>>>>     
>>>>         
>>> Well, may be not only in the active maintenance but also ready for 
>>> active usage with the rest of SER mainline core & modules.
>>>
>>>
>>>   
>>>       
>>>> I would like to do the rest now, as well as change the granular 
>>>> write permissions in experimental to specific modules dirs.
>>>>     
>>>>         
>>>  [...]
>>>   
>>>       
>>>> This means that oracle module should be transferred and possibly 
>>>> usrloc-cl before experimental is deleted.
>>>>     
>>>>         
>>> Hmm. I may be missed some points earlier, but I considered 
>>> experimental tree to be a long term project. Why do you want to delete 
>>> it now? What if somebody else would like to contribute another 
>>> experimental module later? Shouldn't the modules (even moved to 
>>> mainline) be preserved in experimental branches up to the point where 
>>> they have been moved?
>>>
>>> FYI, oracle module is definitely not ready for Ottendorf release yet. 
>>> You might notice that it is only available for rel_0_9_0 branch. This 
>>> is because I have not even tried to compile it with CVS HEAD so far.
>>>
>>> As I mentioned in another message, I'll update the module for 
>>> Ottendorf shortly but I can't guarantee correct functionality until 
>>> more users try it because we're not going to use rel_0_9_0 in short 
>>> term, (and even if we moved to the new release immediately, still we 
>>> use quite limited subset of SER features & DB schema).
>>>
>>>   
>>>       
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Serdev mailing list
>> Serdev at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serdev
>>   
>>     
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.iptel.org/pipermail/serdev/attachments/20061205/7f8c26da/attachment.htm