I think I now have a better handle on how/why I disagree with the DEP-14
recommendation language.
On 8/30/20 8:36 AM, Raphael Hertzog wrote:
> On Sat, 29 Aug 2020, Richard Laager wrote:
>> That said, I do understand we give a lot of deference to developers'
>> workflows. So I have no objection to DEP-14 supporting this workflow
>> with debian/latest. But I would like to see it (debian/latest)
>> recharacterized as the alternate approach rather than the recommended
>> method.
>
> Your approach is perfectly valid but I don't really believe that it should
> be the recommended approach. It doesn't seem to match the most common
> workflow.
>
> Most package maintainers are not actively working on two different
> development branches, instead the single development branch keeps moving
> between:
> - ready for unstable/upload to unstable
> - work in progress on a new upstream release
> - possible upload to experimental to gather feedback (buildd, users)
> - back to ready for upload to unstable
So you are regularly using multiple releases (unstable and experimental)
where the DEP-14 language allows you to use either debian/latest or
debian/{unstable,experimental}, but you feel debian/latest makes the
most sense most of the time in that scenario.
I think I see your point. You don't always know a priori when you are
going to want to upload to experimental. (Where you do know that, it's
because you expect the experimental piece to live in parallel for a
while and you'll use a temporary debian/experimental branch.) So you
have one debian/latest branch that can upload to unstable or
experimental as needed.
You could use debian/experimental all the time and then merge down to
debian/unstable only when you're ready to upload and have chosen
unstable. But I suspect your objection would be: that's unnecessary
busywork. And I see that point. I would probably make the same
objection, which means I think I agree with the debian/latest concept in
your situation.
I'm not sure if most package maintainers are doing this or not. I've
always assumed that most people are targetting only unstable most of the
time and that use of experimental is relatively rare. I could easily be
wrong on that. But that is definitely _my_ practice:
My package branch typically moves between:
- ready for unstable/upload to unstable
- work in progress on a new upstream release
- back to ready for upload to unstable
That is, I'm generally always targetting unstable and _not_ regularly
using multiple releases, so the DEP-14 language "prohibits" me from
using debian/unstable. This is what feels backwards to me. If I'm always
targetting unstable, debian/latest (and previously debian/master) is
less clear than debian/unstable.
At a minimum, can we rework this in some way so the language does not
require me to be regularly using multiple releases to use
debian/unstable as a branch name?
Preferably, can we change this to convey the following (probably using
better language):
1. If you (have one line of package development and) regularly
alternate between uploading to unstable and experimental, use
debian/latest.
2. If you normally only upload to unstable, use debian/unstable.
3. If you will have a separate line of package development for upload
to experimental, name that debian/experimental. If that is
long-lived, the other branch should be debian/unstable.
#1 covers your use case. #1 is listed first per your view that this is
the common case. #2 covers my use case. #3 allows either a #1 or #2
style to add debian/experimental temporarily, while recommending the
debian/{unstable,experimental} pair if the experimental branch is
long-lived (because it's confusing for debian/latest to not be the
latest version).
--
Richard
Attachment:
signature.asc
Description: OpenPGP digital signature