release 1.0.0 soon? when? how? discuss.

[PhyrePhoX]

as y'all already noticed, CHDK has matured quite a bit since it was started, like 2 years ago.
i think it's time we try to implement some kind of milestones in the development of chdk. up to now, the version number of chdk was not fixed to something, it was changed on the go, whenever we saw fit.
 
so i tried to make up the next milestone that will mark 1.0.0 (since this is just my personal opinion and not the one of the dev team, this is subject to discuss, not only with the devs, but also with you, the user. btw this post here is not only written from my dev point of view, but also from a user pov)

- fix all bugs (platform dependent and platform independent) that are currently in the system (bugtracker preferred). this might be difficult, as a lot of bugs seem to derive from bad ports and can only be fixed via asm magic by magicians like ewavr and reyalp
- do more or less a feature-freeze (this will be very hard, and most certainly not doable, as for example people like me cannot fix some bugs (asm) but dont want to sit around doing nothing
- a few things should definitly be in chdk before going 1.0.0:
* energy saving stuff -> control of the lcd
* virtual keyboard -> very important for future features
* imo detection of currently displayed item in playback (avi or jpg, name of item, state of item like is it a playing video, a paused or stopped one, a zoomed in jpg etc) -> important for future features
- imo the *.fi2 format has to be decoded (and of course encoded) so the dryos folks can benefit from that (update)
- the documents in the autobuild and the wiki need a rewrite (works has been done already)
- a good "starter kit" of ubasic and lua scripts in the autobuild
- speaking of ubasic and lua - perhaps we should decide to at least have an OPT_UBASIC to free a lot of precious binary space
- we need to discuss a better form of releasing the binaries. the autobuild is GREAT, but it is more or less to be considered a source of beta- and untested code. so along with the autobuild, we should start releasing "normal releases" again, not only as a fallback in case the autobuild or the trunk is broken, but also as some kind of "public manifestation".

i will soon revive the threads about the specific features again, so people can start working on these again

what do you think? i forgot a lot i guess, but thats what you are here for

[fe50]

...fe50's thoughts:


- yes, we should have 'stable' versions

- fi2: would be nice, but imo we don't need it really, we can also have this in v2 or v3...

- documents / txt files in the builds: i don't know whether they are really helpful, imo we should concentrate the 'docu forces' to the wikia, there we can also have PDF's for offline reading in store easily (e.g. like we already have it with the german guide.

Maybe having a development branch (and maybe an additional experimental branch) again could be a way ?

The download pages have much traffic, must be paid (BIG THX to our 'mighty-hoernsche' !)...maybe we can host 'stable' versions (changing all ~ 2 or 3 months) on a 'free' hoster, maybe on a drop...www.drop.io - 100MB should be enough...

...so my aggregation: yes, stable version, maybe 'CHDK 1.0', not waiting too long anymore since we never will have 'really' stable versions (='bugfree', fully functional & with all features)...we should serve & eat what we have !

[PhyrePhoX]

well, fi2 would greatly increase usability for people who just "want to test this" and dont want to go through the hassle of making their cards bootable (they will do so later, once they see the genius of CHDK )

i do think the files in the autobuild are helpful, after all you cannot read a pdf on your computer back home when you are in the middle of nowhere also it is something you have in one single zipfile, no need to look for pdfs. ofcourse there should be the in-depth pdf guides, but the documents in the autobuild should a) be up to date b) do not contain false data and c) be short and helpful

hm, development branch? i think it should be enough (svn-)tagging special releases every once in a while and auto-export these to somewhere. perhaps hacki can devise a way. having fallback binaries automatically saved somewhere is the reason we imo dont need a special test branch anymore. perhaps we can offer additional binaries, for example ones with all the optional build.conf stuff disabled? anyhows, having releases requires that we release them to the public somehow, complete with an enhanced changelog etc. technically, the last official release of chdk is allbest 50 if i remember correctly
according to hacki, we can host releases on his server as well (it also has a fallback version hosted already, in case someone from the devs messes with the code so the buildprocess fails, it will automatically show up on the page, but the updating of that fallback binaries isnt automated yet).
i'm happy the bugtracker is coming along niceley, at first i thought it wouldnt be used (and it is so much better than the crippled assembla trac ticket system)

[reyalp]

Agree, we should have a release, and should put effort into stability and usability before we release it.

