Splitting branches?

[dverdin]

Dear all,

I discussed this by mail with Soji but I'd like to propose it here: Would it be possible to split sable and development branches?

Currently, Soji maintains Sympa almost single-handedly and the last thing we want is to see him being crushed by work.

But on the other hand, maintaining a Sympa with mixed refactoring, improvements and bug fixes makes it difficult for user to follow the releases, because sometimes, a bug arise.

If we had two different versions, 6.2 as stable and 6.4 or 6.3 or whatever as the next stable, it would allow to make deep changes in the development code without fearing to break running instances, and we could still fix bugs and security problems in the stable branch.

Soji made it clear that he could not maintain both branches so somebody else should maintain the stable branch. If no one more competent wants to, I volunteer to do it.

Also, I would support the idea of Soji being release manager for the development branch, the future stable version.

What do you think?

Cheers!
David

[racke]

I think the releases and beta releases are very well managed given that he is only person doing these. To make it easier for Soji and increase the quality of the release, we others should test more, review more, contribute more instead of complicating the workflow with extra branches. And I'm not aware of anyone planning or doing deep changes. So I don't think it is a good idea.

[ldidry]

TL;DR: I agree with @dverdin

Long answer:
Sympa is not a small software and can be very important for some structures (universities, for ex.), so the admins don’t update Sympo too often (and a lot of them don’t do as often as they should, cf. the admins recently asking for advices for migrating from a 6.1 😅 ). Having a stable branch that would only get bugfixes would make updating Sympa less scary for those admins.

Framalistes hosts more 40k lists with ±730k users and we send more than 250k mails per day. Therefore, we need stability: we can’t afford to risk to get new bugs introduced by a new feature when upgrading to a new version because the new version has a bugfix we need. So I patch my Sympa, but I don’t patch every bugfix (no time available for that).

I think that having two branches would be the right thing to do.

But instead of calling them stable and development, it would be better, IMHO, to call them long term support and cutting edge (or something similar).

[ikedas]

I don't know why David didn't quote my response. Here I do:

From: IKEDA Soji
To: David Verdin
Subject: Re: A proposal regarding Sympa
Date: Wed, 30 Sep 2020 10:41:42 +0900

Hi David,

On Tue, 29 Sep 2020 11:48:18 +0200
David Verdin <[email protected]> wrote:

<<snip>>

> My problem is that we have a lot of users and are using almost all Sympa 
> functionnalities (except custom conditions, I think, we always managed 
> to resolve our problems with Sympa basic conditions). Considering the 
> current rate of releases, I'm having a hard time planning the upgrades 
> because any new version introduces new changes which, in turn, can 
> introduce bugs or regressions. I understand these changes are necessary 
> to improve Sympa codebase and overall performance, however they make 
> upgrades a little hazardous. I'm probably not the only one thinking this.

Recent beta releases include several changes.  I believe that
people including you downloaded, installed and tested these releases
in these three months.  That's why the bug and regression have been
eliminated.  Thank you for helping Sympa by testing it!

IF you have never tested these at all or almost all, it is only
natural that they include obvious bugs and regressions.

Serious question: Have you installed recent betas (6.2.57b) and
checked it even once?


> I was wondering if you would consider keeping a stable branch of Sympa 
> and starting to introduce refactoring and changes in a development 
> branch? I think it would make upgrades less frightening. I also think 
> that it would make big changes possible in the code, as the time between 
> the start of development and beta relase would be longer. All in all, 
> such a change would improve the confidence in Sympa for administrators.

I have proposed release schedule in the public space always.
You might tell what you think over there.
E.g. https://github.com/orgs/sympa-community/teams/everyone

Btw I understand you mean we have to manage separate "stable" and
"development" branches.  As I wrote before, it's too heavy load for
me.  I cannot run the two projects at once.  It's IMPOSSIBLE for me.

On the contrary I'd like to ask: Why do you ask me not to work for
Sympa?  You may rather work for Sympa also by yourself.  If you want
the "stable" version of your own, you can easily do it: Fork
sympa-community/sympa to your namespace and maintain it by yourself.


> I would be glad to see you as release manager of the development branch, 
> of course, as you are the main Sympa developer.
> 
> Tanks for your waork and I'm looking forward to hear from you.

