[Tts-project] Versioning of mbrola-LANG packages (Was: Maintaining mbrola-LANG packages in tts-team team?)

[Andreas Tille]

Hi Samuel,

Am Wed, Feb 25, 2026 at 10:24:02AM +0100 schrieb Samuel Thibault:
> 
> Some voices may have not been updated indeed.

Do you think it rather makes sense to run the script and check for real
changes inside the data?

> The tcts website has been
> shut down for several years now, the github repository should be used
> now.

Sure.  That's why we should use this as Homepage in d/control and
Source in d/copyright.
 
> > Now comes my question:  The UDD query
> > 
> >   udd=> select distinct source, version from sources where source like 'mbrola-%' and release = 'sid' order by version;
> > 
> > uncovers quite a number of different versioning schemes.  The
> > get-orig-source script intended to keep the leading version number as
> > long as it is no date string.  I wonder where such versions might
> > come from.
> 
> They normally come from the respective README files.

OK, I might check this later.

> Either an explicit
> version, or an explicit date, used as such, or nothing explicit,
> in which case I used 0.0.date to avoid conflicting with any scheme
> that would be introduced later, where the date is the date that was
> originally recorded in the upstream zip file (lost while migrating to
> github, but still available in the earliest debian uploads).

... which is the recommended packaging style and which I absolutely
agree.
 
> > If there is no official version numbering I think it makes sense to
> > settle with either
> > 
> >    20200331.fe05a0c-1
> > 
> > or even only
> > 
> >    20200331-1
> > 
> > (since chances for multiple commits on one day are pretty low) for *all*
> > mbrola-LANG packages.  This version would be informative for our users
> > and IMHO reflects the reality better than the current version numbers we
> > have.  What do you think?  If you agree, what version scheme (including
> > commit ID or without it) would you prefer?
> 
> I'm not sure. While the upstream voices packages did mostly have version
> numbers, AFAIK they have never been updated since then, so most probably
> never will (the people there probably even don't have the source
> recordings any more). The https://github.com/numediart/MBROLA-voices/
> repository was built to make sure that the mbrola voices are not lost,
> and it has indeed not seen any update since then.
> 
> But taking 20200331 as date would provide much less information, it
> could even lead users into thinking that the voices themselves have seen
> an update, which is not true ; while the current version numbers are at
> least related to original upstream information.

OK, fine for me.  That's why I was asking.
 
> Also, changing the numbering scheme would mean re-uploading the .orig
> files, which are quite large, for questionable value.

Yes, *if* we decide that creating new upstream tarball makes sense (and
that's why I'm asking first) we need to re-upload the .orig.tar.xz files
(using xz compression might help a bit).  Given that the current README
files inside the source packages are containing broken links I'm tempted
to do so - but not really keen on it if you think that's acceptable.  I
simply think that discussing this first if we decide to upload some
"once-in-a-decade-upload" packages should be done right to make it safe
for the next decade. ;-)

If I understand you correctly you prefer to not change the leading
version number, right?  That's fine for me and I'll rather check whether
the data file and/or some version string in README might have changed.

Kind regards
    Andreas.

-- 
https://fam-tille.de