CI Requirements - Lessons Not Learnt?

[Martin Gräßlin]

Am 10. Januar 2017 22:42:35 MEZ schrieb Ben Cooksley <bcooksley at kde.org>:
>On Mon, Jan 9, 2017 at 8:22 AM, Martin Gräßlin <mgraesslin at kde.org>
>wrote:
>>
>>
>> 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
>>>is
>>>> 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
>>>month",
>>>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
>>>6th,
>>>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.

Honestly, that is an inflexibility I cannot work with. I don't see how I as a dev can
plan to upgrade a dependency if all we get is something between a day and months.
Please remember that our release schedule is only about 3 months. With the
requirements presented here it means I have to announce in the last release cycle that I want to upgrade a dependency.

That doesn't work. Such inflexibility take away the advantage of having a CI.

Cheers 
Martin
>
>>
>> Cheers
>> Martin
>
>Regards,
>Ben
>
>>>
>>>Of course such the numbers (weeks) are arbitrarily chosen and could
>be
>>>different.
>>>
>>>I guess something like this would be convenient for "consumers" of
>the
>>>sources.
>>>
>>>Alex