On Apr 29, 2014, at 4:19 PM, Danushka Menikkumbura <[email protected]> wrote:
> Having different repos will only help if we are planning to have independent > release cycles.Does it make sense (or it is required ) to release the g/w > separately? I am unable to guess if we will need separate release cycles or not. Since web interfaces can take more development iterations then changes to clients and server packages, I guess we might have the need. Other thoughts? Lets draw this to a conclusion? I seeing mostly + 0 -0 kind of opinions. Any strong preferences or should we just roll the dice and go with one option for now? Suresh > > /Danushka > > On Wednesday, April 30, 2014, Suresh Marru <[email protected]> wrote: > > On Apr 29, 2014, at 2:53 PM, Sachith Withana <[email protected]> wrote: > > > >> Suresh, > >> > >> Agree with your points. > >> > >> Consider the PHP gateway. It’s being developed right now. When it’s a full > >> blown gateway, some users would use it directly as their gateway. If they > >> want some new features to be added, they can do that and they will be able > >> to commit it to the main repo, so that other users can use those features > >> too. > >> > >> Basically, I’m just pointing out that the PHP gateway has the potential to > >> become a project of its own, with its own contributors, as a framework for > >> new gateways. > > > > Hi Sachith, > > > > This is a good goal. When such success story happen, we still encourage the > > PHP Reference Gateway bundled within Airavata to have an example to refer > > to. The cloned version of success project can potentially build its own > > community in github or elsewhere. A challenge for airavata should be to > > motivate the community to contribute back generic examples which will > > benefit other users and help maintain the reference implementation. > > > > Suresh > > > >> > >> > >> > >> On Apr 29, 2014, at 11:46 AM, Suresh Marru <[email protected]> wrote: > >> > >>> Just to clarify, to commit to any repo on ASF infrastructure a > >>> committtership will be a pre-requisite. But as a PMC we can granularly > >>> control any of our repos. > >>> > >>> To answer the question, I personally do not see any need to control > >>> access among committters. I agree this need if we are opening up to > >>> contributors (which I do not think is legally complaint). > >>> > >>> Just FYI, subversion project allows any ASF committer to have write > >>> access to their repos, they believe in social trust rather then ACL’s, I > >>> like this boldness it makes us feel welcome. Ofcouse, I doubt any one > >>> will commit without a consent on the mailing list, but thats the point. > >>> > >>> Suresh > >>> > >>> On Apr 29, 2014, at 12:52 PM, Marlon Pierce <[email protected]> wrote: > >>> > >>>> Would we want to have the option to restrict committership to a specific > >>>> repo? > >>>> > >>>> Marlon > >>>> > >>>> On 4/29/14 12:32 PM, Suresh Marru wrote: > >>>>> For reference, please see what other projects are doing - > >>>>> https://git-wip-us.apache.org/repos/asf > >>>>> > >>>>> Projects like cloudstack, cordova, couchdb jclouds and others pretty > >>>>> much add a new repo for lots of components. Other projects choose to > >>>>> have one repo for everything. > >>>>> > >>>>> I am not yet weighing one option over other and soliciting everyone’s > >>>>> input. > >>>>> > >>>>> Suresh > >>>>> > >>>>> On Apr 29, 2014, at 12:27 PM, Suresh Marru <[email protected]> wrote: > >>>>> > >>>>>> Hi All, > >>>>>> > >>>>>> Since the transition to git was uneventful and seems to work well, I > >>>>>> want to resurrect the discussion of a code repos. > >>>>>> > >>>>>> To demonstrate Airavata we will need reference implementations of API. > >>>>>> Previous web implementations are all over the place. Can we discuss > >>>>>> what is the good place to consolidate these examples and indeed > >>>>>> release them periodically? > >>>>>> > >>>>>> Two options to consider: > >>>>>> > >>>>>> * Have these web implementations as a module within main trunk and > >>>>>> release them along with Airavata. > >>>>>> * Create a separate repo and have a separate release cycle. > >>>>>> > >>>>>> Any opinions? > >>>>>> > >>>>>> Suresh > >>>>>> > >>>> > >>> > >> > > > >
