New Prosal [was Re: policy change related to kdelibs snapshots]

[Andras Mantia]

On Tuesday 11 July 2006 12:12, Stephan Kulow wrote:
> Am Dienstag, 11. Juli 2006 10:15 schrieb David Faure:
> > > Conflicts within ported code might still happen, but I think it
> > > won't be too frequent. Well, all in all, I support Dirk's
> > > version.
> >
> > ... which is blatantly ignoring the request from most app
> > developers to not have to update kdelibs for a period of time
> > before they start working on the evening.
>
> Interestingly enough you (Andras) said on kde-commits you stay out of
> app development because kdelibs is changing too quickly and
> drastically. 

I knew someone will spot that. :-)

> Now I propose that we make trunk always compiling in 
> making _sure_ we only merge in compiling changes. And you rather want
> a trunk that is changing all day for porting efforts instead of once
> in a while?

The reason I stayed out that too many things were introduced and broken 
in a very short time. I missed one snapshot update, and things got out 
of control. ;-)
 The reason I want the way Dirk proposed is that we - app developers - 
don't have to take care of a snapshot, can use trunk, fix bugs there 
directly when they are spotted. Doing a recompile every weekend is not 
a big problem and certainly it worths to work on a library which will 
have bugfixes and BC improvements asap. Having new features and BIC 
changes developed in a branch makes more sense than keeping this 
snapshot way. 
 So I hope I didn't misunderstood Dirk's intention, but that is what I 
would like.
 Now if we - library developers - work this way I see no drawback. If I 
improve the library without breaking compilation, I can work in trunk 
and everybody is happy. If I work on a completely new thing which might 
break other apps, I do in a branch, test it there, and possibly port 
the usage of it in separate branches. On every Friday (or every other 
Friday), the library changes and what I ported in other places are 
merged into trunk. 
 With the above scenario app developers can work on relative stable 
library (at least they don't have to update every day if they don't 
want, just every weekend), library developers can do changes without 
interferencing each other and the app developers, library developers 
would help the app developers by porting the code to the new API 
they've created (so they know the best how the API should be used). The 
only drawback can be possible conflicts during merge (if two library 
developers work on the same files but doing different changes) and svn 
history issues.

> - this did not work out at all. Dirk is right if he says it's hard to
> do changes if the code is not compiling and so defect over defect
> sums up in the code. This is frustrating for both application
> developers as it's to libs developers. And if it wasn't for Laurent,
> KDE4 development would already have stopped long ago (Again: thanks
> Laurent).

That is right, he was invaluable in the past months.

> - so my proposal is to give libs developers a branch where they can
> sort out new kdelibs changes and these changes are merged into trunk
> as one.

As I understood you suggested to still keep the snapshot, this way 
creating trunk, bleeding edge, snapshot, different development branches 
=> very confusing.

> - Dirk's proposal (from what I understand) is to drop the time based
> schedule and develop changes right in trunk. Every developer would
> have to make sure his changes are ported out in trunk asap.
>
> Actually the only problem I can see with Dirk's proposal is the
> objection of quite some application developers against dropping the 2
> week cycle. I guess quite some concerns are about the never ending
> porting efforts and the always required recompilations.

So why not keep his proposal, but instead of BIC Fridays, there will be 
a BIC day every other week? I just want to have a simpler process where 
you can both be happy as an app developer and an occasional library 
developer as well. You know, most bugs will show up in applications, 
and I for one, would like to put a fix for them directly in trunk 
without messing with separate branches, snapshots, etc.

> My most important requirement at this point is that library
> developers are required to make sure their API changes make sense (in
> either porting the apps for themselves or writing good porting guide
> material on use cases).

I fully agree.

> So how about we try it with this:
>
> NEW PROPOSAL:
>
> We forget about the snapshotting as it, but don't allow BIC/SIC
> changes to kdelibs trunk outside of mondays - and these commits have
> to come with a prepared port of all modules in trunk/KDE and koffice.

Hey, this is just what I wrote above. :-)

> That way application developers don't need to recompile every
> evening, because the apps would work with the kdelibs of the evening
> before, but still kdelibs developers wouldn't need to apply bugfixes
> to two branches and we wouldn't loose SVN history - we could even
> have grouped commits for the API change and it's porting.

Exactly, I support it!

Andras

-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
-------------- 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/20060711/3d4209cf/attachment.sig>