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

List:       kde-devel
Subject:    Re: Developing applications for KDE4
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2007-02-03 16:47:26
Message-ID: 200702030947.26520.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On February 3, 2007, Dirk Stoecker wrote:
> On Fri, 2 Feb 2007, Aaron J. Seigo wrote:
> > there is a lot of work going into high level documentation for kde4. we
> > do need more effort there, but i'm happy with the pace of things at the
> > moment. we'll easily eclipse what kde3 had in this regard.
>
> I said that the KDE docs are much better. I agree on that. 
> 1.2 -> 2.0 I feel like standing in the rain. Classes and features are
> removed and nowhere a statement how the replace the stuff.

kdelibs/KDE4PORTING.html

this is referenced (including a link to it on the web) from devnew here:

http://developernew.kde.org/Development/Tutorials/Porting

and it will one day be hosted on the wiki. right now it makes more sense to be 
in SVN. if you searched for "porting" on devnew you'd find the above page is 
the first link returned.

we'll be making more noise about devnew once it has its final name so that 
people are actually aware of this stuff.

> > > - All this together with bugs that have been fixed in KDE3 and reappear
> > >   in KDE4.
> >
> > which bugs are these? we have a forward porting policy so this should be
> > kept to an absolute minimum. or is this just hand waving?
>
> Some (most) of these, which are fixed by people who don't run a KDE4
> development. I try to port my bug fixes to trunk, but as I cannot test it
> there this only works, when the structure of the code is nearly the same
> as for 3.5 branch.

perhaps you can find a kde4 code buddy. i do this for some people since 
testing a patch is usually a 10 minute job; writing the patch often takes 
longer, but testing is pretty swift. irc and email lists rock for this =)

> Thought I cannot say to what extend this will be a problem, but it exists
> nevertheless.

understood and agreed

> > the separation is largely symbolic, however, as its the same people
> > working on both. branching is nothing new in the software development
> > world.
>
> I know. And I also know the negative effects of branching. I tend to find
> the "extreme programming" approach better, where larger changes are broken
> down into smaller pieces. You can do major software reworking without
> loosing the possibility to always have one working version. If you agree
> that the seperation is largely symbolic, then you also must agree this
> approach would have worked for KDE as well.

we have been doing exactly this except we haven't done regularly announced 
snapshots. we have a weekly day for libs changes with immediate integration 
efforts and people are testing changes as they go; we do larger changes 
individually in branches and then merge them in one by one, etc... we're not 
that far off from what you're suggesting, with the exception of not bringing 
in more people with regularly announced milestones.

again, it comes back to the poor performance of release engineering, something 
that is being addressed but which could also use more hands (sub to the 
release-team@kde.org list if you can help! =)

> > > but from my point of view and compatibility layer and smooth
> > > transition would have been better.
> >
> > the math on the human resources and time required to do this then compare
> > against reality and you'll find out why this doesn't happen.
>
> Smooth transition does not need more, but less resources if done in the
> right way.

perhaps you aren't aware of the scope of the kde4 project then, because this 
simply is not realistic.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)

[Attachment #5 (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


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