Auto-correction sorry!
Anyways, I also agree with *Shazron's* point of view on this and will also
> go with the consensus.
On Fri, Aug 24, 2018 at 12:06 PM Bryan Ellis wrote:
> Personally, I am also in favor for the issue bankruptcy.
>
>
> I use the LIFO method more when deciding tickets; so
Personally, I am also in favor for the issue bankruptcy.
I use the LIFO method more when deciding tickets; so looking at JIRA might
become less over time as GH issues grow.
I know that there can be relevant tickets, but someone will have to spend
time determining that.
-
Sort out
Nightly build #829 for cordova has failed.
Please check failure details on build details page at
https://builds.apache.org/job/cordova-nightly/829/
You can also take a look at build console:
https://builds.apache.org/job/cordova-nightly/829/consoleFull
-
Jenkins for Apache Cordova
I think we have to take a look at whether we actually *will* look at
GH Issues *and* JIRA. This assumes that us, with limited time and
resources will actually do it.
I don't think I will, tbh. The issues are not lost, they are still in
JIRA for reference when the user wants to take it up again.
Here is the PR on GitHub templates, our usage of them and actual
drafts for all templates:
https://github.com/apache/cordova-contribute/pull/3
Please keep all further discussion on the issue and pull request
template in this Pull Request. Thank you.
Am Di., 21. Aug. 2018 um 20:21 Uhr schrieb :
>
As Shazron said and as I pointed out once before, Apache can enable apps such
as Probot, which works nicely for more then just moving issues.
I pointed this feature link before.
https://probot.github.io/apps/move/
I think Probot will fit our needs better then the other as it provides more
I've just found cordova-plugin-media was voted to be "sunset", but we
didn't do it (https://issues.apache.org/jira/browse/CB-13095), so might be
a good start.
I think it's the only one left, and cordova-plugin-dialogs didn't get a
definite decision.
I wouldn't deprecate more, as biggest struggle
Realistically, if they created an issue more than 6 months ago and nobody
looked at it in that time, they wouldn't bother to recreate. So we would
lose ~1700 issues.
I agree with Raphael, if options are bulk close and ask for migration or
keep them open, I vote for keeping them open.
If somebody
I'm against migrating everything. I would just leave them in JIRA as is and
resolve them when resolved.
Regarding the "dangling" issues: If we re-file issues in GitHub, we would
have to make sure that the corresponding issue in JIRA is properly marked
as obsolete.
In other words, I as a
Back of the napkin calculation... if we took 5 mins (which is quite
conservative) to migrate one by one, 1,811*5 = 9,055 minutes (or ~19
days of 8 hours a day full time). That's about a month of work for one
person (not including weekends), but realistically it will be greater
than this of course,
Realistically doing it one by one will take a very long time, nor is
it necessary -- as a volunteer or if you were paid by your employer.
Some of these issues might be not relevant anymore. If it was
relevant, they can re-file in GH. I really don't want this to drag out
for another year.
In my
Yes, I was talking about that. I only see a big "Authorize Github" button
there. Will try it when I find time. Thanks for testing.
Am Do., 23. Aug. 2018 um 11:13 Uhr schrieb Jan Piotrowski <
piotrow...@gmail.com>:
> > How do we get apps unlocked for organization access?
> > Just request access
I wouldn't do a bulk close neither, I think we should migrate them one by
one to the respective github repo, even using same JIRA id so they still
get linked, and then manually close as duplicate of the new github one.
It's going to be a lot of work, but we don't need to do it right away, we
can
I thought JIRA was locked anyway. So only PMC Members can make changes.
If we just leave them as is, I can simply resolve an issue I fix in JIRA
and all is obvious.
If we ask people to reopen in GitHub, we will have a dangling seemingly
unresolved duplicate in JIRA,
so JIRA becomes less useful
Seems apache/cordova is misconfiged, I created an INFRA issue to
change the notification email from dev@ to commits@:
https://issues.apache.org/jira/browse/INFRA-16945
Am Do., 23. Aug. 2018 um 11:11 Uhr schrieb GitBox :
>
> janpio opened a new issue #2: TEst
> URL:
> How do we get apps unlocked for organization access?
> Just request access using the GitHub dialog that pops up, or doe we have to
> file INFRA tickets?
I don't think anyone has tried that before.
If the question was directed at the
https://github-issue-mover.appspot.com/ I posted, it doesn't
janpio closed issue #2: TEst
URL: https://github.com/apache/cordova/issues/2
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the
janpio commented on issue #2: TEst
URL: https://github.com/apache/cordova/issues/2#issuecomment-415347724
Manually closing this now.
This is an automated message from the Apache Git Service.
To respond to the message, please
janpio opened a new issue #2: TEst
URL: https://github.com/apache/cordova/issues/2
_From @janpio on August 23, 2018 9:11_
test
_Copied from original issue: apache/cordova-discuss#109_
This is an automated
How do we get apps unlocked for organization access?
Just request access using the GitHub dialog that pops up, or doe we have to
file INFRA tickets?
While I found it very nice to have some dedicated space for higher level
design discussions, cordova-discuss
is heavily unmaintained and feedback to
Thanks Jan - I will hold off until we are ready of course.
Raphael - close as in there can not be any more comments added or
additions to the issue, not deletion. They will still exist and be
searchable. We definitely can add a label when we close them.
On Thu, Aug 23, 2018 at 5:01 PM Jan
Thanks for doing this!
I'm not sure about the bulk closing. Last time I checked, at least for our
tooling even very old issues were often still valid and provided some
valuable insight for me. I'd leave them.
If we want to close them, They should definitely get some label that makes
them easily
Just a note to make sure: Please do not proceed with this before issue
and PR templates are in place, labels are unified etc - meaning:
GitHub repos are ready.
(Working on this right now)
Am Do., 23. Aug. 2018 um 10:53 Uhr schrieb Shazron :
>
> I've done this for our JIRA:
> - I've changed
Issues can be moved e.g. with https://github-issue-mover.appspot.com/.
As the issues were a thing of keeping track of stuff, I think
@raphinesse and @brodybits who created most of those issue should take
care of moving their issues to the appropriate repo or close them
themselves, so they are
I've done this for our JIRA:
- I've changed "Resolved" issues to "Closed" (about 8000+ of them)
- I've changed issues with "No Component" to the relevant component
What's left:
- We have 1881 Open, Reopened or In Progress issues
- 474 were created in the last year (52 weeks)
- thus
It's mainly about discoverability, now that we have `cordova` repo
itself (one stop shop for general issues?). `discuss` repo was there
as you mentioned for historical reasons. Now that we have the
`cordova` repo, and we can discuss in the Issues of that repo, another
repo for discussion is
I wanted to use GitHub's GraphQL to gather some insights about cordova
repos. I could not access some organization level information that I could
see over the web, without requesting organization (apache) wide privileges
for GraphQL.
So it's not always that easy.
Shazron schrieb am Do., 23.
Wasn't `cordova-discuss` for a totally different use case?
>From how I understood it, Cordova has/had a formal "proposal" process
that consisted of someone writing a proposal as a PR for higher level
topics. Then a discussion was triggered via an email to this list,
which was had in the comments
> track some high-level topics of items that need to be addressed.
What would those be?
> I think this item is an excellent example of itself.
Not really, besides the hazy definition of the actual problem, this is
_exactly_ the right place to discuss matters that concern the
development of
Which plugins do fall in these two categories in your opinion?
Am Do., 23. Aug. 2018 um 01:27 Uhr schrieb Chris Brody :
>
> From some other discussions I started to wonder if we should consider
> deprecating some more Cordova plugins that fall into either of these
> categories:
> * not critical to
+1 for a public Slack channels that includes development discussion
and other non-private contributor matters.
Am Do., 23. Aug. 2018 um 01:14 Uhr schrieb Chris Brody :
>
> I noticed that a lot of important dev chat discussions on private Slack PMC
> channel does not really need to be kept private.
Again you split the discussion in 2 places by repeating here what you
already commented on the PR. Please stop doing so and complaining how
complicated and scattered everything is in other threads. This is part
of the reason.
I responded to your PR comment.
Am Do., 23. Aug. 2018 um 00:59 Uhr
Sorry hit send too quick.
I added jira.cordova.io as a transition step for us that points to the
current JIRA
On Thu, Aug 23, 2018 at 2:04 PM Shazron wrote:
>
> I've changed the redirect issues.cordova.io to point to
> https://github.com/apache/cordova and added a pointer in the README on
> where
I've changed the redirect issues.cordova.io to point to
https://github.com/apache/cordova and added a pointer in the README on
where to file an issue. It might take some time to propagate
On Thu, Aug 16, 2018 at 9:18 PM Jan Piotrowski wrote:
>
> Oh wow, you already can't create issues for Cordova
I think we should stick to one repo --
https://github.com/apache/cordova and archive the discuss repo.
We should point to that one repo for all things Cordova w.r.t to dev.
On Thu, Aug 23, 2018 at 4:13 AM Chris Brody wrote:
>
> While I personally think it would continue to fill an existing gap
35 matches
Mail list logo
