El Dimecres, 17 de juliol de 2013, a les 19:34:17, Scott Kitterman va
escriure:
> On Thursday, July 18, 2013 01:19:12 AM Albert Astals Cid wrote:
> > El Dimecres, 17 de juliol de 2013, a les 07:37:16, Luca Beltrame va
>
> escriure:
> > > Albert Astals Cid wrote:
> > > > Just as a reminder, we hav
On Thursday, July 18, 2013 01:19:12 AM Albert Astals Cid wrote:
> El Dimecres, 17 de juliol de 2013, a les 07:37:16, Luca Beltrame va
escriure:
> > Albert Astals Cid wrote:
> > > Just as a reminder, we have the Release Team BOF tomorrow July 17 at
> > > 10:15
> > > at Room A2
> >
> > Would it be
El Dimecres, 17 de juliol de 2013, a les 07:37:16, Luca Beltrame va escriure:
> Albert Astals Cid wrote:
> > Just as a reminder, we have the Release Team BOF tomorrow July 17 at 10:15
> > at Room A2
>
> Would it be possible to post the outcome of the discussion here? It would be
> very helpful (as
Albert Astals Cid wrote:
> Just as a reminder, we have the Release Team BOF tomorrow July 17 at 10:15
> at Room A2
Would it be possible to post the outcome of the discussion here? It would be
very helpful (as unfortunately I'm not in Bilbao).
--
Luca Beltrame - KDE Forums team
KDE Science supp
I wish I was there.
Scott K
Albert Astals Cid wrote:
>Just as a reminder, we have the Release Team BOF tomorrow July 17 at
>10:15 at
>Room A2
>
>Cheers,
> Albert
>
>El Dimarts, 16 de juliol de 2013, a les 14:38:47, Scott Kitterman va
>escriure:
>> On Monday, July 15, 2013 09:00:27 PM Luca Bel
Just as a reminder, we have the Release Team BOF tomorrow July 17 at 10:15 at
Room A2
Cheers,
Albert
El Dimarts, 16 de juliol de 2013, a les 14:38:47, Scott Kitterman va escriure:
> On Monday, July 15, 2013 09:00:27 PM Luca Beltrame wrote:
> > Àlex Fiestas wrote:
> > > Now that kde-workspace a
On Monday, July 15, 2013 09:00:27 PM Luca Beltrame wrote:
> Àlex Fiestas wrote:
> > Now that kde-workspace and kdelibs are going to be frozen (which in theory
> > means less work for everybody) I'd like to propose a new release schedule
> > to be applied starting with 4.12.
>
> Replying to the mes
On 07/15/2013 05:54 AM, Aaron J. Seigo wrote:
We are experimenting with the idea of a “long term release” version with kde-
workspace. If 4.11 gets widely used, deployed and stabalized (as we hope it
will) then blessing specific releases for extended #s of releases may be a good
approach.
Right
Àlex Fiestas wrote:
> Now that kde-workspace and kdelibs are going to be frozen (which in theory
> means less work for everybody) I'd like to propose a new release schedule
> to be applied starting with 4.12.
Replying to the message starting the thread because I forgot something
important at lea
Aaron J. Seigo wrote:
> translations .. this will require some time spent with the translation
> maintainers to figure out what will work well for those efforts.
The risk here is that when branches which have been in preparation for a long
time are merged, or simply many branches are merged, the a
On Monday, July 15, 2013 11:51:38 Scott Kitterman wrote:
> 30 of the 42 weeks are spent in some kind of freeze state. Without process
> changes to get from "feature complete" to "released" there's no way to get
> to a three month cycle.
those of us in favour of a shorter development cycle are als
On Monday, July 15, 2013 14:16:01 Luca Beltrame wrote:
> Aaron J. Seigo wrote:
> > "we should try to recruit more people from the user community of
> > downstream distributions who have the skills necessary to merge patches
> > and test. some distributions do this already.”
>
> The reason I menti
Aaron J. Seigo wrote:
> "we should try to recruit more people from the user community of
> downstream distributions who have the skills necessary to merge patches
> and test. some distributions do this already.”
The reason I mentioned "issues" with this approach originally originate from
(perha
On Monday, July 15, 2013 02:48:01 PM Albert Astals Cid wrote:
> El Diumenge, 14 de juliol de 2013, a les 04:19:52, Inge Wallin va escriure:
> > I think keeping 6 months is a good
> > figure to ensure both reasonable turn-around *and* actual bugfixes of
> > versions being used in the real world.
>
El Dilluns, 15 de juliol de 2013, a les 09:58:01, Cristian Tibirna va
escriure:
> Although Inge supposedly bases his analysis on extrapolation and (very) wise
> guessing, and despite the obvious lack of hard data (1), I will put my
> support behind Inge's view.
>
> (1) (sadly including here our b
Although Inge supposedly bases his analysis on extrapolation and (very) wise
guessing, and despite the obvious lack of hard data (1), I will put my support
behind Inge's view.
(1) (sadly including here our blatant dissing of, e.g., 527 severe bug reports
on nepomuk... that ask for stability an
El Diumenge, 14 de juliol de 2013, a les 04:19:52, Inge Wallin va escriure:
> I think keeping 6 months is a good
> figure to ensure both reasonable turn-around *and* actual bugfixes of
> versions being used in the real world.
It may be a reasonable turn-around for some users, but it is also not
d
On Sunday, July 14, 2013 04:19:52 Inge Wallin wrote:
> Without having any scientific proof, I believe that there are 2 main
> categories of users:
> 1. Those generally satisfied who want stability
> 2. Those who long for new updates all the time.
Regardless of whether someone is a Category 1 or
On Saturday, July 13, 2013 09:50:21 Luca Beltrame wrote:
> Aaron J. Seigo wrote:
> > 1. packagers seem to feel that if upstream doesn’t do the actual commit to
> > the upstream repository, then upstream is not maintaining their software
>
> To be honest, that's not always true.
Good :)
> At leas
On 2013-07-14, Inge Wallin wrote:
> Here are some assumptions. Correct me if they are wrong:
> - KDE developers support the last relesed and *maybe* the second to last
> release with bugfixes.
> - Distributions have a release cycle of 6 months or longer.
> - Distributions pick their contents 2
On Saturday, July 13, 2013 14:05:13 Jaime Torres Amate wrote:
> How would the release schedule (
> http://techbase.kde.org/Schedules/KDE4/4.11_Release_Schedule) be in a 3 or
> 4 mounths release? 1 month for new features, 2 or 3 for bugfixing,
> translating, language bindings? Or like linux kernel,
On Sunday, July 14, 2013 15:23:46 David Faure wrote:
> On Friday 12 July 2013 17:07:13 Aaron J. Seigo wrote:
> > we ought to think of ways to make master more stable.
>
> Exactly. And porting master to qt5/frameworks definitely doesn't make it
> more stable, so let's not do that.
>
> (Yes, I'm m
On 07/13/2013 10:19 PM, Inge Wallin wrote:
Without having any scientific proof, I believe that there are 2 main categories
of users:
1. Those generally satisfied who want stability
2. Those who long for new updates all the time.
My feeling is that the first category is the silent majority an
On Monday, July 08, 2013 15:04:40 Àlex Fiestas wrote:
> Now that kde-workspace and kdelibs are going to be frozen (which in theory
> means less work for everybody) I'd like to propose a new release schedule to
> be applied starting with 4.12.
>
> Basically the idea is to cut testing time and compe
On Friday 12 July 2013 17:07:13 Aaron J. Seigo wrote:
> we ought to think of ways to make master more stable.
Exactly. And porting master to qt5/frameworks definitely doesn't make it more
stable, so let's not do that.
(Yes, I'm mixing both topics, because I see contradictory arguments from the
How would the release schedule (
http://techbase.kde.org/Schedules/KDE4/4.11_Release_Schedule) be in a 3 or 4
mounths release? 1 month for new features, 2 or 3 for bugfixing, translating,
language bindings? Or like linux kernel, allways develop new features in other
branches, and 1 month to me
Aaron J. Seigo wrote:
> 1. packagers seem to feel that if upstream doesn’t do the actual commit to
> the upstream repository, then upstream is not maintaining their software
To be honest, that's not always true. At least the major distributions and a
few of the minors have packagers that hold KD
On Friday, July 12, 2013 05:27:53 PM Aaron J. Seigo wrote:
> On Wednesday, July 10, 2013 14:23:24 Scott Kitterman wrote:
> > I've mentioned before in this thread, we're going to look into
> > providing tip of the stable branch packages that people can test so that
> > there is more testing before t
> On Wednesday, July 10, 2013 07:44:35 PM Martin Graesslin wrote:
> > We need to get away from "it's not stable enough" to "it's stable". The
> > only way is to increase the testing and make everything we can do to have
> > an awesome and rocking .0. I think Alex approach is the right one.
> > Redu
On Wednesday, July 10, 2013 12:28:10 Scott Kitterman wrote:
> This isn't the first time upstream KDE developers have suggested offloading
> the boring upstream maintenance work to distributions.
do you think it’s because it is boring? no. it’s because if when this work is
put on the shoulders of
On Wednesday, July 10, 2013 17:16:55 Sune Vuorela wrote:
> On 2013-07-10, Àlex Fiestas wrote:
> > I can't fight with distros, and I don't want to fight with them. If
> > distros
> > need .5 .6 and .200 so be it, just they will have to do them themselves
> > (and I hope we can make the process smoo
On Friday, July 12, 2013 10:12:41 Andras Mantia wrote:
> On Thursday, July 11, 2013 06:53:51 PM andrea diamantini wrote:
> > What about a single official development branch?
> > Just use two branches:
> > - master branch (stable)
> > - kdevel branch (devel)
>
> The natural question to come is: why
On Thursday, July 11, 2013 01:06:59 PM Sebastian Kügler wrote:
> On Tuesday, July 09, 2013 12:53:50 Philip Muskovac wrote:
> > On Monday 08 July 2013 18:59:12 Michael Pyne wrote:
> > > On Mon, July 8, 2013 17:45:10 Philip Muskovac wrote:
> > > > What would at least make my life easier here would be
Àlex Fiestas wrote:
> already out there (this already happened), what is happening here is that
> a HUGE release with a LOT of changes won't even get to the users of that
> distribution at least for another distribution cycle. This usually happens
Don't forget that at least the bigger distros off
henry miller wrote:
> latest, but those will never get beyond a .3 release. Distributions that
> want more stability can work together to submit patches to the long term
Bear in mind that not all distros have packagers with coding skills. Also,
maintenance of patches downstream can be problemat
On Tuesday, July 09, 2013 12:53:50 Philip Muskovac wrote:
> On Monday 08 July 2013 18:59:12 Michael Pyne wrote:
> > On Mon, July 8, 2013 17:45:10 Philip Muskovac wrote:
> > > What would at least make my life easier here would be a way to easily
> > > get a
> > > list of all patches that were applie
On Thursday, July 11, 2013 06:53:51 PM andrea diamantini wrote:
> What about a single official development branch?
> Just use two branches:
> - master branch (stable)
> - kdevel branch (devel)
The natural question to come is: why isn't master the devel branch? :)
Ok, let me reformulate again: did
On Thursday 11 July 2013, andrea diamantini wrote:
> What about a single official development branch?
> Just use two branches:
> - master branch (stable)
> - kdevel branch (devel)
> You develop wherever you like and push things on "kdevel" branch when
> ready. If you like the "one branch approach",
"Àlex Fiestas" wrote:
>On Wednesday 10 July 2013 13:22:20 Sune Vuorela wrote:
>> On 2013-07-09, Sune Vuorela wrote:
>> > So. first one.
>>
>> Second one
>>
>> Release frequency.
>>
>> We have a giant quality problem. Distros won't ship a .0 release to
>real
>> users (as opposed to testers/po
What about a single official development branch?
Just use two branches:
- master branch (stable)
- kdevel branch (devel)
You develop wherever you like and push things on "kdevel" branch when
ready. If you like the "one branch approach", you devel things directly in
kdevel branch.
People knows there
Le mercredi 10 juillet 2013 17:55:42 Àlex Fiestas a écrit :
> On Tuesday 09 July 2013 16:12:35 Andras Mantia wrote:
> > Two point I want to mention:
> > 1) working in a branch for kdepim is quite painful, as you need actually
> > work on branches of 3 (or sometimes 4) modules: kdepimlibs,
> > kdepi
On Wednesday, July 10, 2013 07:44:35 PM Martin Graesslin wrote:
> On Wednesday 10 July 2013 17:13:11 Sune Vuorela wrote:
> > On 2013-07-10, Aaron J. Seigo wrote:
> > >=3D=3D On scheduling mainenance releases
> > >
> > > in a longer 4 month cycle, i=E2=80=99d cut that to 8 weeks and keep jus=
> > >
On Wednesday 10 July 2013 17:13:11 Sune Vuorela wrote:
> On 2013-07-10, Aaron J. Seigo wrote:
> >=3D=3D On scheduling mainenance releases
> >
> > in a longer 4 month cycle, i=E2=80=99d cut that to 8 weeks and keep jus=
> > t the one=20
> > update.
> >
> > this would ease the burdon on our releas
On Wednesday 10 of July 2013 19:17:37 Luigi Toscano wrote:
> The more you go down in the stack, the more you need stability, and no, it's
> not true that with short release time the features will be smaller with
> less bugs, because a feature could have been in development for a long
> time, so it'
On 2013-07-10, Àlex Fiestas wrote:
> I can't fight with distros, and I don't want to fight with them. If distros
> need .5 .6 and .200 so be it, just they will have to do them themselves (and
> I
> hope we can make the process smooth so they can actually do it).
>
> As has been said in this thr
On Wednesday 10 of July 2013 17:43:38 Àlex Fiestas wrote:
> On Tuesday 09 July 2013 21:57:51 Alexander Neundorf wrote:
> > On Tuesday 09 July 2013, Sven Brauch wrote:
> > > I think Nuno's point is very interesting and worth thinking about. To
> > > stick with the firefox example, since they started
A Quarta, 10 de Julho de 2013 17:43:38 você escreveu:
> On Tuesday 09 July 2013 21:57:51 Alexander Neundorf wrote:
> > On Tuesday 09 July 2013, Sven Brauch wrote:
> > > I think Nuno's point is very interesting and worth thinking about. To
> > > stick with the firefox example, since they started rel
On 2013-07-10, Aaron J. Seigo wrote:
>=3D=3D On scheduling mainenance releases
>
> in a longer 4 month cycle, i=E2=80=99d cut that to 8 weeks and keep jus=
> t the one=20
> update.
>
> this would ease the burdon on our release team (and by extension packag=
> ers)=20
> while also giving developer
On Wednesday, July 10, 2013 06:54:06 PM Àlex Fiestas wrote:
> On Wednesday 10 July 2013 18:26:55 you wrote:
> > On Wednesday 10 of July 2013 18:08:04 Àlex Fiestas wrote:
> > > On Wednesday 10 July 2013 13:22:20 Sune Vuorela wrote:
> > > > On 2013-07-09, Sune Vuorela wrote:
> > > > > So. first one.
A Quarta, 10 de Julho de 2013 13:18:57 Aaron J. Seigo escreveu:
> == On branding and visual presentation
>
> some have noted that faster release cycles would make it hard to implement
> branding updates and artwork refreshes such as wallpapers. the answer to
> that is simple: these efforts must
On Wednesday 10 July 2013 18:26:55 you wrote:
> On Wednesday 10 of July 2013 18:08:04 Àlex Fiestas wrote:
> > On Wednesday 10 July 2013 13:22:20 Sune Vuorela wrote:
> > > On 2013-07-09, Sune Vuorela wrote:
> > > > So. first one.
> > >
> > > Second one
> > >
> > > Release frequency.
> > >
> > >
On Wednesday, July 10, 2013 06:08:04 PM Àlex Fiestas wrote:
> On Wednesday 10 July 2013 13:22:20 Sune Vuorela wrote:
> > On 2013-07-09, Sune Vuorela wrote:
> > > So. first one.
> >
> > Second one
> >
> > Release frequency.
> >
> > We have a giant quality problem. Distros won't ship a .0 release
On Wednesday 10 of July 2013 18:08:04 Àlex Fiestas wrote:
> On Wednesday 10 July 2013 13:22:20 Sune Vuorela wrote:
> > On 2013-07-09, Sune Vuorela wrote:
> > > So. first one.
> >
> > Second one
> >
> > Release frequency.
> >
> > We have a giant quality problem. Distros won't ship a .0 release t
On Wednesday 10 July 2013 13:22:20 Sune Vuorela wrote:
> On 2013-07-09, Sune Vuorela wrote:
> > So. first one.
>
> Second one
>
> Release frequency.
>
> We have a giant quality problem. Distros won't ship a .0 release to real
> users (as opposed to testers/power users) and wait until there has
On Tuesday 09 July 2013 21:15:54 Ingo Klöcker wrote:
> On Tuesday 09 July 2013 09:36:00 andrea diamantini wrote:
> > My idea about this concerns the way we let other people know aboout
> > new features. I usually read our feature plan (e.g.
> > http://techbase.kde.org/Schedules/KDE4/4.11_Feature_Pl
On Tuesday 09 July 2013 16:12:35 Andras Mantia wrote:
> Two point I want to mention:
> 1) working in a branch for kdepim is quite painful, as you need actually
> work on branches of 3 (or sometimes 4) modules: kdepimlibs, kdepim-runtime,
> kdepim (and akonadi). Keep them up-to-date, merge them at t
On Tuesday 09 July 2013 21:57:51 Alexander Neundorf wrote:
> On Tuesday 09 July 2013, Sven Brauch wrote:
> > I think Nuno's point is very interesting and worth thinking about. To
> > stick with the firefox example, since they started releasing every
> > ortography fix in the settings dialog as a ne
On 2013-07-09, Sune Vuorela wrote:
> So. first one.
Second one
Release frequency.
We have a giant quality problem. Distros won't ship a .0 release to real
users (as opposed to testers/power users) and wait until there has been
a couple of bug fix releases. Until we ensure that our .0 releases a
On Monday, July 8, 2013 15:04:40 Àlex Fiestas wrote:
> You can read all the proposal in:
> http://community.kde.org/KDE_Core/ReleasesProposal
Neat ... some thoughts:
== On branching
this will be much easier for those who develop features in branches rather
than use master as a big developer fre
On Monday 08 July 2013 18:59:12 Michael Pyne wrote:
> On Mon, July 8, 2013 17:45:10 Philip Muskovac wrote:
> > What would at least make my life easier here would be a way to easily get a
> > list of all patches that were applied to a stable release (esp. when someone
> > bothers to backport a fix a
On Tuesday 09 July 2013, Andras Mantia wrote:
> Hi,
>
> [...] (just replying at some point)
>
>
> Two point I want to mention:
> 1) working in a branch for kdepim is quite painful, as you need actually
> work on branches of 3 (or sometimes 4) modules: kdepimlibs,
> kdepim-runtime, kdepim (and ak
On Tuesday 09 July 2013, Sven Brauch wrote:
> I think Nuno's point is very interesting and worth thinking about. To
> stick with the firefox example, since they started releasing every
> ortography fix in the settings dialog as a new major version, I think
> attention in the media to their releases
On Tuesday 09 July 2013 09:36:00 andrea diamantini wrote:
> My idea about this concerns the way we let other people know aboout
> new features. I usually read our feature plan (e.g.
> http://techbase.kde.org/Schedules/KDE4/4.11_Feature_Plan).
> I think we could add one general page per project, sim
On Tuesday 09 July 2013 16:12:35 Andras Mantia wrote:
> Hi,
>
> [...] (just replying at some point)
>
>
> Two point I want to mention:
> 1) working in a branch for kdepim is quite painful, as you need actually
> work on branches of 3 (or sometimes 4) modules: kdepimlibs, kdepim-runtime,
> kdepim
On Tuesday 09 July 2013 16:12:35 Andras Mantia wrote:
> I also find the motivation somewhat contradictory. Yes, you want to provide
> new features faster, but by cutting down testing time. *Are you sure?*
Well here we have to ask whether the current testing procedure works. Since
the beta got rele
On 2013-07-08, Àlex Fiestas wrote:
I'm going to provide a handful of replies, each dealing with different
aspects of this - hopefully I will post them all over the next couple of
days. I will try to keep them short.
So. first one.
> Basically the idea is to cut testing time and compensate it by
Hi,
[...] (just replying at some point)
Two point I want to mention:
1) working in a branch for kdepim is quite painful, as you need actually work
on branches of 3 (or sometimes 4) modules: kdepimlibs, kdepim-runtime, kdepim
(and akonadi). Keep them up-to-date, merge them at the right point, e
>From my point of view, 3 month releases are going to actually increase
quality. At least in Nepomuk.
The Nepomuk developers (me included) have often merged feature
branches right before the feature freeze even if the branch has some
problems. No one wants to wait 8 months (2 months for the curren
On Monday 08 July 2013 20:40:59 Heinz Wiesinger wrote:
> Any reason not to CC kde-packager or kde-release-team? IMHO they'd be
> primary audiences for this.
kde-packagers is a private mailist, I'm not sure how to handle it.
kde-release-team, I assumed they were in kde-core-devel as well, but you
On Monday 08 July 2013 23:08:29 Ingo Klöcker wrote:
> On Monday 08 July 2013 22:14:28 Aurélien Gâteau wrote:
> > On Monday 08 July 2013 16:26:00 laurent Montel wrote:
> > > Le lundi 8 juillet 2013 16:11:05 Frank Reininghaus a écrit :
> > > > Hi,
> > > >
> > > > 2013/7/8 Àlex Fiestas:
> > > > > Now
My idea about this concerns the way we let other people know aboout new
features. I usually read our feature plan (e.g.
http://techbase.kde.org/Schedules/KDE4/4.11_Feature_Plan).
I think we could add one general page per project, similar to that one,
listing:
- the feature
- the branch where it is
On Tuesday, July 09, 2013 02:02:48 AM Aleix Pol wrote:
> On Mon, Jul 8, 2013 at 3:04 PM, Àlex Fiestas wrote:
> > Now that kde-workspace and kdelibs are going to be frozen (which in theory
> > means less work for everybody) I'd like to propose a new release schedule
> > to
> > be applied starting w
On Mon, Jul 8, 2013 at 3:04 PM, Àlex Fiestas wrote:
> Now that kde-workspace and kdelibs are going to be frozen (which in theory
> means less work for everybody) I'd like to propose a new release schedule
> to
> be applied starting with 4.12.
>
> Basically the idea is to cut testing time and comp
On Mon, July 8, 2013 17:45:10 Philip Muskovac wrote:
> What would at least make my life easier here would be a way to easily get a
> list of all patches that were applied to a stable release (esp. when someone
> bothers to backport a fix after the last point release is out).
> The only way to do th
I think Nuno's point is very interesting and worth thinking about. To
stick with the firefox example, since they started releasing every
ortography fix in the settings dialog as a new major version, I think
attention in the media to their releases has declined a lot -- nobody
cares any more that a
On Monday 08 July 2013 22:14:28 Aurélien Gâteau wrote:
> On Monday 08 July 2013 16:26:00 laurent Montel wrote:
> > Le lundi 8 juillet 2013 16:11:05 Frank Reininghaus a écrit :
> > > Hi,
> > >
> > > 2013/7/8 Àlex Fiestas:
> > > > Now that kde-workspace and kdelibs are going to be frozen (which
> >
On Monday 08 July 2013 16:26:00 laurent Montel wrote:
> Le lundi 8 juillet 2013 16:11:05 Frank Reininghaus a écrit :
> > Hi,
> >
> > 2013/7/8 Àlex Fiestas:
> > > Now that kde-workspace and kdelibs are going to be frozen (which in
> > > theory
> > > means less work for everybody) I'd like to propos
A Segunda, 8 de Julho de 2013 21:54:02 Albert Astals Cid escreveu:
> El Dilluns, 8 de juliol de 2013, a les 20:03:14, Nuno Pinheiro va escriure:
> > A Segunda, 8 de Julho de 2013 20:58:42 Albert Astals Cid escreveu:
> > > El Dilluns, 8 de juliol de 2013, a les 19:32:13, Nuno Pinheiro va
>
> escriu
El Dilluns, 8 de juliol de 2013, a les 20:40:59, Heinz Wiesinger va escriure:
> On Monday 08 July 2013 15:04:40 Àlex Fiestas wrote:
> > Now that kde-workspace and kdelibs are going to be frozen (which in theory
> > means less work for everybody) I'd like to propose a new release schedule
> > to be
El Dilluns, 8 de juliol de 2013, a les 20:03:14, Nuno Pinheiro va escriure:
> A Segunda, 8 de Julho de 2013 20:58:42 Albert Astals Cid escreveu:
> > El Dilluns, 8 de juliol de 2013, a les 19:32:13, Nuno Pinheiro va
escriure:
> > > A Segunda, 8 de Julho de 2013 15:04:40 Àlex Fiestas escreveu:
> > >
On Monday 08 July 2013 15:04:40 Àlex Fiestas wrote:
> Now that kde-workspace and kdelibs are going to be frozen (which in theory
> means less work for everybody) I'd like to propose a new release schedule to
> be applied starting with 4.12.
>
> Basically the idea is to cut testing time and compens
On Monday 08 July 2013 15:04:40 Àlex Fiestas wrote:
> Now that kde-workspace and kdelibs are going to be frozen (which in theory
> means less work for everybody) I'd like to propose a new release schedule to
> be applied starting with 4.12.
IMHO that's a bit hasty. There was previous talk about Fr
A Segunda, 8 de Julho de 2013 20:58:42 Albert Astals Cid escreveu:
> El Dilluns, 8 de juliol de 2013, a les 19:32:13, Nuno Pinheiro va escriure:
> > A Segunda, 8 de Julho de 2013 15:04:40 Àlex Fiestas escreveu:
> > > Now that kde-workspace and kdelibs are going to be frozen (which in
> > > theory
>
El Dilluns, 8 de juliol de 2013, a les 19:32:13, Nuno Pinheiro va escriure:
> A Segunda, 8 de Julho de 2013 15:04:40 Àlex Fiestas escreveu:
> > Now that kde-workspace and kdelibs are going to be frozen (which in theory
> > means less work for everybody) I'd like to propose a new release schedule
>
On Monday 08 July 2013 20:32:57 Thomas Lübking wrote:
> On Montag, 8. Juli 2013 20:30:39 CEST, Martin Graesslin wrote:
> > The concept of integration branches is a solution to this problem
>
> +1
>
> They do not only rise testing (beyond your own) but also and especially
> integrated testing (aga
A Segunda, 8 de Julho de 2013 15:04:40 Àlex Fiestas escreveu:
> Now that kde-workspace and kdelibs are going to be frozen (which in theory
> means less work for everybody) I'd like to propose a new release schedule to
> be applied starting with 4.12.
>
> Basically the idea is to cut testing time a
On Montag, 8. Juli 2013 20:30:39 CEST, Martin Graesslin wrote:
The concept of integration branches is a solution to this problem
+1
They do not only rise testing (beyond your own) but also and especially integrated
testing (against feature clashes where A xor B is good and A & B miserably
f
On Montag, 8. Juli 2013 20:09:47 CEST, laurent Montel wrote:
Yes I finished it 2 days ago, but started 2 months ago.
So it was bug fixing, I didn’t create new feature 2 days ago.
And I had 6 months to develop it, so think when there is 3 months to do it.
Hein?
And if it took you 10 years or
On Monday 08 July 2013 20:06:51 Albert Astals Cid wrote:
> El Dilluns, 8 de juliol de 2013, a les 14:03:19, Scott Kitterman va
escriure:
> > Albert Astals Cid wrote:
> > >El Dilluns, 8 de juliol de 2013, a les 11:25:42, Scott Kitterman va
> > >
> > >escriure:
> > >> On Monday, July 08, 2013 04:59
Le lundi 8 juillet 2013 19:55:46 Albert Astals Cid a écrit :
> El Dilluns, 8 de juliol de 2013, a les 15:45:13, laurent Montel va escriure:
> > Hi,
> > As you know I work a lot on kdepim (but you forgot to ask me if it was a
> > good idea or I didn’t receive mail... :) )
> >
> > Ok kdelibs and kde
El Dilluns, 8 de juliol de 2013, a les 14:03:19, Scott Kitterman va escriure:
> Albert Astals Cid wrote:
> >El Dilluns, 8 de juliol de 2013, a les 11:25:42, Scott Kitterman va
> >
> >escriure:
> >> On Monday, July 08, 2013 04:59:50 PM Àlex Fiestas wrote:
> >> > On Monday 08 July 2013 10:40:21 Scot
Albert Astals Cid wrote:
>El Dilluns, 8 de juliol de 2013, a les 11:25:42, Scott Kitterman va
>escriure:
>> On Monday, July 08, 2013 04:59:50 PM Àlex Fiestas wrote:
>> > On Monday 08 July 2013 10:40:21 Scott Kitterman wrote:
>> > > We've already experienced having some parts of the SC skip
>rele
El Dilluns, 8 de juliol de 2013, a les 11:25:42, Scott Kitterman va escriure:
> On Monday, July 08, 2013 04:59:50 PM Àlex Fiestas wrote:
> > On Monday 08 July 2013 10:40:21 Scott Kitterman wrote:
> > > We've already experienced having some parts of the SC skip releases and
> > > it
> > > was a real
El Dilluns, 8 de juliol de 2013, a les 15:45:13, laurent Montel va escriure:
> Hi,
> As you know I work a lot on kdepim (but you forgot to ask me if it was a
> good idea or I didn’t receive mail... :) )
>
> Ok kdelibs and kde-workspace is frozen until KDE SC5 so less work for you
> for example.
>
El Dilluns, 8 de juliol de 2013, a les 15:14:07, Luigi Toscano va escriure:
> On Monday 08 of July 2013 15:04:40 Àlex Fiestas wrote:
> > Now that kde-workspace and kdelibs are going to be frozen (which in theory
> > means less work for everybody) I'd like to propose a new release schedule
> > to be
On Monday 08 of July 2013 18:09:44 Àlex Fiestas wrote:
> On Monday 08 July 2013 17:45:10 Philip Muskovac wrote:
> > I understand that we can have additional point releases if people still
> > find issues that need to be fixed, but with so many short release cycles
> > I expect that the attention fo
On Monday 08 July 2013 17:45:10 Philip Muskovac wrote:
> Hi,
>
> With my Kubuntu Developer Hat on, one concern I have is the support
> timeframe for the planned 4.13 release. Kubuntu 14.04, planned to be
> released in April 2014 will be a Long Term Support release meaning we'll
> have to care abou
On Monday, July 08, 2013 04:59:50 PM Àlex Fiestas wrote:
> On Monday 08 July 2013 10:40:21 Scott Kitterman wrote:
> > We've already experienced having some parts of the SC skip releases and it
> > was a real problem from a distribution perspective. Please, let's not do
> > it again.
>
> KDE-PIM w
On Monday 08 July 2013 10:40:21 Scott Kitterman wrote:
> We've already experienced having some parts of the SC skip releases and it
> was a real problem from a distribution perspective. Please, let's not do
> it again.
KDE-PIM will be released, just not with the features of those working with a 6
On Monday 08 July 2013 16:38:02 you wrote:
> Le lundi 8 juillet 2013 16:19:02 Àlex Fiestas a écrit :
> > I did pasted the link in #kontact and #akonadi a couple of times before
> > sending this email :p
>
> I never saw it.
> And paste on irc is not speak with guy which works several project.
Sure,
1 - 100 of 110 matches
Mail list logo
