Hi,
Am 26.01.25 um 02:07 schrieb Otto Kekäläinen:
I would
also expect that if the man page for munch is *not* on the master
branch, then it means that nobody else has written it and solved the
bug yet.
And exactly that assumption is wrong. (And contradicts what you say later, like
in have a debian/experimental and merge it back late..)
Stuff which is in development upstream or in experimental exists, even if it is
not in master.
Sometimes it's the version where stuff happens - like in freeze time where all
stuff happens there since sid is (basically) frozen for anything not supposed
to be for the release.
That would confuse people and waste peoples time.
People look up debian/latest and see stuff not relevant for sid where they ae
working on/for. Especially on freezes where stuff still happens for
experimental.
Or even worse, as follows:
"Latest stuff"? That would in my case be a version which will only be released
in August and has not even have a pre-release yet. The alpha
will be in May only.
Personally if I have some features that are not ready to be uploaded
for a long time, I would maintain them in a 'feature branch'. In some
cases that feature branch might live as a MR that is open for a very
long time.
But then it's not "latest". I would call whet is in experimental for libreoffice
"latest". Especially next week when 25.2.0 will be released 25.2.0 is the "latest"
upstream final release, and 24.8.x is not :)
Or I might call it debian/experimental and upload to
experimental, but not merge to debian/latest until post early June in
the context of your question.
And if it never ends up in sid for a release?
In your workflow described above people will get confused why they get LO 25.2
instead of 24.8. That doesn't help for contributing to sids 24.8 package.
Regards,
Rene
