On Wed, Dec 12, 2012 at 3:13 PM, Pranav Saxena <pranav.sax...@citrix.com> wrote: > Chip , > > Perhaps you missed the earlier conversation happened in the mailing thread > earlier . Attaching the thread here.
Thanks... I didn't miss it, because this is the same thread. But I do appreciate you re-sharing the content in case I did miss it. ;-) > [Chip] Is this actually under development right now? If so, where is the > code? Who's working on it? How can others in the community participate? > Where is the technical design discussion happening? Do we have Jira records > for tracking the dev work? Where is the discussion about QA'ing the software > happening? > > [Pranav] - Yes , the basic implementation has just started and myself and > Brian Federle are working on the backend design . The idea is to have the > very basic model up and working and then push the working model to the asf > branch so that if anyone's willing to contribute can do so without any > problems. When I say "basic model" , I am referring to the front end > development for the marketplace within the CloudStack UI and the backend > hierarchy for the directory structure . We had a discussion with Jie and > we'll be updating Jie's proposal with the technical design as soon as > possible and sharing it with the community. The basic structure of the > backend design is already there in the proposal Jie has shared. > I would suggest that committers in particular use feature branches within the asf repo. I assume that the term "asf branch" you use above is because you guys have your local git repo configured with multiple remotes. That's perfectly fine, but shouldn't you be coordinating code collaboration through the project repo? > [Chip] - There is mention of static configuration files being used to store > the product listings, and storing them as part of the CloudStack source code > repository. This doesn't make any sense to me on a number of fronts. Why > would a product catalog be embedded in the source code of the store front? > Wouldn't a better design be to allow *whomever* is hosting this software to > use runtime config changes to create and manage their product listings? > > [Pranav] - The static configuration files which you are referring to are not > actually static . The listing of the name of the application a vendor is > willing to host in that file might make you feel that it's static in nature > but it's dynamic in a sense that the config file is being used for listing > will be remotely accessed by the script tags (require.js) .The script tags > would dynamically pick up the appID during the runtime and load the content > which a vendor has provided ( in his application specific config file) in > order to display it on the detail view for his application on the Cloudstack > marketplace . I think this needs to be spelled out, or the example code pushed to the repo. As I said in my reply to Jie, I think we will end up with the design causing project process issues. I may be wrong though... please do help us all understand it better! > Hope I managed to answer few of your queries here . Regarding the QAing , I > am not sure how is that supposed to work. For any further clarifications , we > can have a detailed discussion on the backend design. If you suggest , we > could also push the basic working model right now (say in a private asf > branch ) for the community to review it and propose changes , if any. > Not sure what you mean by a "private asf branch", but I think you might mean a "feature branch" in the project's git repo. Correct? Can you create a feature branch and push each of your changes as each of you make significant ones? We had previously agreed as a community that larger development, particularly done by committers, would be done in feature branches that are public. Does this work for you guys? > @Brian - Do you have anything to add here ? > > Regards, > Pranav >
