airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Marru <sma...@apache.org>
Subject Re: SVN repo for GSOC projects
Date Fri, 28 Jun 2013 19:29:28 GMT
Hi Danushka,

Anything you patch to the trunk, I would suggest to directly to contribute to the trunk itself.
Since we all are in active development phase, you should get enough screams is something breaks.


The new gsoc sandbox I suggested is for components which are not currently in trunk, like
the new web components. Towards the end of gsoc, we need to merge the sandbox also with main
code base. If your contributions naturally belong to main code base, start sending patches.


Other way to look at this is:

* if you are in a exploratory phase, you certainly want to keep that code in gsoc-sandbox.
* if you have a well-tested piece which does not break the builds, it can directly go to trunk.

Suresh

On Jun 28, 2013, at 3:17 PM, Danushka Menikkumbura <danushka.menikkumbura@gmail.com>
wrote:

> Hi Suresh,
> 
> We have discussed about the layout on this thread but not sure if we have
> deviated (naturally) from it while working.
> 
> I wonder if we should clone the trunk and submit patches against it? I mean
> gsoc2013 branch or something?.
> 
> Thanks,
> Danushka
> 
> 
> On Sat, Jun 29, 2013 at 12:27 AM, Suresh Marru <smarru@apache.org> wrote:
> 
>> Hi All,
>> 
>> Very nice to see all of you so actively sharing information. I think the
>> we are only missing code reviews others you all are doing great.
>> 
>> Can we agree upon these suggested repo structure? Can any one please post
>> the final agreed layout? I will create the repo and you guys can create
>> JIRA's and start submitting patches.
>> 
>> An important aspect of GSoC is to learn about open source contributions
>> and the apache way is to do it through patches and review board code
>> reviews. Few of you already have lot of experience with it, it will be
>> great to others to follow suite.
>> 
>> Suresh
>> 
>> On Jun 25, 2013, at 3:48 PM, Subho Banerjee <subs.zero@gmail.com> wrote:
>> 
>>> @Viknes: Yup... thats what my plan is. AngularJS - Bootstrap - jsPlumb. I
>>> am currently implementing the AngularJS Models for the Workflow
>> composition
>>> process.
>>> 
>>> @Dhanushka: Any third party JS library goes into the vendor folder (thats
>>> what the HTML boilerplate people say).
>>> The deployment structure is a bit different, currently I am looking at
>>> Grunt to do the minification of CSS and JS as well as compile
>> SASS/Compass
>>> that comes from the Bootstrap project. This will be integrated into the
>>> Maven build to produce (versions of)  the webapp that is optimized for
>>> browsers and screen sizes, we can probably enable the server to serve
>>> different versions depending on the source of the request.
>>> 
>>> 
>>> On Tue, Jun 25, 2013 at 11:08 PM, Viknes Balasubramanee <viknesb@msn.com
>>> wrote:
>>> 
>>>> +1 for the Boilerplate structure.
>>>> 
>>>> Speaking of sharing JS libraries, I think AngularJS[1] would be a
>> perfect
>>>> fit as you can define services and modules and share them between
>> different
>>>> webapps easily.
>>>> It has a sharp learning curve, but once you get used to it, it should be
>>>> fun to code with.
>>>> 
>>>> Also I suggest we use Twitter Bootstrap[2] for the look and feel.
>>>> 
>>>> [1] http://www.angularjs.org/
>>>> [2] http://twitter.github.io/bootstrap/index.html
>>>> 
>>>> Thanks
>>>> Viknes
>>>> 
>>>> -----Original Message-----
>>>> From: Sanchit Aggarwal [mailto:sanchitagarwal108@gmail.com]
>>>> Sent: Tuesday, June 25, 2013 10:55 AM
>>>> To: dev@airavata.apache.org
>>>> Subject: Re: SVN repo for GSOC projects
>>>> 
>>>> +1
>>>> 
>>>> Danushka ,
>>>> we can have a utilities folder under the JS folder itself and from there
>>>> the shared JS libraries can be used.
>>>> 
>>>> Regards
>>>> Sanchit Aggarwal
>>>> MS Research (Computer Science)
>>>> Center for Visual Information Technology IIIT Hyderabad, Gachibowli
>>>> Contact - 9581417330
>>>> 
>>>> 
>>>> 
>>>> On Tue, Jun 25, 2013 at 11:49 AM, Danushka Menikkumbura <
>>>> danushka.menikkumbura@gmail.com> wrote:
>>>> 
>>>>> Maybe it is a deployment model is it?
>>>>> 
>>>>> 
>>>>> On Tue, Jun 25, 2013 at 11:46 AM, Danushka Menikkumbura <
>>>>> danushka.menikkumbura@gmail.com> wrote:
>>>>> 
>>>>>> +1.
>>>>>> 
>>>>>> How would you use shared JS libraries in this boilerplate BTW?.
>>>>>> 
>>>>>> Cheers,
>>>>>> Danushka
>>>>>> 
>>>>>> 
>>>>>> On Tue, Jun 25, 2013 at 11:36 AM, Subho Banerjee
>>>>>> <subs.zero@gmail.com
>>>>>> wrote:
>>>>>> 
>>>>>>> I would like to suggest a slightly different layout. Particularly
>>>>> because
>>>>>>> the logic for the UI for Workflow composition and Workflow
>>>>>>> composition itself in HTML are not seperate. Also, I am following
>>>>>>> the HTML5 Boilerplate to structure my front end code[1], so this
>>>>>>> means that code which I write for the workflow composition UI
is
>>>>>>> structured as follows -
>>>>>>> 
>>>>>>> /:.
>>>>>>> ├───index.html
>>>>>>> ├───css
>>>>>>>   └───vendor
>>>>>>> ├───doc
>>>>>>> ├───img
>>>>>>> └───js
>>>>>>>   ├───vendor
>>>>>>>   ├───model
>>>>>>>   └───controlers
>>>>>>> 
>>>>>>> Now, the js folder contains all the front end logic for the UI
as
>>>>>>> well
>>>>> as
>>>>>>> workflow composition. I would suggest that we follow this structure
>>>>>>> and not further subdivide the web UI module. In which case, we
can
>>>>>>> reuse objects in between the various web-ui sub-projects.
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> Subho.
>>>>>>> 
>>>>>>> 
>>>>>>> [1] http://html5boilerplate.com/
>>>>>>> 
>>>>>>> 
>>>>>>> On Mon, Jun 24, 2013 at 11:47 PM, Danushka Menikkumbura <
>>>>>>> danushka.menikkumbura@gmail.com> wrote:
>>>>>>> 
>>>>>>>> Hi Suresh,
>>>>>>>> 
>>>>>>>> I think we need to have the following structure.
>>>>>>>> 
>>>>>>>> 1. web-gui (xbaya-web-ui?) - The Web UI would be a top-level
>>>>>>>> module,
>>>>>>> under
>>>>>>>> which we may have the following sub modules.
>>>>>>>> 
>>>>>>>> - ui (Widgets, graph, canvases, etc)
>>>>>>>> - workflow (Workflow composition, execution)
>>>>>>>> - monitor (Workflow monitoring)
>>>>>>>> - protocol (XML/JSON protocol conversion module)
>>>>>>>> 
>>>>>>>> 2. ws-messenger.client.protocol.amqp - AMQP client API bits
>>>>>>>> 
>>>>>>>> 3. xbaya-gui.ui - AMQP configuration + monitoring.
>>>>>>>> 
>>>>>>>> Sanchit, Shameera, Subho, Vijayendra and Viknes, what do
you think?.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Danushka
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Sun, Jun 23, 2013 at 6:16 PM, Suresh Marru <smarru@apache.org>
>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Hi All,
>>>>>>>>> 
>>>>>>>>> Please discuss how should we structure the SVN repo for
gsoc
>>>>> projects?
>>>>>>>>> certainly not by student since every one is contributing
to
>>>>>>>>> master
>>>>>>>> project.
>>>>>>>>> So may be the functional components?
>>>>>>>>> 
>>>>>>>>> I created a sandbox area, please discuss how individual
modules
>>>>>>> should be
>>>>>>>>> organized and please create JIRA's and submit patches
to this
>>>> repo.
>>>>>>>>> 
>>>>>>>>> https://svn.apache.org/repos/asf/airavata/sandbox/gsoc2013
>>>>>>>>> 
>>>>>>>>> Suresh
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 
>> 


Mime
View raw message