Developers of Sympa

["Stefan Hornburg (Racke)" <address@concealed>]

On 03/30/2017 11:27 AM, Marc Chantreux wrote:
> Hello Soji,
> 
> Thanks for sharing. We will talk about it at the very beginning of the
> hackathon. I think everyone already agreed on the your vision of the 6.2
> branch and i really would like to see you as the maintainer of it.
> 
> The think i want to discuss during the hackathon is the opportunity to 
> split sympa on multiple components. at least
> 
> * sympa-backend-*     the abstract classes for serialization
> * sympa-mlm           the mailing list manager
> * sympa-rest-server   the REST server over mlm
> * sympa-vue           the web UI over rest-server
> * sympa-tt            the web UI over mlm (if someone wants to maintain)
> 

Hello Marc,

an essential component would be

* sympa-schema          the data storage schema (DBIx::Class)

This sits beneath sympa-mlm and sympa-rest-server and holds all business
logic.

> and there would be a notion of dependency between some of them. sympa
> should become easiser to
> 
> * dive in
> * reason about
> * package and install

* test test test

> 
> we also should talk about release process (i really would like some
> people to merge branches on devel and make master to point on stable
> tags) and deprecation process (what, why and how to break retrocompat.,
> how to document it).
> 

For the anticipated limited amount of developers PRs to master work
much better (lesson learned in Dancer project).

This implies proper CI testing of course.

Regards
        Racke


>> If you don't mind, I will deal with these works including merger of
>> related pull requests.
> 
> i would really appreciate it. anyone against ?
> 
>> Periodic release
>> ----------------
> 
> from my point of view, i think we should steal from perl:
> 
> * features are documented and marked as experimental by default
> * even major versions are stable (with maintainance), minors are for bug
>   fixing
> * even major versions are for devel snapshots. minors are for new
>   features and patchlevel are for fixing.
> 
> so we can have a fast pace of release for people who can afford more
> maintainance for new features as well as respecting the slow pace of
> bigger sites (like big universities and such)
> 
>> Thus, if there are no objection, we must decide: When the next
>> version (6.2 and new major) will be released?
> 
> if noone objects, this decision belongs to you now.
> 
> regards
> 


-- 
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration.