My impression as a user on this is that, since the very first few
prototypes with WKWebView from Shazron and some others, to later the Ionic
attempts at solving/masking the usual issues, to the current situation
where we have a deprecated UIWebView, is still the same as it was at the
start: using W
Agree with all 3 points by Jan.
@Chris Brody I think we should make use of Github Milestones to track
related issues.
On Wed, Aug 8, 2018 at 6:59 AM Jan Piotrowski wrote:
>
> Update to my initial email:
>
> I just noticed we actually _do_ have an issue template in use in the
> cordovs-docs reposi
Agree with Jesse -- this is more informational and fit for a blog post
since a lot of new devs will not know about fastlane
On Wed, Aug 8, 2018 at 6:33 AM Jesse wrote:
>
> track it in a blog post ;)
>
> Since we use cordova-docs repo for the blog, maybe an issue there would
> make the most sense.
We could whip something up using https://glitch.com for a start
On Wed, Aug 8, 2018 at 11:34 AM Shazron wrote:
>
> Thanks Jan!
>
> 1. Should we just disable those then? One other way is to add in bold
> big letters about the deprecation in the New Issue template
> 2. These links are super useful.
Thanks Jan!
1. Should we just disable those then? One other way is to add in bold
big letters about the deprecation in the New Issue template
2. These links are super useful. Perhaps they should be on the
website, what do you all think? Not sure if the scripting for the
second link is server side
Nightly build #813 for cordova has failed.
Please check failure details on build details page at
https://builds.apache.org/job/cordova-nightly/813/
You can also take a look at build console:
https://builds.apache.org/job/cordova-nightly/813/consoleFull
-
Jenkins for Apache Cordova
+1 on archiving deprecated repos, it's an easy way to make it very clear that
it is no longer maintained
On Wed, 8 Aug 2018, at 01:37, Chris Brody wrote:
> +1
> On Tue, Aug 7, 2018 at 11:32 AM julio cesar sanchez
> wrote:
> >
> > Archived repos are read only.
> >
> > People can still clone and/o
Update to my initial email:
I just noticed we actually _do_ have an issue template in use in the
cordovs-docs repository:
https://github.com/apache/cordova-docs/blob/master/.github/ISSUE_TEMPLATE.md
J
2018-08-07 23:18 GMT+02:00 julio cesar sanchez :
> I think us as committers should decide if th
track it in a blog post ;)
Since we use cordova-docs repo for the blog, maybe an issue there would
make the most sense.
(Disclosure: I am a contributor to PhoneGap and PhoneGap build)
@purplecabbage
risingj.com
On Tue, Aug 7, 2018 at 3:22 PM, Chris Brody wrote:
> Sounds good. Any suggestion
Sounds good. Any suggestions how to track this one before it gets forgotten?
On Tue, Aug 7, 2018 at 6:20 PM Jan Piotrowski wrote:
>
> Full agreement Jesse.
> (Although I generally think Cordova users would benefit from more
> links to useful tooling - but this should be discussed somewhere else)
>
Full agreement Jesse.
(Although I generally think Cordova users would benefit from more
links to useful tooling - but this should be discussed somewhere else)
Just for the record: fastlane is not a hosted service, but just
another tool you install locally.
Some CI providers offer it on their servi
Don't forget:
https://docs.microsoft.com/en-us/appcenter/
https://build.phonegap.com/
https://www.buddybuild.com/features/ci-cd-integrations
If they ask to be featured, then sure, lets, but I don't think we need to
be chasing them.
A simple cordova blog post explaining how to get cordova working w
I think us as committers should decide if the commits make sense to keep
all of them or squash them into one. But bug fixes should usually be only
one commit, and major refactors are not usually sent by non committers
El El mar, 7 ago 2018 a las 23:02, Chris Brody
escribió:
> > > I would favor a
Fastlane itself currently doesn't mention Cordova in its documentation
and setup creation at all - there are Github issues to change that -
so this probably would not be really appropriate as we ask for "tools"
etc to have _proper_ Cordova support and documentation how to use it.
But yes, I think
> > I would favor a place where a contributor can mark if s/he would
> > recommend the committer should *not* use the squash option.
>
> That of course could be defined in the contributor guidelines or PR
> template (although there it might be a bit confusing to new users that
> don't know what thi
Nice, especialy about ionic.zone/fastlane. Shouldn't we feature
fastlane on cordova.io?
On Tue, Aug 7, 2018 at 4:03 PM Jan Piotrowski wrote:
>
> What exactly do you mean by "integrate"?
>
> Apps built with Cordova (and Ionic) are pretty well supported by
> Fastlane, /platforms/ios|android are just
All very good points Chris.
>> > 3. Merge Conventions / Protected Branch:
> Nice idea. The one exception is that committers sometimes have to tag
> and push individual commits when making releases.
We will definitely have to check how this works with current workflows
defined in coho and in othe
What exactly do you mean by "integrate"?
Apps built with Cordova (and Ionic) are pretty well supported by
Fastlane, /platforms/ios|android are just native projects after all -
even though you have to take some extra measures to handle the
generated projects. I wrote some articles about how can wor
> > It might be good to require a checkbox for developers certificate of
> > origin (developercertificate.org) like at:
> > https://github.com/papercss/papercss/blob/master/.github/PULL_REQUEST_TEMPLATE.md
>
> If we were going to require something like this, I think we would have
> to go back to th
On Tue, Aug 7, 2018 at 12:36 PM Chris Brody wrote:
>
> > I would suggest we use something similar to this, which explicitly
> > asks for running the tests and writing documentation:
> > https://github.com/fastlane/fastlane/blob/master/.github/PULL_REQUEST_TEMPLATE.md
> >
> > What do you think rega
Should we explore this idea for Android & iOS?
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
> 1. Issue template:
> [...]
> I think we should definitely use this for Bug Report, Feature Request,
> Support Question. What sections should we suggest in our templates?
All suggestions look good, should probably give proper attribution.
> 2. Pull Request template:
>
> I think we can drop the J
Thanks all, but handling the migration of JIRA issues to Github is
not really the topic of this discussion.
Either use the other "[DISCUSS] [JIRA -> GitHub Issues] The way
forward" thread where I had defined this as "d) Define and execute
issue migration from JIRA to GitHub" or create a new thread.
I wouldn't do 2, most people won't create a new issue, but that doesn't
mean the issue doesn't exist.
Anyway, I think there is another thread about the migration, this is for
the templates.
El mar., 7 ago. 2018 a las 19:04, Chris Brody ()
escribió:
> Options I can think of:
>
> 1: make and use
Options I can think of:
1: make and use an auto-migration script
2: use quick filters to close issues in bulk with a message that the
OP should manually raise on GitHub if so desired
3: continue with JIRA issues for a while
I would vote for the easiest way possible to end use of JIRA issues
(prob
Hi Jan,
I like your suggestions. But curious to understand how to take care of
existing issues which are currently available in JIRA? Should it be ported
to respective git repos or will continue to remain as is till it's closed?
On Tuesday, August 7, 2018, Jan Piotrowski wrote:
> Now that Githu
+1
On Tue, Aug 7, 2018 at 11:32 AM julio cesar sanchez
wrote:
>
> Archived repos are read only.
>
> People can still clone and/or fork them, they just can't send PRs or create
> new issues.
>
> I'm +1 on archiving them.
>
>
>
> El mar., 7 ago. 2018 a las 17:25, escribió:
>
> > I suggest archiving
Archived repos are read only.
People can still clone and/or fork them, they just can't send PRs or create
new issues.
I'm +1 on archiving them.
El mar., 7 ago. 2018 a las 17:25, escribió:
> I suggest archiving them all and deal with any issues as they appear. After
> all, repos can be unarch
I suggest archiving them all and deal with any issues as they appear. After
all, repos can be unarchived if necessary.
Chris Brody schrieb am Di., 7. Aug. 2018, 17:16:
> Continuation of discussion from
>
> https://lists.apache.org/thread.html/affbc74f0ff4d34bc09657c3c302e185cc98b946d260184847fdf
What is the current (probably unwritten) rule regarding deprecation
and archival of Cordova repositories?
-J
2018-08-07 17:16 GMT+02:00 Chris Brody :
> Continuation of discussion from
> https://lists.apache.org/thread.html/affbc74f0ff4d34bc09657c3c302e185cc98b946d260184847fdf191@%3Cdev.cordova.ap
Now that Github Issues are enabled on all repositories, it makes sense
to create a (or several) new Issue and PR template(s) that doesn't
point to JIRA any more and also uses the current state of the art.
Current Cordova issue and PR template:
- no issue template
-
https://github.com/apache/cordo
Continuation of discussion from
https://lists.apache.org/thread.html/affbc74f0ff4d34bc09657c3c302e185cc98b946d260184847fdf191@%3Cdev.cordova.apache.org%3E
I think it is not desired to actively support deprecated repos. I
think the easiest solution is to simply make those repos archived.
But what
Please open a new discussion re the archiving/deprecation topic - this
is a very different thing.
Sure, feel free to transfer the links to a Github Wiki or whatever -
as I wanted to generate the links automatically I had to use a
scripting language.
2018-08-07 17:07 GMT+02:00 Chris Brody :
> I wo
I would favor archiving the deprecated repos asap so we don't have to
deal with traffic on those anymore.
Thanks for making the nice GitHub filter and group repo links. I would
really favor using a wiki, which is supported by GitHub, for this kind
of thing for the sake of easy writing & editing.
You may have noticed the first issues coming in on some repositories.
1. In hindsight enabling issues for deprecated platforms, plugins etc
may not have been the smartest decision. We will have to find out how
to handle this - we should probably write down a "deprecation /
archivation policy" anyw
Thanks Gandhi. Can I get one more review on this one?
On Mon, Aug 6, 2018 at 11:28 PM gandhi rajan wrote:
>
> +1
>
> On Tuesday, July 31, 2018, Chris Brody wrote:
>
> > Please review and vote on this cordova-browser@5.0.4 patch release by
> > replying to this email (and keep discussion on the DIS
36 matches
Mail list logo
