'Re: Merge trunk for 4.0.1'

[prev in list] [next in list] [prev in thread] [next in thread] 

List: kde-panel-devel
Subject: Re: Merge trunk for 4.0.1
From: "Riccardo Iaconelli" <riccardo () kde ! org>
Date: 2008-02-02 14:11:10
Message-ID: f57cdca40802020611i49cb0125q94c94e1be1625a4e () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

[Attachment #4 (text/plain)]

On Jan 30, 2008 4:33 PM, Riccardo Iaconelli <riccardo@kde.org> wrote:

> Il giorno 30/gen/08, alle ore 07:19, "Aaron J. Seigo" <aseigo@kde.org>
> ha scritto:
>
> > On Tuesday 29 January 2008, Riccardo Iaconelli wrote:
> >> What do you think of asking release-team for an exemption to merge
> >> trunk of plasma and libplasma (krunner too?) in the 4.0.1 branch?
> >
> > there have bee ntoo many i18n and binary incompatible changes, i
> > think. i've
> > been backporting a lot of changes i've been making (i have 3 more
> > sitting in
> > my tobackport directory atm), as others should be doing as well.
> >
> > i would like to see the taskbar changes backported .. which means
> > BoxLayout
> > changes and taskbar.
> >
> > we can certainly do backports on such a case-by-case basis. and 4.1
> > will be
> > out in july, and we can do more frequent releases ourselves as well,
> > so i
> > don't think it's a big issue.
> >
> > besides the taskbar improvements, anyone have any other suggested
> > backports?
>
> I'd say taskbar (including the show only current desktop thing),
> toolbox, and the ability to resize the panel (which is currently being
> worked on by me). Anything else?
>
> Ciao,
> -Riccardo
>

Being 4.0.1 released in a week, should we proceed with this?

-Riccardo
-- 
GPG key:
3D0F6376
When encrypting, please encrypt also for this subkey:
9EBD7FE1
-----
Pace Peace Paix Paz Frieden Pax Pokój Friður Fred Béke 和平
Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch
Shanti Vrede Baris Rój Mír Taika Rongo Sulh Mir Py'guapy 평화

[Attachment #5 (text/html)]

On Jan 30, 2008 4:33 PM, Riccardo Iaconelli &lt;<a \
href="mailto:riccardo@kde.org">riccardo@kde.org</a>&gt; wrote: <div \
class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid \
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Il giorno \
30/gen/08, alle ore 07:19, &quot;Aaron J. Seigo&quot; &lt;<a \
href="mailto:aseigo@kde.org">aseigo@kde.org</a>&gt; ha scritto: <div \
class="Ih2E3d"> &gt; On Tuesday 29 January 2008, Riccardo Iaconelli wrote: \
&gt;&gt; What do you think of asking release-team for an exemption to \
merge &gt;&gt; trunk of plasma and libplasma (krunner too?) in the 4.0.1 \
branch? &gt; &gt; there have bee ntoo many i18n and binary incompatible \
changes, i &gt; think. i&#39;ve &gt; been backporting a lot of changes \
i&#39;ve been making (i have 3 more &gt; sitting in &gt; my tobackport \
directory atm), as others should be doing as well. &gt; &gt; i would like to \
see the taskbar changes backported .. which means &gt; BoxLayout &gt; changes \
and taskbar. &gt; &gt; we can certainly do backports on such a case-by-case \
basis. and 4.1 &gt; will be &gt; out in july, and we can do more frequent \
releases ourselves as well, &gt; so i &gt; don&#39;t think it&#39;s a big \
issue. &gt; &gt; besides the taskbar improvements, anyone have any other \
suggested &gt; backports? </div>I&#39;d say taskbar (including the show \
only current desktop thing), toolbox, and the ability to resize the panel (which \
is currently being worked on by me). Anything else? Ciao, -Riccardo </blockquote></div> Being 4.0.1 released in a \
week, should we proceed with this? -Riccardo -- GPG \
key: 3D0F6376 When encrypting, please encrypt also for this \
subkey: 9EBD7FE1 ----- Pace Peace Paix Paz Frieden Pax Pokój Friður Fred \
Béke 和平 Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch \
Shanti Vrede Baris Rój Mír Taika Rongo Sulh Mir Py&#39;guapy 평화

_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel

[prev in list] [next in list] [prev in thread] [next in thread] 