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. <[email protected]> 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. > >
