[ckan-dev] release date for 2.4

Wed Mar 18 15:43:30 UTC 2015

Sounds great to me. I'll bring it up with the Tech Team tomorrow.

Dave

On 18 March 2015 at 15:21, Steven De Costa <
steven.decosta at linkdigital.com.au> wrote:

> Coolio, so let's ship 2.4 on 4 June. 2.5 on 4 Sept and then 3.0 on 4 Dec.
> Then 3.1, 3.2, 3.3 and 4.0 on a similar schedule in 2016.
>
> Does that work?
>
>
> On Wednesday, March 18, 2015, David Read <david.read at hackneyworkshop.com>
> wrote:
>
>> Steven,
>>
>> We do 'point-point' releases (e.g. 2.3.1) without a timetable. It might
>> be a sudden security issue, or back-ports, released with an appropriate
>> urgency. Point-point releases have an established meaning, process and
>> frequency. So unless there is support for a change, I think the tech team
>> should be left to manage the details of these.
>>
>> We're discussing normal 'point' releases (e.g. 2.4) which have been every
>> 3 or 4 months. I don't see why you'd want to delay them to 6 months. I
>> think it's great that you're drumming up interest and people for new
>> features, but they can slot in whichever release is next whenever they are
>> ready. There's no reason to delay hum-drum releases, with fixes and general
>> improvements that devs really appreciate, every 3 months.
>>
>> Dave
>>
>> On 18 March 2015 at 14:56, Steven De Costa <
>> steven.decosta at linkdigital.com.au> wrote:
>>
>>> Thanks David. Regular patch releases sound great, needed and
>>> appropriate. So 2.3.1, 2.3.2, etc.
>>>
>>> Six months would be a good target for 2.4 if we were to consider more
>>> significant structure updates via such a cycle.
>>>
>>> And, if feature freeze was done in four then it gives vendors two months
>>> to update integrations, etc. Then the whole world moves forward with the
>>> release together.
>>>
>>> I think CKAN is the kind of thing that can be a core component of
>>> other hybrid systems so I'd hope to encourage such adoption.
>>>
>>> Please don't let any of these ideas slow anyone down though. When I'm
>>> back in the office next week I'll be working through the roadmap features
>>> with our team and picking a few to tackle. The main on I'd like Link to
>>> help with is the first time install to make it so easy my mum could do it.
>>>
>>> Hoots!
>>>
>>>
>>> On Wednesday, March 18, 2015, David Read <david.read at hackneyworkshop.com>
>>> wrote:
>>>
>>>> Clearly frequent releases are necessary. I can't tell how you got the 6
>>>> months figure but it doesn't feel frequent enough to me. If someone is
>>>> doing a block of customizing, it might take 1 or 2 months. If they want a
>>>> new feature or bugfix and its not going to be released for several months
>>>> then they are more likely to fix it themselves on their own fork of ckan,
>>>> will be further from master and less likely to contribute it back.
>>>>
>>>> The 2.3 release was exceptional for being almost 13 months after 2.2.
>>>> Nearly all previous releases were spaced 3 or 4 months after the previous
>>>> one.
>>>>
>>>> The policy has been to just release regularly every three months. This
>>>> was disrupted in the last release by the premature merging of a large and
>>>> incomplete feature, and perhaps the notion that OKF was passing
>>>> responsibility for releases to the CKAN Association. If we work to keep the
>>>> master branch in a useful state then it shouldn't become an issue again.
>>>>
>>>> What does need addressing is the cost of doing a release. I guessing it
>>>> is a few days work. I think the tech team should review it, minimize the
>>>> cost and codify it to make it easier for other people to do it, aside from
>>>> Adria.
>>>>
>>>> David
>>>>
>>>> On 16 March 2015 at 14:40, Steven De Costa <
>>>> steven.decosta at linkdigital.com.au> wrote:
>>>>
>>>>> Two thumbs up is a good start :)
>>>>>
>>>>> I'd add that part of the motivation for routine six month releases is
>>>>> to allow a commercial ecosystem to then build their own roadmap on top of
>>>>> that of CKAN cycle.
>>>>>
>>>>> This will help paid members of the association justify the business
>>>>> case for investment in the project, whether it's in-kind or cash.
>>>>>
>>>>> The main idea I have for release management is to break apart the
>>>>> product definition from the product development and product support
>>>>> workloads. Then we can recruit different types of people with great skills
>>>>> into each area of effort. (No exclusions though. People can get involved in
>>>>> all areas if they wish)
>>>>>
>>>>> In addition, the product definition team would release EOIs to
>>>>> identify if there are funding sources that could then be used to accelerate
>>>>> development of features. A fund for feature X would then be market demand
>>>>> driven. The vendors listed as CKAN suppliers could then pitch to develop
>>>>> feature X as a paid project.
>>>>>
>>>>> Some conflict of interests need to be managed, but I figure that would
>>>>> be a great problem to have if we first had the funding created :)
>>>>>
>>>>> The C&C Team would have the job to promote roadmap features and
>>>>> attract funding.
>>>>>
>>>>> I think much of the technical release management would remain in the
>>>>> tech team as it has. They'd just have a deadline constraint for shipping.
>>>>> But, they potentially have a lot more support from other teams too.
>>>>>
>>>>> My own experience with 2.3 was that I really wanted to help, but for
>>>>> various reasons it was hard. A lot of my suggestions here are taken from
>>>>> that experience and thinking about ways companies like mine or initiatives
>>>>> people like me can support might more easily be leveraged to ship new
>>>>> features.
>>>>>
>>>>> I have zero criticism and all applause for everyone involved in the
>>>>> 2.3 release. In fact my deep gratitude is a debt I need to repay.
>>>>>
>>>>> #WeAreCKAN
>>>>> Steven
>>>>>
>>>>>
>>>>> On Monday, March 16, 2015, Claire Reis <Claire.Reis at umanitoba.ca>
>>>>> wrote:
>>>>>
>>>>>>  I think releasing 2.4 in September is a great idea as well.
>>>>>> Geospatial is also of interest to our group as we add more datasets and
>>>>>> upgrade our CKAN instance (http://130.179.67.140/).
>>>>>>
>>>>>>
>>>>>>
>>>>>> I’d also be interested to hear more about your plans for release
>>>>>> planning and management activities Steven.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Claire
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Ross Jones [mailto:ross at servercode.co.uk]
>>>>>> *Sent:* March 16, 2015 03:37
>>>>>> *To:* CKAN Development Discussions
>>>>>> *Subject:* Re: [ckan-dev] release date for 2.4
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Steven,
>>>>>>
>>>>>>
>>>>>>
>>>>>> That sounds great to me - what does everyone else think? It's be
>>>>>> great to get the community's opinion on whether that would be too soon,
>>>>>> just about right etc?
>>>>>>
>>>>>>
>>>>>>
>>>>>> My hope is that with more frequent releases the upgrade process would
>>>>>> be even simpler and we can share around the workload of managing the
>>>>>> release.
>>>>>>
>>>>>>
>>>>>>
>>>>>> We've had a couple of people express interest in Geospatial and
>>>>>> Workflow as things that could be prioritised - and I think, particularly
>>>>>> the workflow in particular might be a really good place to start.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>>
>>>>>>
>>>>>> Ross
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>  On 14 Mar 2015, at 03:39, Steven De Costa <
>>>>>> steven.decosta at linkdigital.com.au> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi folks,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Further to the comment from Ross about the roadmap and heading toward
>>>>>> a 2.4 release I discussed this with Rufus last night.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I'm keen for us to target 4 September as the release date and work
>>>>>> backwards from that as a hard deadline.
>>>>>>
>>>>>>
>>>>>>
>>>>>> What are the reactions to that date and suggested approach?
>>>>>>
>>>>>>
>>>>>>
>>>>>> I'm keen to pull more people into the dev work and would do whatever
>>>>>> I can to help. I say that also from my C&C Team and Steering Group
>>>>>> perspectives.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I also have a few ideas on how to support release planing and
>>>>>> management activities, largely from a non dev track, so that the dev folks
>>>>>> can be 100% on the code and coolness of CKAN.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Steven
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> *STEVEN DE COSTA *|
>>>>>> *EXECUTIVE DIRECTOR *www.linkdigital.com.au
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> ckan-dev mailing list
>>>>>> ckan-dev at lists.okfn.org
>>>>>> https://lists.okfn.org/mailman/listinfo/ckan-dev
>>>>>> Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *STEVEN DE COSTA *|
>>>>> *EXECUTIVE DIRECTOR*www.linkdigital.com.au
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> ckan-dev mailing list
>>>>> ckan-dev at lists.okfn.org
>>>>> https://lists.okfn.org/mailman/listinfo/ckan-dev
>>>>> Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>>>>>
>>>>>
>>>>
>>>
>>> --
>>> *STEVEN DE COSTA *|
>>> *EXECUTIVE DIRECTOR*www.linkdigital.com.au
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> ckan-dev mailing list
>>> ckan-dev at lists.okfn.org
>>> https://lists.okfn.org/mailman/listinfo/ckan-dev
>>> Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>>>
>>>
>>
>
> --
> *STEVEN DE COSTA *|
> *EXECUTIVE DIRECTOR*www.linkdigital.com.au
>
>
>
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20150318/0ee2c971/attachment-0003.html>