The mailing list for listmasters using Sympa

[Marc Chantreux <address@concealed>]

hello,

> > https://github.com/orgs/sympa-community/teams/everyone/discussions/19
> Do you really think that kind of biased post is helpful for the future of 
> Sympa?

i do.

> And certainly Soji doesn't deserve to be blamed as project manager.
> He does a good job.

so you say.

some people just contacted me to make me realize that this discussion
(and so every other ones posted on @everyone) isn't even public.

don't you think those kind of problems and discussions should be public
so you can take decisions based on the community needs, not on some
broken visions of sympa as a simple "legacy perl project" we can hack
on?

there was a time when the sympa community included the developpers.

so this is a raw copy of the thread:

@dverdin Splitting branches?
dverdin
6 days ago

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
@dverdin
dverdin 1 hour ago Author

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
ldidry 1 hour ago

    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
xavierba 20 minutes ago

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...