After feature freeze, new features should go in a different branch (I'd suggest making a branch for the release candidate, rather than branching the dev version and then merging it back to the trunk in the future.)  Bug fixes should go in both where applicable. Based on past experience, we probably want to minimize the amount of time both are getting a lot of use.

Fixing all bugs is probably a tall order. We should set up mantis so we can target bugs for a particular release.

Having full documentation on the wiki is important. Other documentation can be derived from that.

[databoy]

I know that CHDK is a open source hobby project. Like a lot of projects which start out small; re-writing the documentation on the CHDK Wiki is a huge task. I think that the developer's and contributor's should approach O'Reilly Media O'Reilly Media: About O'Reilly about having the CHDK Wiki published into a book. A book title like "CHDK for Dummies - Hacking Canon Cameras and Other Photographic Mysteries" seems to be appropriate.

The advantages of having a commercial publisher is that funds generated could be used to pay for the forum hosting and the purchase of other Canon cameras. Also there are many people who own Canon cameras who do not know of CHDK or may be apprehensive about loading CHDK on thier cameras because it is technically to  difficult for them. Those people would be receptive to following a guide in a book. The book could also contain fundamental photographic information to explain all the functions of CHDK. Approaching Canon for official support may also farther the cause. From purely a marketing perspective Canon have an advantage over their competitors. Obtaining permission to use copyright material and camera images or quote from copyright material may assist in "cleaning up" documentation.     

I am aware that for some of the developers, English is not their primary language. The guides could be written in their native language and translated into English. This would also accommodate non-English Forum contributions.    

[reyalp]

This thread is about planning a release. Book publishing is OT.

[databoy]

Software programmers are good at writing software. Technical writers are good at writing documentation. The point I am making is that everyone has different and specialised skills. The CHDK software and documentation has grown too big for a small group of dedicated volunteers to handle. Why not use the skills of technical writers for the benefit of the CHDK project.

[fe50]

IMHO
CHDK is a specialized environment for a small group of technically oriented people.
CHDK should not go any kind of 'commercial' way, elsewise one day Canon won't or even can't suffer CHDK anymore...although many people think Canon won't proceed against CHDK, i'm sure they'll react, and that in a way we would not like.

About the documentation & the wikia:
Everybody can write that kind of 'book' in the wikia, publishing is not a big deal, you can have a professional PDF 'book' in some minutes.

But: the experience has shown that there are many people just talking much about the documentation and how it could be - but only a few of them are really there and contribute their time...
E.g. in the german forum we have ~ 1307 users, we have an always up-to-date, detailed manual in the wikia - and less than a dozen of active people...that's also a side of the medal

[reyalp]

I've added some versions to the mantis tracker:
1.0.0 - planned release.
1.1.0 - Dummy for post 1.0 stuff.

I've set the dates to March 2009 and Jan 2010 respectively. These are not real dates. They are arbitrary values picked to 1) put them both in the future 2) put them in the correct order. We can adjust them as needed when things become clearer.

In the "advanced" view for creating/updating bugs, you can set a target version. If we do this for the outstanding bugs, they will go in the roadmap, and help us keep track of which things should be fixed for release.

I'm not a mantis guru by any means, so if I've done this wrong, please feel free to slap me around.

edit:
You can also mutli-select in the main view, and then select update target version at the bottom to do bulk changes.

edit #2:
Maybe we should have a 0.9.1 (or .0) version, marked as released for the old, closed bugs ?

[PhyrePhoX]

nice

but your last statement: you want to flag already closed tickets? go ahead, i do not object - but: why?

[mattkime]

when i first saw the thread title, i thought "1.0.0 release - whats the point??" 1.0 isn't as important as it used to be.

but then i saw the feature list and thought "yes, i want 1.0!"

from what i've experienced with chdk, the biggest obstacle to providing a stable chdk is testing the software across all cameras. i think it would be extremely helpful to test each and every chdk feature across all cameras. yes, that is very difficult. however, if we make it easy for individuals to contribute then its not so bad. the solution to this is a database which cross references features, chdk revisions, and user results. i'm curious if there is an "off the shelf" solution to this because creating your own database driven web solution would be quite time consuming.

i'm not sure if thats useful feedback for the 1.0 discussion but its something i'd like to see chdk gain.

thanks!

[mariush]

...fe50's thoughts:



The download pages have much traffic, must be paid (BIG THX to our 'mighty-hoernsche' !)...maybe we can host 'stable' versions (changing all ~ 2 or 3 months) on a 'free' hoster, maybe on a drop...www.drop.io - 100MB should be enough...

If you'll ever need a mirror for the stuff or somewhere to host the files, I have a dedicated server and I can donate bandwidth.

It would look more serious compared to zshare or other free sites.

[SHOCKproof]

I'm a CG artist. I'd like to contribute to CHDK. Is there any way I can help?

[Vlaaaad]

I`m sorry for writing here, but could it be face detection in final version of the script?