CI Requirements - Lessons Not Learnt?

Ben Cooksley bcooksley at
Tue Jan 10 21:42:35 GMT 2017

On Mon, Jan 9, 2017 at 8:22 AM, Martin Gräßlin <mgraesslin at> wrote:
> Am 6. Januar 2017 17:46:30 MEZ schrieb Alexander Neundorf <neundorf at>:
>>On 2017 M01 6, Fri 22:39:22 CET Ben Cooksley wrote:
>>> See my notes above re. why tying this to the dependency freeze date
>>> a bad idea and won't really work.
>>> Given that we potentially have to take into account Qt version bumps
>>> and base system rebuilds - i'll give a timeline of 1 month's advance
>>> notice (this is an absolute worst case scenario time). In most
>>> instances we can turn things around in much shorter time (about a
>>> week), especially where it's just a case of installing an already
>>> available package / adding a PPA/Equivalent Repository.
>>> The significant variation in time above is why I don't want to
>>> actually specify a time frame which is set in stone. Some things are
>>> just easier to provide / upgrade than others.
>>how about some simple rule like "new dependencies every first of the
>>and 1 week notice. For the developer this would mean in the worst case
>>5 weeks
>>waiting, which is probably quite a lot.
>>E.g. if you need a new dependency, and announce it let's say January
>>you'll get it February 1st.
>>If you announce it January 29th, you get it March 1st.
> In general I like the more formal approach to dependency handling.
> This concrete proposal is in my opinion to restrictive to developers - in case of plasma it could mean only one date per release schedule.
> That's difficult to plan and makes it easy for devs to miss. If for whatever reason you cannot push that one day you have to wait a complete release cycle.
> And I don't see how this addresses the problem of CI needs time. As Ben told us one week might not be enough.
> It can address the problem for distro consumers, but for developers on older distros it wouldn't help either.

Can we have a proposal from your side then Martin?

As i've said previously, what i'm asking for here is fundamentally
incompatible with integration into a release schedule, as dependencies
can be bumped at essentially any time from the point of a version
being released (the unfreeze) to the point dependencies are frozen in
the lead up to a release. The advance notice i've asked for needs to
be given before said bump actually happens.

Note that the amount of notice needed is very dependent on the nature
of the bump - some bumps could be sorted in 24 hours... while others
require extensive planning and need weeks.

> Cheers
> Martin


>>Of course such the numbers (weeks) are arbitrarily chosen and could be
>>I guess something like this would be convenient for "consumers" of the

More information about the kde-core-devel mailing list