December 16, 2012
On Sun, Dec 16, 2012 at 10:05:58AM -0500, Andrei Alexandrescu wrote: [...]
> Just one tidbit of information: I talked to Walter and we want to build into the process the ability to modify any particular release. (One possibility is to do so as part of paid support for large corporate users.) That means there needs to be one branch per release.
[...]

This can be done easily if we maintain each release as a separate git branch. It does not even require modifying the current process, since as I understand it we're already proposing to branch when making a release. So in theory, if there's an urgent need, we can sidestep the "maintain at most two stable releases at a time" part of the process, checkout an older release, apply a bugfix, release another patch, etc..

If we name the git branches properly, there shouldn't be a problem with the proliferation of branches, as it will be obvious what each branch is for.


T

-- 
Try to keep an open mind, but not so open your brain falls out. -- theboz
December 16, 2012
On 12/16/12 10:15 AM, Joseph Rushton Wakeling wrote:
> On 12/16/2012 04:05 PM, Andrei Alexandrescu wrote:
>> Just one tidbit of information: I talked to Walter and we want to
>> build into the
>> process the ability to modify any particular release. (One possibility
>> is to do
>> so as part of paid support for large corporate users.) That means
>> there needs to
>> be one branch per release.
>
> Can you expand on the requirements/goals there a bit? Would be useful to
> have a good sense of what kind of modifications you have in mind.

Right now we're using a tagging system for releases, implying releases are just snapshots of a continuum. But what we need is e.g. to be able to patch 2.065 to fix a bug for a client who can't upgrade right now. That means one branch per release.

> I don't think anything in what I've proposed (elsewhere in this thread,
> I'm afraid I haven't written it up on the wiki yet...) is incompatible
> with the notion of one branch per release.

I agree. Just wanted to add this to the general discussion.


