[pulseaudio-discuss] [PACKAGERS] Patches for 0.9.15

[Zygo Blaxell]

On Wed, Jun 10, 2009 at 02:16:03AM +0300, Felipe Contreras wrote:
> What do you propose instead? Have a "$version-stable" branch for each
> and every release? That doesn't scale, the repository will be polluted
> with branches that nobody use any more.
> 
> And it is a good use of git, remember that a branch is just a pointer,
> and the pointer can jump from one commit to a complete unrelated one,
> there's nothing wrong with that.

In your private repo, no, there's nothing wrong with that.

On a shared repo that is also the upstream repo, it annoys people who do
fetches (yes, fetches, not pulls) of refs/heads/* from multiple remotes
to the same repo, then work offline to do the merging.  If *any* head
in the remote repo is rebased (and therefore requires a non-ff pull),
the entire fetch is considered to have "failed", even though some remote
heads have been updated in the local repo.  When this happens, I have
to do an ad-hoc fetch to a new remote, look at what happened to the
branch pointers, and decide whether I want to force update the branch
or drop the remote repo because its owner is clueless.

Compare this with my preferred work flow (which is that I set up a
cron job to fetch from the remote overnight, then forget it exists, and
merge branch heads at my leisure, while offline, with 'git merge'),
and you'll see that non-ff pulls are a lot more work.  ;-)

ff-only fetches are not the git default, but I prefer non-ff pulls to be
the exception, not the rule.  The exception is for cases like "-next" or
"for-upstream" branches that are routinely rebased and have no useful
history--and, incidentally, usually stored in separate repos from the
mainline upstream, so I can have different 'fetch' lines for them in
.git/config.

It's possible to make a variety of data-losing mistakes with non-ff
fetches (especially if your repo has multiple remotes), that cannot be
made with ff-only fetches.

ff-only also keeps upstream honest, which is important when there's a
completely untrusted network between you and upstream, and dishonest
people lurking on that network.  If I see a non-ff branch update from
a trusted upstream, that should tell me to start asking some serious
questions about what I've pulled.

> I thought of another use-case, I do have a "stable" branch in most of
> the projects I follow,

Do you have an example of such a project with a "stable" branch upstream?
I've followed a number of cvs, git and svn projects over the years,
and have yet to see anyone use a plain "stable" branch (as opposed to
one with an embedded version number).

> I still haven't heard an advantage of "$version-stable" over "stable".

As mentioned by others, "$version-stable" is required because old Pulse
versions will be in the field for years after release.  We can expect
patches to be added in parallel to *all* of the "$version-stable"
branches that anyone is still interested in for as long as they're
interested in them.  Patches might not be committed to the branches in
any particular order.  Patches might be committed to only a subset of
the stable branches.  If Lennart gets too busy, the branches may have
separate maintainers.

So the question is really:  why *also* have a "stable"?

What should "stable" point to?  What if release .17 is awesome, but .18
and .19 suck, nobody deploys them, and they are quickly abandoned by
users and developers alike?  Should "stable" then point to a very broken
.19, or to a snapshot of .20 with bugfixes, or should stable be rolled
back to .17?  What if only people using bluetooth think that .18 sucked,
and only people using jack think that .19 sucked?  Who will decide which
version gets marked "stable?"

The fact that the Linux kernel uses "$version-stable" but not "stable"
should tell us something.

The term "stable" is hardly descriptive of a branch that jumps arbitrarily
from one major release to another.  Implementations change, dependencies
get added, features get deprecated...nothing about that is "stable".
"$version-stable" makes sense, since it can reject patches that are not
bug- or build- fixes for a fixed set of features and runtime environments.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20090617/827eff69/attachment.pgp>