INFRA request filed: https://issues.apache.org/jira/browse/INFRA-6902
On Sat, Oct 19, 2013 at 3:36 PM, Brian LeRoux <b...@brian.io> wrote: > Discreet repos do have value for discreet issue tracking IMO even when you > use Jira. For example, feature branching is easier to reason about. > > /me shrugs > > One big repo to rule them all has created more problems than perceived > benifits in our past experience so maybe I'm just allergic. > > On Saturday, October 19, 2013, Michal Mocny wrote: > > > Anis, when we were first ripping out the plugins getting ready for 3.0 we > > didn't yet have support for plugins in git repo subdirs. I think we had > > that functionality by 3.0 launch but by then we have created a bunch of > > repos and momentum followed through. We *could* merge them all into a > > cordova-plugins repo, but I'm not sure that has value. We *could* > graduate > > plugins out of cordova-plugins into discrete repos, but I'm not sure that > > has value either. For end users, and for us devs, it really doesn't > > matter, so we should do whats most comfortable. > > > > Brian, at the moment we aren't using github for issue tracking anyway, so > > "discrete issue tracking" doesn't need to mean "discrete git repo". > Likely > > we do want to create a JIRA component for "graduated" plugins. The only > > benefit to moving to discrete repos I can think of is consistency, which > > may very well have value (esp for tooling support like coho). > > > > -Michal > > > > > > On Fri, Oct 18, 2013 at 6:57 PM, Brian LeRoux <b...@brian.io> wrote: > > > > > I think having a staging area for plugins is a good idea and leaving > > > cordova-labs as a prototyping area. Ideally we graduate plugins out of > > > cordova-plugins if they get any sort of traction at all and require > > > discreet issue tracking. > > > > > > > > > On Fri, Oct 18, 2013 at 1:31 PM, Anis KADRI <anis.ka...@gmail.com> > > wrote: > > > > > > > I am just curious. Why do that only for those plugins only and not > > > > every other plugins ? I know phonegap/phonegap-plugins was a bad idea > > > > but since git 1.7 there is [1]. I've never used it but just figured > it > > > > might apply to our case. I also think namespacing is a bad idea. > > > > > > > > [1] http://schacon.github.io/git/git-read-tree.html#_sparse_checkout > > > > > > > > On Fri, Oct 18, 2013 at 12:57 PM, Shazron <shaz...@gmail.com> wrote: > > > > > Great -- i *think* we have consensus, but I will wait until Monday > to > > > > move > > > > > forward just in case. Here's my updated proposal on what has been > > > > discussed > > > > > today: > > > > > > > > > > 1. Ask INFRA to create a cordova-plugins repo > > > > > 2. Move (with history) the cordova-labs plugins branch to the repo > in > > > (1) > > > > > 3. Create a CordovaPreferences plugin in (1) with a generic API > (and > > > > > predefined constants) -- iOS to start > > > > > > > > > > > > > > > On Fri, Oct 18, 2013 at 11:46 AM, Michal Mocny < > mmo...@chromium.org> > > > > wrote: > > > > > > > > > >> Sure we can debate the exact interface when it comes to it. Could > > use > > > > >> predefined constants instead of strings to help with > > > > >> typing/discoverability: > > > > >> > > > > >> navigator.cordovaPreferences.setPreference(win, fail, > > > > >> navigator.cordovaPreferences.PREFERENCE-iOS-GapBetweenPages, 0); > > > > >> > > > > >> > > > > >> On Fri, Oct 18, 2013 at 2:17 PM, Shazron <shaz...@gmail.com> > wrote: > > > > >> > > > > >> > Not feeling hot about the namespace thing - as Jesse said it > might > > > > limit > > > > >> > us. Ok - if we do a cordova-plugins repo it won't be hard to > move > > > the > > > > >> > plugins branch to it with a filter-branch option, preserving > > history > > > > -- > > > > >> > great. > > > > >> > > > > > >> > I think a generic preferences plugin is ok (wouldn't be hard to > > > > convert > > > > >> > the interface anyway for the existing code I have for iOS) with > > the > > > > usual > > > > >> > problems of user education/documentation for upgrades. Putting > in > > > the > > > > >> > preference name itself might be error prone (who's a great > speller > > > > >> here?), > > > > >> > but I would amend the pseudo code to actually have a > > failure/success > > > > >> > callback as well for these situations. > > > > >> > > > > > >> > navigator.cordovaPreferences.setPreference(win, fail, > > > > >> > 'iOS-GapBetweenPages",0); > > > > >> > navigator.cordovaPreferences.getPreference(win, fail, > > > > >> > 'iOS-GapBetweenPages"); > > > > >> > > > > > >> > On Fri, Oct 18, 2013 at 10:59 AM, Jesse < > purplecabb...@gmail.com> > > > > wrote: > > > > >> > > > > > >> > > If you namespace it to the platform, and later it makes sense > to > > > > >> support > > > > >> > it > > > > >> > > on another device, you will have even more issues. > > > > >> > > I think the best approach mentioned is the cordova-plugins > repo > > > > which > > > > >> is > > > > >> > > like the wild-west that is purplecabbage/phonegap-plugins > except > > > it > > > > i >