Thank you for proposal.  I appreciate you to continue helping the
community.  Thank you!


Regards,
-- Soji

[dverdin]

Hi everyone,

Indeed, @ikedas I did not quote you mainly because it was your thoughts, not mine, so I preferred you publish them instead of me.

I agree with @ldidry about the denomination. I talked about stable and development because it was how we called it during the CRU / RENATER era. But if you feel long term support / cutting edge suits better, I agree.

To @racke : It is not that weird to have two branches. Most projects have a stable release in which they only introduce bug fixes and an ongoing development barnch in which they can make deeper and non reversible changes. it does not change anything about workflow: you make quick bug fixes in the stable branch to keep the stable version afloat and you make planned, long term developments it the dev branch. It offers us the ability to break things temporarily in the development branch if needed.
About deep changes, I remember you wanted to introduce dancer and DBIx::Class. Did you give up about this?

In what I understand, until now :

• @racke disagrees,
• @ldidry agrees,
• @ikedas agrees as long as he does not have to maintain the stable branch. It is a good thing I proposed he stayed release manager of the development branch and I or somebody else became release manager of the stable one, then.

Any other advice?

[ldidry]

Any other advice?

We need to talk about the tagging of the LTS branch. I propose 6.2.60-p1, 6.2.60-p2, etc. (if the LTS is the 6.2.60, of course). The -p1, -p2, etc is for patch-level-1, patch-level-2, etc. We could use 6.2.60a, 6.2.60b but after 26 bugfixes releases, we would have a problem.

Of course, we could also switch to semantic versioning instead, but I remember that has already been discussed and was not accepted.

[xavierba]

I would prefer to use numbers for the LTS: 6.2.60.1, 6.2.60.2, etc... But I agree semantic versioning would be nice imho, including for the fast moving branch, eg 6.3.0, 6.4.0 rather than 6.2.60, 6.2.62, etc...

[racke]

So for starters (before implementing a branching scheme) I would like to clearly identify changes which alter the behaviour of Sympa, e.g. #1038.

I suggest that these will be communicated in a separate section of the release notes. Also input from everyone to these kind of changes would be appreciated 👋

[ikedas]

I don't agree to call the branch proposed by @dverdin as "stable". As far as I can understand, it would be better to be called "legacy" or "frozen". That's what @dverdin wishes: What he want is the software working just the same as 6.1, isn't it?

About versioning: @dverdin says there are "big changes" during 6.2. I don't think so. There are many bug fixes, clarification of features, removal of duplicate or conflicting behaviors. (At least by me) there are few that newly added.

After all, recent work is paying the price in the past: No suffice test suites; "Copy-and-paste" programing instead of refactoring.

• Test suite with enough coverage will solve most of problem causing regression. HOWEVER Nobody really tackles it.
• "Copy-and-paste" (or "cargo-cult") programming in the past encumbers maintainability. The half of "big changes" are rewriting of such code --- from my point of view.

I think semantic versioning (this is good idea by itself) or split branchs is "the rice cake in the picture" - the pie in the sky. Recently we are working to accomplish the ideal development I wrote in above. I think continuous release is better than spending time discussing about release date and version number of the next release.

[racke]

I agree with @ikedas about continuous releases. Those who are support special branches should feel free to help first with reviewing PRs and setup a better test infrastructure.

[racke]

About deep changes, I remember you wanted to introduce dancer and DBIx::Class. Did you give up about this?

No, but that's on the back burner for now. Currently working on a new Ansible role for Sympa, which I used for an upgrade and revamp of a Sympa installation at a German university. Hope to publish that before/shortly after the 6.2.60 release.

[dverdin]

Currently working on a new Ansible role for Sympa, which I used for an upgrade and revamp of a Sympa installation at a German university. Hope to publish that before/shortly after the 6.2.60 release.

Hey, that's cool!
Would it replace the current sympa-ansible repository?

[dverdin]

So for starters (before implementing a branching scheme) I would like to clearly identify changes which alter the behaviour of Sympa, e.g. #1038.

I suggest that these will be communicated in a separate section of the release notes. Also input from everyone to these kind of changes would be appreciated wave

