Hi Rene, > What should debian/latest be? The latest upstream (pre-)release? Aka what is > in experimental? Or not even there, > just preparing stuff for experimental?
This is a good question, as it goes to the core of why DEP-14 recommends debian/latest first, respectively in the debian/unstable and debian/experimental branches second (or at least I am think this is why, I didn't write DEP-14). In every git repository you need to have one default branch that signifies what regular or occasional contributors should target with their improvements. So from your three categories above, I would say "preparing stuff for experimental" would be the best fit. Of course, some of your uploads might go into unstable, hence DEP-14 authors chose 'latest'. The branches are not to document what *is already* in Debian, tags serve that purpose. Think of it like this: If I want to contribute to Hunspell, one of your packages, by fixing #528601 and writing a man page for munch, I would clone your g...@salsa.debian.org:libreoffice-team/hunspell.git and as it defaults to branch 'master', I would make my commit on top of that, and either submit a merge request that suggest to merge the man page into the 'master' branch (as it is the current default branch), or I might send a patch via BTS, but that patch would apply cleanly only on the 'master' branch as it was based off it. 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. I would most likely also run 'git add remote ottok g...@github.com:ottok/hunspell.git', switch to upstream real 'master', git rebase on it and git push and submit the same man page upstream, as upstream Hunspell is hosted on GitHub. Eventually we all probably wish to have all generic improvements benefit everyone universally and be upstrean, not just in Debian. In this scenario it would slightly slow me down that I need to deal with two 'master' branches that have the same files but are actually not of the same history. I hope this helps to illustrate the purpose of 'latest', and also show a scenario where having it called 'debian/latest' helps collaboration. For the record, I am not asking you to change anything in Hunspell, I just tried to make a good story by using a concrete example. > 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. 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. I hope this helps to illustrate the workflows.
