kde-core-devel Digest, Vol 66, Issue 30

Tue Sep 9 23:01:34 BST 2008

kde-core-devel-request at kde.org wrote:
> Send kde-core-devel mailing list submissions to
> 	kde-core-devel at kde.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://mail.kde.org/mailman/listinfo/kde-core-devel
> or, via email, send a message with subject or body 'help' to
> 	kde-core-devel-request at kde.org
> 
> You can reach the person managing the list at
> 	kde-core-devel-owner at kde.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of kde-core-devel digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Review request for knotify osd plugin (Ben Cooksley)
>    2. Re: Change release schedule 4.2 and schedule for 4.3
>       (Mauricio Piacentini)
>    3. Re: Change release schedule 4.2 and schedule for 4.3 (Tom Albers)
>    4. Re: Change release schedule 4.2 and schedule for 4.3 (Tom Albers)
>    5. Re: Change release schedule 4.2 and schedule for 4.3
>       (Andreas Pakulat)
>    6. Re: Change release schedule 4.2 and schedule for 4.3
>       (Pau Garcia i Quiles)
>    7. Re: Change release schedule 4.2 and schedule for 4.3
>       (Thiago Macieira)
>    8. Threadweaver::JobRunHelper::runTheJob failed/done Signals
>       (Alejandro Wainzinger)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 10 Sep 2008 08:10:00 +1200
> From: "Ben Cooksley" <sourtooth at gmail.com>
> Subject: Re: Review request for knotify osd plugin
> To: kde-core-devel at kde.org
> Message-ID:
> 	<b366d7a00809091310qe7531e3k6adfd5b5d429948c at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On 9/8/08, Olivier Goffart <ogoffart at kde.org> wrote:
>> Le dimanche 7 septembre 2008, Ben Cooksley a ?crit :
>>> the two configuration parameters i spotted "Timeout" and "Persistent"
>>>
>>> || "Persistant" have been added to the osd knotify plugin, being
>>>
>>> appropriately handled.
>>>
>>> -the Persistent option should be treated however as deprecated, you
>>> should set the Timeout to 0 instead.
>>> -Previously the option for hiding after a certain time was called
>>> "Time" and was renamed to "Timeout", in order to provide
>>> compatability.
>>>
>>> as long as there are no others i didn't miss this means that
>>> applications do not have to adjust themselves ( apart from the name of
>>> the plugin they are asking for ), and as long as they don't use the
>>> dbus interface that kpassivepopup provided.
>>>
>>> bcooksley
>>
>> Sorry i missunderstand you.
>> You're not touching the KNotification Api, are you?
>> Because you shouldn't.
>>
>>
>> KPassivePopup doesn't provide dbus interface.
>> The dbus code which is in the notifybypopup.cpp is used for the plasma
>> noticiation.
>>
>> You should not create a new plugin, but modify the notifybypopup one to not
>> use KPassivePopup, but your fancy OSD instead.
>>
>> Application should need no change at all.
>>
>> If application need more complex OSD with custom widget on it, they will
>> have
>> to use the OSD without using KNotification.    But what are those
>> applications? and what do they do?
>>
>>
> 
> no, i am not touching the knotification api. the changes i will have
> to make to kpassivepopup will be extremely invasive ( removing timer
> module as handled by osd, adding options for progress, click on close,
> position ) but it is possible, i will do something on it.
> 
> integrating with plasma via dbus makes sense, just never figured out
> why the dbus system was there.
> 
> regarding applications needing more complex osd's, they can just
> render them into the image if what they need to add is small enough (
> i won't add anything to assist them at all w/ this )
> 
> bcooksley
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 09 Sep 2008 17:33:22 -0300
> From: Mauricio Piacentini <piacentini at kde.org>
> Subject: Re: Change release schedule 4.2 and schedule for 4.3
> To: kde-core-devel at kde.org
> Message-ID: <48C6DD92.3000403 at kde.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Speaking from my experience in KDE Games, you can not force someone to 
> participate in the stabilization phase anyway. What I see happening is 
> that we end up having a smaller window of opportunity for new 
> development to occur. This (I think) can be better handled with a DVCS 
> that is friendlier to branches and local work. I have no experience with 
> git, but it appears to foot this bill from what I have heard. What I 
> know for a fact is that very few people bother to branch in SVN right 
> now: we simply wait until things are unfrozen to start working on new 
> features, that is what happens. And if someone is busy by the time the 
> trunk is open the development does not happen, it is simple as that.
> 
> As a comparison, in the time the trunk was "opened" we were incredibly 
> productive, just before 4.0. I do think we can regain that drive with 
> the "always summer in trunk" proposal by Dirk and Sebastian. At least I 
> think we should try something different, as the current centralized and 
> serialized mode is apparently hampering development at least on some 
> areas of the project.
> 
> The freeze periods really do impact our module negatively, from looking 
> at what happened before 4.0 and 4.1. Number of commits is much lower and 
> the community disperses for 2 or 3 months. We stop working on features 
> that we think will not be completed in time, or worse, do not start 
> working on them at all. In our case this happens because probably there 
> are not many showstopper bugs, so freeze period equals no development 
> activity for several people in our module, as branching is expensive in SVN.
> 
> I also see that the ones that work in bugfixing and stabilization are 
> not necessarily the ones that work on new features, so I fail to see how 
> we can get worse compared with what we have now. The question of 
> stability of code can not be improved I think by forcing people to stop 
> working on trunk for a given period of time. In fact, by giving people 
> the freedom to commit at anytime we will probably avoid the rush of 
> half-finished features just before the freeze date, and this might even 
> improve the quality and stability, who knows. This tie between the 
> development schedule and the release schedule appears to be something 
> not optimal, and affects the community building portion of the project 
> as well. So why not try something different, at least for post-4.2, and 
> see what happens?
> 
> Regards,
> Mauricio Piacentini
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 09 Sep 2008 22:34:41 +0200
> From: Tom Albers <tomalbers at kde.nl>
> Subject: Re: Change release schedule 4.2 and schedule for 4.3
> To: kde-core-devel at kde.org
> Message-ID: <2183847.jFWPyCFQSv at kde.nl>
> Content-Type: text/plain; charset="us-ascii"
> 
> At Tuesday 09 September 2008 21:52, you wrote:
>> On Tue, Sep 9, 2008 at 11:54 AM, Boudewijn Rempt <boud at valdyas.org> wrote:
>>> On Tue, 9 Sep 2008, Thiago Macieira wrote:
>>>
>>>> On Terça 09 Setembro 2008 15:23:43 Torsten Rahn wrote:
>>>>> The proposed always-summer-in-trunk model rather is an "opt-in" model which
>>>>> allows the group to become much more loosely bound "together". "Opting in"
>>>>> would require to take action and make a decision (which people try to avoid
>>>>> if possible)
>>>> The current model is already an opt-in one.
>>>>
>>>> If someone doesn't want to participate in the stabilisation phase, all he has
>>>> to do is stop committing.
>>> Sure: but your reasoning is pretty specious. If one stops committing at all,
>> or only
>>> work in a branch for three months, it feels bad. As if you've placed yourself
>> outside
>>> the community. Which, in fact, you have.
>>>
>>> If, on the other hand, you keep coding cool stuff and, while never really
>> making it
>>> available to users, still making it somewhat available, you can blog about it
>> and feel
>>> good and a front-runner who's taking KDE places. While you're still relying
>> on others
>>> to do the dirty work of bringing your stuff up to scratch and making it
>> releasable.
>>> Right now, having the boring work, i.e., making it into a release, depends on
>> you also
>>> participating in the stabilistation phase, trunk-is-always open rewards the
>> opposite:
>>> have fun. do cool stuff, never care about integration or stabilisation, just
>> blog and be
>>> famous.
>> I see it the opposite way around.
>> right now, as kde approaches a feature freeze, everyone rushes to get
>> their pet features in. we get a big dump of barely-working-ish code,
>> everything's a big mess for anyone using kde svn, and we all have to
>> pick through this ugliness and try to get it cleaned up before release
>> time. if someone goes on holidays or loses their laptop or otherwise
>> is unavailable during this time, someone else has to clean up their
>> mess or the bugs end up in a release. (several evil plasma zui bugs
>> got into 4.1.0 because I was busy with SoC and forgot about the
>> release schedule.)
>>
>> if it was "always summer in trunk", features would not be allowed in
>> until they're already reasonably stable. people could develop in a
>> branch (requiring a VCS that does cheap branches, ideally local
>> branches because nobody wants to see my "this is a mess, let's try
>> again next week" commits) and stabilise as they go, not having to
>> worry about a feature-freeze deadline. of course bugs would sneak into
>> trunk, but the big obvious ones would be fixed before that instead of
>> being put off because it's feature-time. people who aren't developing
>> plasma wouldn't see big breakages, they'd just see the sneakier bugs
>> that crept up to the branch they're on (summer or autumn or whatever),
>> and then they can either fix those or nag us about them.
>>
>> I really want to be able to work on bugs or features based on my own
>> schedule, not based on freezes. when we're not in freezes I'm too busy
>> trying to cram in features, so I don't fix bugs I want to fix, and
>> when we're in a freeze then I can't work on a feature without the
>> hassle of setting up a branch or git-svn (which is horribly fragile),
>> even if I've hit a wall with bugs. and then there's the stuff in my
>> schedule that conflicts with kde's schedule entirely, and I might end
>> up doing nothing at all and missing a window because I had homework or
>> something - but I can't just do it later because later it won't work
>> with kde's schedule.
>> it's just silly. the current dev. model really doesn't suit the way I work.
>>
>> I do agree that we should be very careful to ensure people are still
>> encouraged to fix bugs, and keep an eye on the stability of the
>> project, but I believe this change would result in *less* bugs in
>> releases, not more.
> 
> I read your complete mail, but I don't see any reasoning for the fact that it would result in less bugs in releases. Can you explain that more?
> 
> How come you think that when there is always summer, you assume you have fixed more bugs in your code vs having a somehow forced stabilisation period for that?
> 
> Toma
> 
> ------------------------------
> 
> Message: 4
> Date: Tue, 09 Sep 2008 22:41:25 +0200
> From: Tom Albers <tomalbers at kde.nl>
> Subject: Re: Change release schedule 4.2 and schedule for 4.3
> To: kde-core-devel at kde.org
> Message-ID: <2475149.KHdc1pS6la at kde.nl>
> Content-Type: text/plain; charset="us-ascii"
> 
> At Tuesday 09 September 2008 20:54, you wrote:
>> On Tue, 9 Sep 2008, Thiago Macieira wrote:
>>
>>> On Terça 09 Setembro 2008 15:23:43 Torsten Rahn wrote:
>>>> The proposed always-summer-in-trunk model rather is an "opt-in" model which
>>>> allows the group to become much more loosely bound "together". "Opting in"
>>>> would require to take action and make a decision (which people try to avoid
>>>> if possible)
>>> The current model is already an opt-in one.
>>>
>>> If someone doesn't want to participate in the stabilisation phase, all he has 
>>> to do is stop committing.
>> Sure: but your reasoning is pretty specious. If one stops committing at all, or
>> only
>> work in a branch for three months, it feels bad. As if you've placed yourself
>> outside
>> the community. Which, in fact, you have.
>>
>> If, on the other hand, you keep coding cool stuff and, while never really
>> making it
>> available to users, still making it somewhat available, you can blog about it
>> and feel
>> good and a front-runner who's taking KDE places. While you're still relying on
>> others
>> to do the dirty work of bringing your stuff up to scratch and making it
>> releasable.
>>
>> Right now, having the boring work, i.e., making it into a release, depends on
>> you also
>> participating in the stabilistation phase, trunk-is-always open rewards the
>> opposite: 
>> have fun. do cool stuff, never care about integration or stabilisation, just
>> blog and be
>> famous.
>>
>>> He doesn't have to remain idle for the 3 months when trunk is frozen. He can 
>>> create branches and work there. Or keep the code to himself in a local DVCS 
>>> repository (svk or git work just fine for that).
>> Hard facts are needed with this kind of argument, the kind of facts Paul Adams
>> can provide: 
>> how many people stop committing and start working in branches during soft and
>> hard feature
>> freeze. Does the commit rate drop off, and what happes to the bug rate?
>>
>>> The point of "it's always Summer in trunk" is to make sure that the 
>>> development stays in trunk and those people don't go away for 3 months
>> because 
>>> it's frozen.
>> Sounds great. But I don't believe it will work that way. Always summer in trunk
>> will,
>> I predict, result in a big mess and nobody but the paid help doing
>> stabilisationand
>> release work. Development in trunk is a Bad Thing if diverts any attention from
>> releasing. 
>> No feature is worth a dime if it means a feature that got implementer earlier
>> gets
>> released later.
>>
>> Boudewijn
> 
> I hate to fload the mailinglist. But I agree completely with Boudewijn. I think these are valid concerns and I don't really see this git/always-summer be a magic solution to our problems.
> 
> As long as our users use another branch than what we developers use, I'm likely to vote against that plan. I think the only way to make awesome releases is to actually use what the users use. So you get annoyed with the same bugs at the same time (or rather a bit earlier). 
> 
> Best.
> 
> Toma
> 
> ------------------------------
> 
> Message: 5
> Date: Tue, 9 Sep 2008 23:02:13 +0200
> From: Andreas Pakulat <apaku at gmx.de>
> Subject: Re: Change release schedule 4.2 and schedule for 4.3
> To: kde-core-devel at kde.org
> Message-ID: <20080909210213.GB22551 at morpheus.apaku.dnsalias.org>
> Content-Type: text/plain; charset=us-ascii
> 
> On 09.09.08 11:47:30, Aaron J. Seigo wrote:
>> On Tuesday 09 September 2008, Cornelius Schumacher wrote:
>>> subproject has special needs and needs a different schedule it might make
>>> sense to for example skip a release or even do a separate release.
>> this already happens, of course =)
>>
>> i think it would have been great if, e.g., the kdevelop module could have 
>> simply ignored the freeze cycles for 4.0 and 4.1, gaining an extra 4 months of 
>> available mainline development time. they weren't going to make those releases 
>> anyways, so why bother?
> 
> Uhm, thats a bad example, because we actually did that :P That is we
> completely ignored any release schedules for the two modules we were
> working on. So we didn't really loose any time.
> 
> Andreas
>