Andrei
December 16, 2012
On Sunday, 16 December 2012 at 15:05:58 UTC, Andrei Alexandrescu wrote:
> On 12/16/12 6:15 AM, Joseph Rushton Wakeling wrote:
>> On 12/15/2012 09:39 PM, deadalnix wrote:
>>> Can we drop the LTS name ? It reminds me of ubuntu, and I clearly hope
>>> that
>>> people promoting that idea don't plan to reproduce ubuntu's scheme :
>>> - it is not suitable for a programming language (as stated 3 time now,
>>> so just
>>> read before why I won't repeat it).
>>> - ubuntu is notoriously unstable.
>>
>> Call them "stable release cycles" if you like, which is what they are
>> intended to be.
>
> Just one tidbit of information: I talked to Walter and we want to build into the process the ability to modify any particular release. (One possibility is to do so as part of paid support for large corporate users.) That means there needs to be one branch per release.
>
> Andrei

I don't see why that is a requirement (having a branch per release).
We can still have a single stable branch with tags for releases and when Walter needs to provide special customizations he can always just branch off of the tagged release. This should be Walter's business and not part of the "official" community process.

in git terms, assuming we have a tagged release of 2.61
$ git checkout -b 2.61-partner 2.61
This branches off a new branch "2.61-partner" for the specific partner modification based off the contents of the "2.61" release.

Also, this kinda messes with the notion of integration. A single stable branch helps prevent "forgotten" bug-fixes. I.e a critical bug was fixed on release N, what will ensure it will be included in release N+1? If Release N+1 is on the same branch than the bug-fix is included by default and prevented the need to perform a manual operation (a merge) that could be forgotten.
December 16, 2012
On 12/16/12 11:56 AM, foobar wrote:
> I don't see why that is a requirement (having a branch per release).
> We can still have a single stable branch with tags for releases and when
> Walter needs to provide special customizations he can always just branch
> off of the tagged release.

To the extent possible, a good process should facilitate the desirable scenarios. Clearly this is possible, but that doesn't mean we shouldn't make it easy within reason.

> This should be Walter's business and not part
> of the "official" community process.

I think this is rather shortsighted. Corporate support by Walter is only one possible scenario, but there are many others.

> in git terms, assuming we have a tagged release of 2.61
> $ git checkout -b 2.61-partner 2.61
> This branches off a new branch "2.61-partner" for the specific partner
> modification based off the contents of the "2.61" release.
>
> Also, this kinda messes with the notion of integration. A single stable
> branch helps prevent "forgotten" bug-fixes. I.e a critical bug was fixed
> on release N, what will ensure it will be included in release N+1? If
> Release N+1 is on the same branch than the bug-fix is included by
> default and prevented the need to perform a manual operation (a merge)
> that could be forgotten.

The prevalent use of the feature would be that a bug in a future release is back-patched onto an older release.


Andrei
December 16, 2012
On Sunday, 16 December 2012 at 18:37:48 UTC, Andrei Alexandrescu wrote:

> The prevalent use of the feature would be that a bug in a future release is back-patched onto an older release.
>
>
> Andrei

The issue I see is we will have X releases. A bug is fixed, do we now apply it to all X or only Y releases?

I see it unreasonable to maintain every release. If we need to make a special "maintenance" release then we directly handle the issue being requested instead of providing every fix applicable.

Branches work when needing to handle continuous support, but tags are the perfect lite weight solution when you'll have to handle one off support. It can be done right now, but I don't know what version you'd release 2.57 + 1 as.
December 16, 2012
On Sunday, 16 December 2012 at 07:35:27 UTC, deadalnix wrote:
> I shouldn't be here explaining why this is wrong, you should be here explaining me why it can be applied anyway.


We are developing a process, specifying what it will look like.

If I'm building an airplane and say I think it should be kind of like a car, I'd expect your response would be.

You can't build an airplane with wheels, windshield, and a cabin for passengers. Cars have those and meant for driving on the ground with very sticked adherence to the laws of gravity.

What I expect you to say, we shouldn't be building an airplane, helicopters are much better at traveling and landing in tight places and that is what we need. Airplanes are good for when we need long distance.

Instead I hear, plans are good for long distance we shouldn't build them.

> Otherwise, anyone can come with any point, whatever how stupid it is, and each time we have to prove that person wrong. When you come with something, you have to explain why it make sens, not the other way around.

We have explained why it makes sense, the goals are already up on the wiki.

So you should review those goals and explain why the plan does not meet those, or correct the goals. You are doing neither.

> Back to the point, and it will be the last time. A distro is a set of programs. The goal of the distro is to provide a set of programs, as up to date as possible, that integrate nicely with each other, and with as few bugs as possible. Some of these goals are in conflict, so we see different pattern emerge, with different tradeoff, as ubuntu and debians's processes.

I said you don't have to repeat yourself.
December 16, 2012
On Sunday, 16 December 2012 at 16:23:57 UTC, Andrei Alexandrescu wrote:
>
> Right now we're using a tagging system for releases, implying releases are just snapshots of a continuum. But what we need is e.g. to be able to patch 2.065 to fix a bug for a client who can't upgrade right now. That means one branch per release.
>

I don't see a problem with retaining release branches for some time, and I think we were planning to do this as a means to support previous stable versions for some time period.

However, patching a downstream release while leaving upstream unpatched is not going to work well within the public branches, the flow must be from up stream to down stream, otherwise it'll be a confusing mess where older versions may have specific bug fixes but higher versions don't have the same bug fixes. In addition stable branches are forbidden from receiving new features because that will destabilize them and in addition upstream will be out of sync, causing a lot of confusion.

From what I can see, part of what you are proposing will have to be performed off-site as a private affair between the corporate user and the service provider. What we can certainly provide is a stable branch as-is when it was released, and that branch can certainly receive any patches that made their way that far down stream, however the patches will be bug fixes only.

--rt
December 16, 2012
On 2012-12-16 20:04, Jesse Phillips wrote:

> I see it unreasonable to maintain every release. If we need to make a
> special "maintenance" release then we directly handle the issue being
> requested instead of providing every fix applicable.

We could say that we support X number of older releases.

-- 
/Jacob Carlborg
December 16, 2012
On Sunday, 16 December 2012 at 18:37:48 UTC, Andrei Alexandrescu wrote:
>> This should be Walter's business and not part
>> of the "official" community process.
>
> I think this is rather shortsighted. Corporate support by Walter is only one possible scenario, but there are many others.
>

Indeed. To avoid the proliferation of branch that need support, it is better to slow down the number of new feature that each release provide and release them by packs.

So less branch need to be maintained.

> The prevalent use of the feature would be that a bug in a future release is back-patched onto an older release.
>

It is usually easier to go from the oldest to newest than the other way around.
December 16, 2012
On 12/16/2012 05:23 PM, Andrei Alexandrescu wrote:
> Right now we're using a tagging system for releases, implying releases are just
> snapshots of a continuum. But what we need is e.g. to be able to patch 2.065 to
> fix a bug for a client who can't upgrade right now. That means one branch per
> release.

Ahh, OK.  That makes complete sense, in fact I'd assumed it was a given that we'd wind up with one branch per release and release-specific bugfixes, which is why your remarks made me wonder if there was something more that needed explaining.