Re: INFRA requests based on the F2F meeting
Forgot to paste the link: https://github.com/orgs/apache/projects/2 To grab issues from repos, Add Cards -> uncheck "Only show results from linked repositories" then use a query to limit your search On Wed, Aug 22, 2018 at 9:37 AM Shazron wrote: > > The Org Project Level Board has been created. We can add issues from > all repos in the Apache org now. > https://issues.apache.org/jira/browse/INFRA-16913 > > > On Sat, Aug 18, 2018 at 4:22 PM Shazron wrote: > > > > Update: INFRA has fixed the issue. We can make modifications on issues > > again. Creation of issues is disabled -- only CB Project Admins can > > create new issues. > > On Sat, Aug 18, 2018 at 4:02 PM Shazron wrote: > > > > > > I'll ask INFRA to revert the change. > > > On Fri, Aug 17, 2018 at 3:51 PM Jan Piotrowski > > > wrote: > > > > > > > > Can confirm, Cordova JIRA seems to be fully read only now. Seems we > > > > should roll back and only deactivate after we migrated everything > > > > (somehow). > > > > > > > > 2018-08-17 5:05 GMT+02:00 Shazron : > > > > > There might be a side effect on locking down JIRA. I can't comment on > > > > > existing JIRA issues now. > > > > > On Thu, Aug 16, 2018 at 9:40 PM Shazron wrote: > > > > >> > > > > >> Not sure how, maybe edit some project settings in JIRA, need to > > > > >> investigate. > > > > >> > > > > >> On Thu, Aug 16, 2018 at 9:18 PM Jan Piotrowski > > > > >> wrote: > > > > >>> > > > > >>> Oh wow, you already can't create issues for Cordova in JIRA any > > > > >>> more. > > > > >>> That was quick. > > > > >>> > > > > >>> Is there maybe a way to somehow point people into the right > > > > >>> direction in JIRA? > > > > >>> We will now of course update issues.cordova.io, but I assume some > > > > >>> peole have https://issues.apache.org/jira/projects/CB/ or similar > > > > >>> URLs > > > > >>> bookmarked. > > > > >>> > > > > >>> -J > > > > >>> > > > > >>> 2018-08-16 10:34 GMT+02:00 Shazron : > > > > >>> > 1. Org Level Project Board > > > > >>> > https://issues.apache.org/jira/browse/INFRA-16913 > > > > >>> > 2. Lock down JIRA for creation of new issues > > > > >>> > https://issues.apache.org/jira/browse/INFRA-16914 > > > > >>> > > > > > >>> > - > > > > >>> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > > >>> > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > >>> > > > > > >>> > > > > >>> - > > > > >>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > > >>> For additional commands, e-mail: dev-h...@cordova.apache.org > > > > >>> > > > > > > > > > > - > > > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Nightly build #827 for cordova has failed
Nightly build #827 for cordova has failed. Please check failure details on build details page at https://builds.apache.org/job/cordova-nightly/827/ You can also take a look at build console: https://builds.apache.org/job/cordova-nightly/827/consoleFull - Jenkins for Apache Cordova - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: INFRA requests based on the F2F meeting
The Org Project Level Board has been created. We can add issues from all repos in the Apache org now. https://issues.apache.org/jira/browse/INFRA-16913 On Sat, Aug 18, 2018 at 4:22 PM Shazron wrote: > > Update: INFRA has fixed the issue. We can make modifications on issues > again. Creation of issues is disabled -- only CB Project Admins can > create new issues. > On Sat, Aug 18, 2018 at 4:02 PM Shazron wrote: > > > > I'll ask INFRA to revert the change. > > On Fri, Aug 17, 2018 at 3:51 PM Jan Piotrowski wrote: > > > > > > Can confirm, Cordova JIRA seems to be fully read only now. Seems we > > > should roll back and only deactivate after we migrated everything > > > (somehow). > > > > > > 2018-08-17 5:05 GMT+02:00 Shazron : > > > > There might be a side effect on locking down JIRA. I can't comment on > > > > existing JIRA issues now. > > > > On Thu, Aug 16, 2018 at 9:40 PM Shazron wrote: > > > >> > > > >> Not sure how, maybe edit some project settings in JIRA, need to > > > >> investigate. > > > >> > > > >> On Thu, Aug 16, 2018 at 9:18 PM Jan Piotrowski > > > >> wrote: > > > >>> > > > >>> Oh wow, you already can't create issues for Cordova in JIRA any more. > > > >>> That was quick. > > > >>> > > > >>> Is there maybe a way to somehow point people into the right direction > > > >>> in JIRA? > > > >>> We will now of course update issues.cordova.io, but I assume some > > > >>> peole have https://issues.apache.org/jira/projects/CB/ or similar URLs > > > >>> bookmarked. > > > >>> > > > >>> -J > > > >>> > > > >>> 2018-08-16 10:34 GMT+02:00 Shazron : > > > >>> > 1. Org Level Project Board > > > >>> > https://issues.apache.org/jira/browse/INFRA-16913 > > > >>> > 2. Lock down JIRA for creation of new issues > > > >>> > https://issues.apache.org/jira/browse/INFRA-16914 > > > >>> > > > > >>> > - > > > >>> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > >>> > For additional commands, e-mail: dev-h...@cordova.apache.org > > > >>> > > > > >>> > > > >>> - > > > >>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > >>> For additional commands, e-mail: dev-h...@cordova.apache.org > > > >>> > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] [Github Issues] Support questions in GitHub issues
I just had a quick look and around 90% of new issues are tagged with support label. Do we really want that? Real issues will be buried with this volume of support issues. El sábado, 11 de agosto de 2018, julio cesar sanchez escribió: > I have always closed the issues that weren’t issues and pointed people to > SO or slack. Same for when ask questions on the dev mail list. > > El sábado, 11 de agosto de 2018, Jan Piotrowski > escribió: > >> > I think we should make that clear in the issue template >> > and direct people to slack or stackoverflow. >> >> I personally don't really think that's necessary. >> >> The issue volume for Cordova is very low (at least on JIRA and at >> least since Github issues were enabled), so having a few support >> requests bring some activity (and in the best case positive outcome >> for the users) is actually a good thing. >> >> Another aspect: The moment you introduce a restrictive policy, the >> issues work as a maintainer tends to get very negative - most people >> ignore the issue template anyway and post their support requests >> anway, which you have to close and post a canned reply. >> >> Which of course doesn't mean that the "Support Request" issue template >> should not direct people to StackOverflow and Slack, and definitely >> include some fields to fill out so we have something to work with (OS, >> versions etc.). But that's a thing for the other mailing list thread. >> >> If the volume or benefit of support requests ever gets overwhelming, >> we can still change that policy. >> >> > We might still use a support label as closing reason. >> >> If the majority of maintainers really wants to disallow support >> requests, this would be a nice way to categorize those requests and >> enable a discussion in the closed issue anyway. >> >> -J >> >> >> 2018-08-11 9:30 GMT+02:00 : >> > Jan proposed a support label for issues more than once. That fit me >> > thinking. Do we really want to allow support questions like this one >> [1] in >> > the issues? >> > >> > I'm definitely against it. I think we should make that clear in the >> issue >> > template and direct people to slack or stackoverflow. We might still >> use a >> > support label as closing reason. >> > >> > What do you think? >> > >> > [1]: https://github.com/apache/cordova-android/issues/474 >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> For additional commands, e-mail: dev-h...@cordova.apache.org >> >>
Re: [DISCUSS] [Github Issues] Issue and Pull Request labels
Labels that I would like to have: - something to show that you are open to suggestions or want to work out how something is supposed to work. Could be "discussion" - A "Work in Progress" label I would have tried to just write a script that creates the labels via GH API. But do we have the necessary permissions to do so? Jan Piotrowski schrieb am Do., 9. Aug. 2018, 23:07: > Now that we have Github issues enabled for all our repositories, > another new thing we have to talk about are Github Issue and Pull > Request labels. > > > If you are not aware of Github labels, here is a nice introduction: > https://help.github.com/articles/about-labels/ > > This also contains a list of the default labels all our repositories > got when issues were enabled: > > > bug, duplicate, good first issue, help wanted, invalid, question, wontfix > > https://help.github.com/articles/about-labels/#using-default-labels > > Issues also have a color, which - when chosen well and used uniform > across repositories - make it easier to scan the issue list. > > > As we come from JIRA, it's important to understand the differences. > A JIRA ticket has many different fields: Type, Status, Priority, > Resolution, Affects Version/s, Fix Version/s, Component/s, Labels, > Security Level, Environment, Estimate, Flag, External issue URL, > External issue ID, Epic Link, Sprint, Docs Text > On Github none of those exist. Most of this information has to be > supplied via the description of the issue (and can be requested via > the issue or PR template, see previous email), but it can also make > sense to map some of those via Github labels. > > > With the first few issues that came in on our repositories, I already > created the following two new labels: > > - `support` - Used for support questions that don't report a bug and > don't request a new feature but e.g. want to understand how something > works, need help debugging their individual problem etc. (This will > probably be the majority of the issue we are getting.) > - `platform: android` (ios, browser, windows, osx) - For plugin > repositories it makes sense to categorize e.g. a bug report or feature > request for its platform > > > Other projects have very structured labels: > https://github.com/fastlane/fastlane/labels > https://github.com/ionic-team/ionic-cli/labels > > Or pretty extensive lists of stuff: > https://github.com/Microsoft/TypeScript/labels > https://github.com/Microsoft/vscode/labels > > What do we actually need for the beginning? > Any other input? > > > Does anyone have an idea how we can "manage" our labels across our ~70 > repositories? Are there any scripts out there that can automate the > creation/deletion of them via the Github API? > > > Best, > Jan > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
Re: [DISCUSS] [Github Issues] Issue and PR template + Merge Conventions / Protected Branch
Sounds pretty good to me. A few thoughts: - The support question template should refer people to a proper support site like Stack Overflow. - Merge convention should be: if multiple commits make the history more meaningful, do a merge commit, else squash and rebase. - the templates will probably require different information to be provided, depending on the repository. cordova-lib is usually platform independent, for example. Shazron schrieb am Mi., 8. Aug. 2018, 06:52: > 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 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 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 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 this is talking about). Do you know how other > project > > >> > handle that? > > >> > > >> Haven't seen anything like this before. > > >> > > >> > In the end it is always the decision of the committer how > contributed > > >> > code makes it into the code base, so having good guidelines for us > > >> > would probably be the best solution, right? > > >> > > >> Yes. General common sense may prove to be the major principle, as I > > >> think it has in the past. For example: > > >> * Someone raises a PR with bug fixes and major refactoring in separate > > >> commits (should not be squashed) > > >> * Someone else raises a PR with a single fix, but with extra commits > > >> to fix issues with the first commit (*should* be squashed) > > >> > > >> I wonder if we can track these discussions in a better way, somehow. I > > >> have no time to help with these things right now. I think better > > >> tracking could help ensure these important tasks do not get forgotten. > > >> > > >> - > > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > >> For additional commands, e-mail: dev-h...@cordova.apache.org > > >> > > >> > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
