New kdelibs policy starting monday

[Ismail Onur Filiz]

Hi,

On Saturday 15 July 2006 04:01, Stephan Kulow wrote:
> Hi!
>
> As there doesn't seem to be a real discussion going on anymore,
> I declare the new trunk/KDE policy applying starting this monday.
>
> This means:
>  - next monday we will erase kdelibs4_snapshot and from that time
>     trunk/KDE/kdelibs is the kdelibs to compile against
>  - all of trunk is supposed to compile at any time against that very
>    kdelibs
>  - Source and binary incompatible changes are only allowed on mondays
>    (on every monday though) and porting efforts should be finished the
>    same evening (that means every developer is allowed to start changing
>    8am her timezone and has to make sure trunk is compiling till 10pm his
>    timezone (being around in #kde4-devel and awaiting people complaining
>    might be enough).
> - Source incompatible changes shall be developed in an extra branch before
>    they hit trunk. As trunk is supposed to compile at any time, you can
> branch off trunk and make your changes till your branch compiles again.
>
> Now I hope we can get kdepim and kdewebdev to compile before monday,
> otherwise this policy will be a bit complicated to enforce. And I hope
> everyone makes sure we make this a dynamic process, i.e. update the policy
> if it turns out it's imperfect.

How about announcing/explaining what the source and binary incompatible 
changes are, like Aaron suggested? Quoting him:

>>earlier i suggest a reporting mechanism for API changes: an email to 
>>kde-core-devel with "[API] <classname>" as the title. would that work?

I am a bit out-of-the-loop by being in the Pacific timezone and mostly being 
able to contribute during weekends, therefore more or less the only way to 
follow such changes is follow the commit logs. But that requires reading a 
lot of irrelevant things, and most of the time the logs are not that 
explanatory. A 'real explanation' would for instance enable me to help with 
the porting efforts, as somebody mainly interested in kdepim.

Best...

Ps: BTW, for this 'branching for changes' phenomenon, I strongly suggest 
everybody to look into svk, which is a distributed vcs built on top of svn. 
But that's another topic.

>
> Greetings, Stephan