Re: RFC: Final update of DEP-14 on naming of git packaging branches
Hi,
For me, the one branch type of development is closer to my style. I'm
that type of guy who can be easily distracted by quite anything and
therefore can easily forget things. Luckily, in most cases I have
automatic alerts and habits preventing disasters to happen, but there
are cases when it's a bit harder to maintain.
In most of the cases (99.5%) I'm working on the next release of the
package. Either by fixing bugs, following recommendations (lintian,
PTS, etc) or incorporating newer versions from upstream.
ANd after I finish with it, I upload the next version to unstable. But
in some cases, when it better to validate my hypothesis first, I upload
it to experimental. It does not happen too often (1 or 2 times
annually) and therefore if I create a new branch for it, that would
make me harder to not make mistakes (forget about the branch entirely,
deploy it to unstable by accident or just forget to merge it at the
end.)
Of course, when I have to fix something in a more "prod" environment
while I'm targeting my uploads to experimental, I still can create
ephemeral branches, correctly targeting them to the right release and
do a small fix there (hopefully by cherry-picking the fix from the
latest, so that will not be a problem if I forgot to merge it back).
Another problem of mine with creating different branches (and therefore
I like to avoid them) is the Changelog file, which makes the cross-
merges a bit more complicated than what is healthy for me.
Of course my packages are small and the chance that a newer release
breaks something fundamental is subtle, so it is low risk to target
unstable mst of the time.
On Sun, 2020-08-30 at 21:33 +0200, Mathias Behrle wrote:
> * Simon McVittie: " Re: RFC: Final update of DEP-14 on naming of git
> packaging
> branches" (Sun, 30 Aug 2020 15:02:35 +0100):
>
> > On Sun, 30 Aug 2020 at 15:36:53 +0200, Raphael Hertzog wrote:
> > > If I know that the next upstream release
> > > breaks backwards compatitibly and that it will have to mature a
> > > long time
> > > in experimental until all other packages are ready, I might start
> > > to
> > > package it rigth now in debian/experimental and continue to use
> > > debian/latest for my unstable uploads.
> >
> > If that's your workflow (the same as src:dbus, where versions
> > 1.13.x
> > are a development branch not recommended for general use), then I
> > don't
> > think debian/latest is a good name for that branch, and I'd
> > recommend
> > using debian/unstable for your unstable uploads.
> >
> > Rationale: it seems very confusing if a branch with "latest" in its
> > name
> > does not contain the newest available version :-)
>
> +1
>
> Additionally I think explicit is usually better than implicit. When
> all other
> branches are named following their suites why should we diverge for
> this special
> case?
>
> > (debian/master didn't have that problem because it's named by
> > analogy
> > to the "master" branch used in upstream git repositories, which
> > doesn't
> > really have a fixed meaning anyway.)
>
> BTW the same applies for me to the (re-)naming of the 'default'
> branch
> (currently master). If it is the default branch the most plausible
> name is just
> 'default'.
>
>
Reply to: