CI Requirements - Lessons Not Learnt?
mgraesslin at kde.org
Sun Jan 8 19:22:01 GMT 2017
Am 6. Januar 2017 17:46:30 MEZ schrieb Alexander Neundorf <neundorf at kde.org>:
>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
>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.
>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