View mode: basic / threaded / horizontal-split · Log in · Help
December 16, 2012
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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
Re: Next focus: PROCESS
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.
6 7 8 9 10 11 12 13 14
Top | Discussion index | About this forum | D home