[pulseaudio-discuss] [PACKAGERS] Patches for 0.9.15

[Felipe Contreras]

On Wed, Jun 17, 2009 at 11:15 PM, Zygo
Blaxell<zblaxell at dactyl.hungrycats.org> wrote:
> 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.

Where does the Linux kernel uses "$version-stable", on Linus' tree
there's only one branch: master.

In linux there's a separate repository for each "stable" release:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.30.y.git

This scales pretty nicely because developers don't see any of the
"$version-stable" noise, and maintainers can focus only on the stable
version they care about. So, it doesn't matter if a "stable"
repository is way too old for anybody to care, it will still not
create noise for anybody else.

> 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.

Do you think it's difficult to decide where "stable" should point to?
0.9.15.1 or 0.2.1

"stable" should point to the recommended stable version to use.

If somebody wants to have "$version-stable" then I say it should be in
a separate repository.

-- 
Felipe Contreras