kdebase + kdelibs head

[Aaron J. Seigo]

On Tuesday 21 March 2006 09:46, Aaron J. Seigo wrote:
> On Tuesday 21 March 2006 02:51, David Faure wrote:
> > But I think that once we have a big change ready in snapshot, we can
> > just decide to go ahead and update the snapshot. Shall I do that?
>
> as long as these big changes don't happen every few days ;) i think it
> would be a nice way to help keep up the pace of porting the non-lib modules
> while not discouraging people from following trunk/kdelibs ...

apparently my pre-caffeine brain spews out undecipherable gibberage. let me 
try again:

for those of us who don't have the disk space or time (i lack both on my 
laptop, to be honest, as i already have 3 kde installations on it, 2 of which 
are from source), we are left with a choice between kdelibs_snapshot and 
trunk/kdelibs. for those of us working on library issues, it's really not a 
choice: trunk/kdelibs is the only way to do that. we should also try and get 
as many "core" people working on trunk/kdelibs as possible.

but that leaves us with the inability to work on applications. this isn't a 
problem for most application development, but the apps i tend to work on the 
most live in kdebase these days.

is it possible that those who work on kdebase are more likely to also follow 
trunk/kdelibs as well? kdelibs+kdebase are sort of the foundational parts of 
kde anyways and in that sense "go together". and doesn't it make more sense 
to have actual applications to test trunk/kdelibs against?

what i'd suggest is that we either need to keep kdelibs_snapshot up to date 
with larger changes made in trunk/kdelibs so that we can port kdebase more 
aggressively or (and the more i think about it, the more i like this 
option: ) do a kdebase_snapshot along with kdelibs_snapshot which is meant to 
be primarily read-only.

this way we can work on trunk/kdebase in tandem with kdelibs which gives us:

 - more developers on trunk/kdelibs without imposing more hassles for them
 - applications to test against trunk/kdelibs
 - the ability to more rapidly evolve kdebase as it can change in tandem with 
kdelibs, which is very uncomfortable to do right now

of course, in kdelibs_snapshot is going away in a couple of weeks (which i 
actually don't see happening) then this is a moot point. but if _snapshot is 
here for a month or more i'd really like to see a refinement of our current 
methods here.

hopefully that's more understandable than my 3 line bit of cyphertext from 
earlier in the morning ;)

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

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060321/d147d494/attachment.sig>