From: Bertrand Delacretaz > Le Lundi, 1 d�c 2003, � 08:51 Europe/Zurich, Reinhard Poetz a �crit : > >> ...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.
Ok, I understand > > > 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=105343145413 > 887&w=2) > to enable this. I'll contact him > > - 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. So using the dependency function we can create following hierarchy: - CocoonFormsRoadmap - release 1.0 - multi-form support - calculated widgets - release 1.1 - tree widget Did you mean it this way? > > > - implementation ;-) > > Cannot help with this one ATM but it still looks important ;-) :-) -- Reinhard