I think that these are exactly the kind of things that should be done in a development branch only. When and admin has installed a Sympa, he does not want to change it. If a simple upgrade to a version of the same branch breaks your cutomizations, you'll stop trusting the software.

And I really don't think that a lot of administrators are reviewing PR. so when they discover a change, it is often a bit late.

[ikedas]

@dverdin, I repeat my statement, leave from this thread and continue working for Sympa:

You may rather work for Sympa also by yourself. If you want
the "stable" version of your own, you can easily do it: Fork
sympa-community/sympa to your namespace and maintain it by yourself.

[racke]

Currently working on a new Ansible role for Sympa, which I used for an upgrade and revamp of a Sympa installation at a German university. Hope to publish that before/shortly after the 6.2.60 release.

Hey, that's cool!
Would it replace the current sympa-ansible repository?

Yes, though it will only cover Sympa installation itself. So you would need roles for MTA, RDBMS and web server.
Succesfully used on the following platforms (in my test VM park):

• Arch Linux
• CentOS 7
• CentOS 8
• Debian 8 (Jessie)
• Debian 9 (Stretch)
• Debian 10 (Buster)
• Fedora 31
• openSUSE Leap 15
• Ubuntu 16 (Xenial)
• Ubuntu 18 (Bionic)
• Ubuntu 20 (Focal)
• Ubuntu 22 (Groovy)

[dverdin]

I don't agree to call the branch proposed by @dverdin as "stable". As far as I can understand, it would be better to be called "legacy" or "frozen". That's what @dverdin wishes: What he want is the software working just the same as 6.1, isn't it?
Yes ! Exactly!
More precisely: I want the software to work as it works now, because it works way better than te 6.1 did.
But I want the relases in 6.2 to work the same way: only bug fixes, no changes. Just stabilization.
As for the way the branch is named. I really don't have an opinion. The way you prefer.

About versioning: @dverdin says there are "big changes" during 6.2. I don't think so. There are many bug fixes, clarification of features, removal of duplicate or conflicting behaviors. (At least by me) there are few that newly added.
Yes, but some of these changes led to buggy relases. I don't blame anyone. It's just the kind of things that happen when facing a behemoth like the Sympa code.

After all, recent work is paying the price in the past: No suffice test suites; "Copy-and-paste" programing instead of refactoring.
Yes, certainly.
I may remind you that, despite this, Sympa was reknown for its stability and versability.
Listen, I'm all for refactoring and test suite (all the PR I tried to submit since two years always had unit tests, and I am the only developer to do it in Sympa) but I just want to move risky changes to a dedicated area.

Test suite with enough coverage will solve most of problem causing regression. HOWEVER Nobody really tackles it.
"Copy-and-paste" (or "cargo-cult") programming in the past encumbers maintainability. The half of "big changes" are rewriting of such code --- from my point of view.

And you're perfectly right to do it!
But I'd like to separate concerns.

I think semantic versioning (this is good idea by itself) or split branchs is "the rice cake in the picture" - the pie in the sky. Recently we are working to accomplish the ideal development I wrote in above. I think continuous release is better than spending time discussing about release date and version number of the next release.

And I don't care how releases should be numbered.
I just want two spaces: one for stable / frozen/ patch only; one for the great wrok you're doing and for which I'd like to contribute.

[racke]

So for starters (before implementing a branching scheme) I would like to clearly identify changes which alter the behaviour of Sympa, e.g. #1038.

I suggest that these will be communicated in a separate section of the release notes. Also input from everyone to these kind of changes would be appreciated wave

I think that these are exactly the kind of things that should be done in a development branch only. When and admin has installed a Sympa, he does not want to change it. If a simple upgrade to a version of the same branch breaks your cutomizations, you'll stop trusting the software.

And I really don't think that a lot of administrators are reviewing PR. so when they discover a change, it is often a bit late.

But they are supposed to read the release notes. And I said we should do a better job on the PR reviews (with the exception of @ikedas who does that properly).

[dverdin]

@dverdin, I repeat my statement, leave from this thread and continue working for Sympa:

You may rather work for Sympa also by yourself. If you want
the "stable" version of your own, you can easily do it: Fork
sympa-community/sympa to your namespace and maintain it by yourself.

