e.g. Apache Camel does use JIRA for issue tracking. They are not using GitHubs issue management. And they do accept pull requests.
And from the infra blog https://blogs.apache.org/infra/entry/improved_integration_between_apache_and Any Pull Request that gets opened, closed, reopened or commented on now gets recorded on the project's mailing list If a project has a JIRA instance, any PRs or comments on PRs that include a JIRA ticket ID will trigger an update on that specific ticket I don’t get your point. BR Maruan Am 21.09.2014 um 21:42 schrieb John Hewson <j...@jahewson.com>: >> I’d think if projects such as Apache Camel, Apache Jackrabbit, Apache Tomee, >> Apache Cordova to mention some can handle it we should be smart enough to >> handle it too. > > None of those projects make use of file attachments for issues the way that > we do. > >> I can’t see the issues tab for these projects but pull requests. > > Is exactly my point - we’re forced to use GitHub issues for pull requests, > which is a problem because then we don’t get to manage these via JIRA. > Looking at these projects all of them have had pull requests which do not > contain any references to JIRA issues but have been merged in, so it seems > certain that we would loose JIRA as a central point of information. > > -- John > > On 20 Sep 2014, at 04:24, Maruan Sahyoun <sahy...@fileaffairs.de> wrote: > >> I’d think if projects such as Apache Camel, Apache Jackrabbit, Apache Tomee, >> Apache Cordova to mention some can handle it we should be smart enough to >> handle it too. And I can’t see the issues tab for these projects but pull >> requests. >> >> BR >> Maruan >> >> Am 20.09.2014 um 04:22 schrieb John Hewson <j...@jahewson.com>: >> >>>> Issue tracking would still be done using Jira. Same as for most other >>>> Apache projects >>> >>> The problem with that approach is that GitHub’s pull requests can only be >>> managed via GitHub’s issues interface, so we’re forced to use it. There’s >>> no way to prevent GitHub users from opening and discussing issues in pull >>> requests rather than on JIRA. >>> >>> -- John >>> >>> On 17 Sep 2014, at 21:58, Maruan Sahyoun <sahy...@fileaffairs.de> wrote: >>> >>>> >>>> >>>> Maruan Sahyoun >>>> >>>>> Am 18.09.2014 um 02:03 schrieb John Hewson <j...@jahewson.com>: >>>>> >>>>> I agree with Tilman on this point, the examples need to stay in the trunk >>>>> where they can be built along with it. >>>>> It’s very common to modify an example to take into account API changes. >>>>> They’re also currently distributed along with the main PDFBox source >>>>> bundle, which is a good thing. >>>>> >>>>> I’d be surprised if anybody outside of the project wanted to contribute >>>>> to the documentation, almost nobody seems to like writing it. Perhaps we >>>>> could do this as a trial - see if it really increases contributions or >>>>> not? It would be great if it did. >>>>> >>>> >>>> OK so lets try with the docs. >>>> >>>> To mention it for completness - the build process for the web site and the >>>> documentation contained within will still be done by the Apache CMS. >>>> >>>>> It’s worth adding that I’m (reluctantly) against moving PDFBox trunk over >>>>> to GitHub because GitHub Issues is not powerful enough for our needs >>>>> (e.g. no file attachments), which is really a shame. >>>>> >>>> >>>> Issue tracking would still be done using Jira. Same as for most other >>>> Apache projects >>>> >>>>> -- John >>>>> >>>>>> On 17 Sep 2014, at 10:26, Tilman Hausherr <thaush...@t-online.de> wrote: >>>>>> >>>>>> Hi Maruan, >>>>>> >>>>>> The examples only. >>>>>> >>>>>> With "the docs" I assume you mean the website. I've never touched it >>>>>> (although I might in the future), it isn't part of the project, so I >>>>>> don't mind. >>>>>> >>>>>> Tilman >>>>>> >>>>>>> Am 17.09.2014 um 19:01 schrieb Maruan Sahyoun: >>>>>>> is that because of the examples, the docs or both? >>>>>>> >>>>>>> BR >>>>>>> >>>>>>> Maruan >>>>>>> >>>>>>>> Am 17.09.2014 um 18:46 schrieb Tilman Hausherr <thaush...@t-online.de>: >>>>>>>> >>>>>>>> It is a "I don't like it, but I can live with it but I think it might >>>>>>>> be a pain". A "soft -1". >>>>>>>> >>>>>>>> Tilman >>>>>>>> >>>>>>>>> Am 17.09.2014 um 08:40 schrieb Andreas Lehmkühler: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>>> Tilman Hausherr <thaush...@t-online.de> hat am 16. September 2014 um >>>>>>>>>> 18:03 >>>>>>>>>> geschrieben: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -1, I don't like the idea to have different repository types. >>>>>>>>> Hmmm, is this just a "I don't like it, but I can live with it" or is >>>>>>>>> it a clear >>>>>>>>> veto? >>>>>>>>> >>>>>>>>> In a case of a veto, how about starting with moving parts of the docs >>>>>>>>> to a new >>>>>>>>> git repo? IMO sooner or later the project will move from svn to git >>>>>>>>> and that >>>>>>>>> would be a good opertunity to get used to the general usage of git >>>>>>>>> and of course >>>>>>>>> to the special processes used here at the ASF so that we are not >>>>>>>>> thrown in at >>>>>>>>> the deep end after the migration. >>>>>>>>> >>>>>>>>>> Tilman >>>>>>>>> BR >>>>>>>>> Andreas >>>>>>>>> >>>>>>>>>>> Am 16.09.2014 um 10:21 schrieb Maruan Sahyoun: >>>>>>>>>>> Hi there, >>>>>>>>>>> >>>>>>>>>>> in order to make it easier for people to contribute to the >>>>>>>>>>> documentation and >>>>>>>>>>> examples I thought about the potential benefits of moving these to >>>>>>>>>>> a git >>>>>>>>>>> based repository instead of svn. The main idea behind that is to >>>>>>>>>>> allow >>>>>>>>>>> people to contribute via github opening another channel of >>>>>>>>>>> communication and >>>>>>>>>>> making it easier to contribute. >>>>>>>>>>> >>>>>>>>>>> Proposed names are pdfbox-docs and pdfbox-examples. Take a look at >>>>>>>>>>> https://github.com/apache/cordova-docs for an example of that. >>>>>>>>>>> >>>>>>>>>>> I haven’t thought about all potential implications and changes >>>>>>>>>>> necessary yet >>>>>>>>>>> but wanted to get a first feedback about support for that idea >>>>>>>>>>> before >>>>>>>>>>> putting more effort into that. >>>>>>>>>>> >>>>>>>>>>> WDYT? >>>>>>>>>>> >>>>>>>>>>> Maruan >>>>> >>> >> >
