Backporting to 4.1.80

Hi there,

I have tried to backport some patches that were going to be useful while I 
found out that I had no karma to commit on tags.

I am placing patches here, with the explanation:

backport.diff:

This patch corresponds to revisions 891277, 891278, 891359 and 891377 in 
trunk.

The aiming of this is to behave more perfectly by don't accepting the 
open/save dialog when you are going to save. Instead you click one time, and 
you can still modify the filename to add for instance a "_2" and then accept 
the dialog.

It also fixes other internal problems for stability shake.

backport2.diff:

This was already backported, but made KMail do some strangenesses on its 
previous version. I believe all problems are fixed now, and I couldn't find any 
regressions. For this reason I would like to see this patch readded.

Basically, it allows users that have the need of special characters being able 
to write them when the autocompletion box is shown.

This means that I, as a spanish user can't write "música" when writing "m", 
because the autocompletion was popped up and when writing it would look like 

Re: Backporting to 4.1.80

On Tuesday 02 December 2008 02:08:20 Rafael Fernández López wrote:
> I have tried to backport some patches that were going to be useful while I
> found out that I had no karma to commit on tags.

Why would you want to backport patches to a tag? It's either branch/ (4.1.x) 
or trunk (next release of that is beta2). Tags are not supposed to change 
after a release, which for 4.1.80 a.k.a beta1 has happened :).
--

-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 

Re: Backporting to 4.1.80

Hi,

> Why would you want to backport patches to a tag? It's either branch/
> (4.1.x) or trunk (next release of that is beta2). Tags are not supposed to
> change after a release, which for 4.1.80 a.k.a beta1 has happened :).

Because I want it to be on the 4.2 branch that will be created from the 4.1.80 
tag. No ?

I thought that was the way: we tag from trunk, we branch from the tag that 
were the betas.

Regards,
Rafael Fernández López.

Re: Backporting to 4.1.80

On 02.12.08 17:27:45, Rafael Fernández López wrote:
> Hi,
> 
> > Why would you want to backport patches to a tag? It's either branch/
> > (4.1.x) or trunk (next release of that is beta2). Tags are not supposed to
> > change after a release, which for 4.1.80 a.k.a beta1 has happened :).
> 
> Because I want it to be on the 4.2 branch that will be created from the 4.1.80 
> tag. No ?
> 
> I thought that was the way: we tag from trunk, we branch from the tag that 
> were the betas.

No, we tag from trunk for the betas, then we branch from trunk for 4.2.0
and tag 4.2.x (x>0) from the branch.

Andreas

--

-- 
Domestic happiness and faithful friends.

Re: Backporting to 4.1.80

On Tuesday 02 December 2008 17:27:45 Rafael Fernández López wrote:
> > Why would you want to backport patches to a tag? It's either branch/
> > (4.1.x) or trunk (next release of that is beta2). Tags are not supposed
> > to change after a release, which for 4.1.80 a.k.a beta1 has happened :).
>
> Because I want it to be on the 4.2 branch that will be created from the
> 4.1.80 tag. No ?
>
> I thought that was the way: we tag from trunk, we branch from the tag that
> were the betas.

No, the beta2 will be tagged from trunk (and the tag made compilable, nobody 
besides Dirk (I think) may commit there). Likewise, just before after the 
release, 4.2 will be branched off of trunk, subsequent releases (4.2.0, 4.2.1, 
...) will be tagged from that branch. Trunk is open for feature commits again 
then.

In short: committing to trunk is enough. :)
--

-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 

Re: Backporting to 4.1.80

Hi,

> In short: committing to trunk is enough. :)

Thanks Mr. Kügler !! :P

Regards,
Rafael Fernández López.

reopen trunk for KDE 4.3?

Hi,

I know we haven't implemented the whole "always summer in trunk" scheme, but I
wonder if we can go ahead and branch KDE 4.2 and reopen trunk. Just for kopete
alone, I have 3 patches, and a whole new protocol support plugin to integrate
and I'm sure other projects would benefit from this as well.

Thoughts?
--
Matt

Re: reopen trunk for KDE 4.3?

Op Wednesday 03 December 2008 23:17 schreef u:
> Hi,
> 
> I know we haven't implemented the whole "always summer in trunk" scheme, but I
> wonder if we can go ahead and branch KDE 4.2 and reopen trunk. Just for kopete
> alone, I have 3 patches, and a whole new protocol support plugin to integrate
> and I'm sure other projects would benefit from this as well.
> 
> Thoughts?

The problem is that we are only setup to handle two active branches for the translations. Currently 4.1 and
4.2, if we branch off 4.2, we need to setup a third branch for translations.

That said, I really think we should think about the 4.1.4 release, who are we actually going to do a pleasure
with that release? 4.2 is around the corner and is so much better than a possible 4.1.4. Are  trunk bugfixes
being backported to the branch currently and tested over there? I don't think a lot of developers are
testing that branch anymore. Our users are probably best served with a rocking 4.2.  I'm not going to fight
for this idea, it is just my opinion. Adventurous users can go to 4.2 beta1, stable users are already served
with 4.1.3.

So, just in my personal opinion, we can drop 4.1.4 and spent our energy to 4.2.0.

Toma

Re: reopen trunk for KDE 4.3?

Re: reopen trunk for KDE 4.3?

A Dijous 04 Desembre 2008, Aaron J. Seigo va escriure:
> On Wednesday 03 December 2008, Tom Albers wrote:
> > Op Wednesday 03 December 2008 23:17 schreef u:
> > > Hi,
> > >
> > > I know we haven't implemented the whole "always summer in trunk"
> > > scheme, but I wonder if we can go ahead and branch KDE 4.2 and reopen
> > > trunk. Just for kopete alone, I have 3 patches, and a whole new
> > > protocol support plugin to integrate and I'm sure other projects would
> > > benefit from this as well.
> > >
> > > Thoughts?
> >
> > The problem is that we are only setup to handle two active branches for
> > the translations. Currently 4.1 and 4.2, if we branch off 4.2, we need to
> > setup a third branch for translations.
>
> or would it make sense to ignore trunk until 4.2 is released for
> translations? so that the two branches being tracked would be 4.1 and the
> upcoming 4.2?
>
> for that matter, why are thranslations still being tracked for 4.1 when 4.2
> is now in string freeze? 

Because 4.1.4 is planned for tagging in 10th of december[1].

> should translators not be working on 4.2? (Honest 
> questions, i know next to nothing about the translation procedures)

Who says they are not working on trunk? For example, in 5 hours there have 
been 3 commits to the 4.1.x translation branch and 19 to trunk translation 
branch.

Albert

[1] http://techbase.kde.org/Schedules/KDE4/4.1_Release_Schedule

>
> > So, just in my personal opinion, we can drop 4.1.4 and spent our energy
> > to 4.2.0.
>
> +1 from me, for the imho good reasons you outline.