And that's exactly what I want to do! We all agree. Cool!
But I'd like to do it within the "sympa-community". Not all by myself, and in accordance to you.

[dverdin]

But they are supposed to read the release notes. And I said we should do a better job on the PR reviews (with the exception of @ikedas who does that properly).

Oh, yes, sorry: "we" = the developers.
That's an excellent point indeed. We don't spend enough time reviewing.

[dverdin]

Currently working on a new Ansible role for Sympa, which I used for an upgrade and revamp of a Sympa installation at a German university. Hope to publish that before/shortly after the 6.2.60 release.

Hey, that's cool!
Would it replace the current sympa-ansible repository?

Yes, though it will only cover Sympa installation itself. So you would need roles for MTA, RDBMS and web server.
Succesfully used on the following platforms (in my test VM park):

Arch Linux
CentOS 7
CentOS 8
Debian 8 (Jessie)
Debian 9 (Stretch)
Debian 10 (Buster)
Fedora 31
openSUSE Leap 15
Ubuntu 16 (Xenial)
Ubuntu 18 (Bionic)
Ubuntu 20 (Focal)
Ubuntu 22 (Groovy)

Good ! that will certainly be a good improvement of what we do now. Better maintainability by using galaxy roles.

[xavierba]

@ikedas: Why would such an LTS, short of a better name, has to be in a fork in a different namespace while it could happen in the sympa-community namespace ?

@racke: I'm reading the release notes and I usually know about the changes beforehand, but I've never seen any release notes mentioning regressions. I do also test the betas and I'm even providing Fedora/RHEL/CentOS RPMs for the betas to ease the life of anyone wanting to help test them. However, there's no way for me to test every special cases on my test rigs that I or other will encounter on a real life production server. And thus I and others did hit regressions, and reported them, but after suffering from them in production.
It is not doing anyone any good if one has to choose between the (security) fixes in the latest and greatest release and staying on the last known good release in fear of possible unforeseen regressions.

@racke: is the ansible role building from source or using the RPMs ? Also Fedora 31 is EOL.

[racke]

@ikedas: Why would such an LTS, short of a better name, has to be in a fork in a different namespace while it could happen in the sympa-community namespace ?

@racke: I'm reading the release notes and I usually know about the changes beforehand, but I've never seen any release notes mentioning regressions. I do also test the betas and I'm even providing Fedora/RHEL/CentOS RPMs for the betas to ease the life of anyone wanting to help test them. However, there's no way for me to test every special cases on my test rigs that I or other will encounter on a real life production server. And thus I and others did hit regressions, and reported them, but after suffering from them in production.
It is not doing anyone any good if one has to choose between the (security) fixes in the latest and greatest release and staying on the last known good release in fear of possible unforeseen regressions.

I think we need to help @ikedas when he is writing the release announcements. Usually I can determine which changes can bite users. This should be clearly marked.

@racke: is the ansible role building from source or using the RPMs ? Also Fedora 31 is EOL.

From source, git repo and local folder (last one mostly for development). Package is in the works. What do I need to install the beta repos? I tried Fedora 32 but it coughed violently when it tried to install Perl modules with cpanm.

[xavierba]

@racke: is the ansible role building from source or using the RPMs ? Also Fedora 31 is EOL.

From source, git repo and local folder (last one mostly for development). Package is in the works. What do I need to install the beta repos? I tried Fedora 32 but it coughed violently when it tried to install Perl modules with cpanm.

The regular releases are in Fedora and EPEL, respectively.
Not EPEL 8 though (still working on the spawn-fcgi/systemd+multiwatch change), but packages built from the same RPM specfile are at:

• https://copr.fedorainfracloud.org/coprs/xavierb/sympa/

The beta, built from the same specfile too but with the beta tarballs are at:

• https://copr.fedorainfracloud.org/coprs/xavierb/sympa-beta/

[xavierba]

oh, and forgot to mention it, no need for CPAN, all perl modules are available as rpms.

[racke]

Even the optional ones?

For source installations it is needed to install with CPAN as it is hard to maintain list of module - package mapping. And a new Sympa version might require another module.

[xavierba]

Even the optional ones. If any is missing, please let me know, I'll try and get them packaged and added to Fedora/EPEL.