[Serdev] Re: SER experimental

Tue Dec 5 10:28:29 UTC 2006

Hi Greger,

Greger V. Teigre wrote:
> Experimental was an attempt at allowing new modules a path into the
> main modules directory.
> However, there have been some issues:
> - experimental is outside the tree and has been missed by many people
> - it is more difficult to align with the releases the modules belong to
> - it means that we must have a separate process and management
>
> 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").

* 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;
  - when self building, people will most certainly build both groups: 1.
"Why not?" 2. "I'm not really sure what I need."

* (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;
  - I don't imagine anyone trying '$ make include_modules=group-others'
or '... =group-experimental', but rather specify the exact set of
modules one needs.

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])

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
>   

-- 
Bogdan Pintea

iptego GmbH  -  VoIP Security
http://www.iptego.de