...CocoonForms = need to to define a Component called CocoonForms for the "Cocoon 2" product in bugzilla.
What do we need this for?
Defining a "Cocoon Forms" component of Cocoon allows you to mark issues as being specific to Cocoon Forms.
If all enhancement requests are marked as such we simply don't include them and also don't include all bugs with "[Patch]" in their summary and we get a list of all open bugs.
Yes, but if you're only interested in Cocoon Forms stuff you need another query parameter, hence the need for a new Component definition in bugzilla.
See http://wiki.cocoondev.org/Wiki.jsp?page=HowWeUseBugzilla - I added a query section
cool
...Looks good, exactly what I needed. So IIUC we have to:
- get access to the "edit products" function or at least set up a standard (organizational) procedure how we have it done (e.g. email the right person at Apache infrastructure)
Yes, preferably get access to "edit products".
Pier seems to have the necessary bugzilla rights (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105343145413887&w=2) to enable this.
- create CocoonForms component --> altough I don't know what we need this for ...
see above
- make it possible to have more than 6 votes
- move all entries from Wiki to Bugzilla
Yes, and keep the wiki page for general info about the roadmap
- give our users and committers some time to vote
- discuss on [EMAIL PROTECTED] the voting results and set up the roadmap
Sounds good
--> how can we activate the "target milestone"? That's exactly what we would need!
hmm...never used it, and I'm not sure if milestones can be defined at the product level.
OTOH a milestone ("release 2.2") could be another bugzilla entry which depends on the Cocoon Forms Roadmap entry, this would also give a good overview. Actually that would be my preferred way of doing it, the multi-level dependency tree is then very informative.
- implementation ;-)
Cannot help with this one ATM but it still looks important ;-)
-Bertrand
