Am 10. Januar 2017 22:42:35 MEZ schrieb Ben Cooksley <bcooks...@kde.org>: >On Mon, Jan 9, 2017 at 8:22 AM, Martin Gräßlin <mgraess...@kde.org> >wrote: >> >> >> Am 6. Januar 2017 17:46:30 MEZ schrieb Alexander Neundorf ><neund...@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
