click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Malcolm Edgar <malcolm.ed...@gmail.com>
Subject Re: Click Release Strategy
Date Sat, 16 May 2009 09:15:13 GMT
Hi Adrian,

I would be happy to start working with you on your JIRA's items which
one would you like to start on?

regards Malcolm Edgar

On Tue, May 12, 2009 at 11:01 PM, Adrian A. <a.adrian.tech@gmail.com> wrote:
>> just have been
>> super super busy last week or so (wife just had a baby boy today, and
>> I am feeling rather chipper at the moment).
>
> Congratulations :) !
>
>>> What about the patches?
>>> Many JIRA issues have patches in them (form the community) but were not
>>> included.
>>> Should we send more, or should we give up :) ?
>>
>> The issue we currently have at the moment is time, its easy for the
>> few Click committers to be over whelmed with JIRA items.
>>
>> New JIRA feature requests are not necessarily easy to evaluate, as you
>> have to consider:
>> * 80/20 guideline, or is this new feature used commonly enough that it
>> should be included, or will it just bulk out the code base ?
>
> Yes, it should be included. The 80/20 is what drives every patch.
> If the rule does not apply, it makes no sense for me to loose time in making
> that patch in first place.
>
>> * will the change break backward compatibility, in programmatic
>> behaviour or rendering, or can it be accommodated as an new option ?
>
> Backward compatibility is always the requirement.
>
>> * is the feature simple and largom, is it a good fit for the framework?
>
> Yes, yes and yes.
>
>> Most new features also require an example demonstration in
>> click-examples, which is also used as a test harness, and
>> documentation. This often takes just as long or longer than writing
>> the code.
>
> I haven't supplied for most patches example code yet because at this
> moment this seems pointless: if you don't include the patches(so far none
> was) my effort is a loose of time anyway, so why should I loose twice as
> much time?
>
> Examples can always be quickly supplied after patches are included. Besides,
> it's not specific to Apache.org practice to include new features just 1 day
> before the release, so there's enough time to include example code(and
> review it) too before a release is done.
>
>> I think it would probably be more efficient to discuss the issues on
>> the dev forum and then raise a JIRA item once an approach starts to
>> come together.
>
> Most issues have my comments (or from other users) but many are not answered
> so far :(.
> That's why I asked here about the status one more time.
>
>> Bugs however are a different matter, they should just
>> go straight into JIRA, bugs are much easier to deal with as they are
>> generally pretty straight forward.
>
> Click is already quite complex (compared to the early versions I was used to
> - 0.xx),
> so it's quite improbable that you will get that many bug fix patches from
> the community.
> Also, there are few things that one could count as bugs, but because of
> "backward compatibility" they are considered "features".
>
>>>> I would like to get some feedback on this approach.
>>>
>>> For this time, I think it's OK to have this approach.
>>> After the release of 2.1.0, I think however that the Apache practice
>>> requires
>>> to support bug-fix releases too (e.g. 2.1.x).
>>> After 2.1.0, I think the 1.5.x can be abandoned, since the new fixing
>>> branch
>>> would be 2.1.x.
>>
>> Again 1.5.x wont be abandoned, as bugs  identified and fixed are they
>> will be ported to the respective Apache or SF version.
>
> I mentioned this because I saw that 1.5.x also got new features, not just
> bug fixing. I think this will create much more confusion that it tries to
> solve. Combined with the change in the online documentation strategy, the
> confusion will be even bigger IMHO.
>
> A.
>
>

Mime
View raw message