Or, if someone volunteers to create and maintain a bot which duplicates the Github issue to JIRA ticket specifically for a label, we will see the changes of people's preference over time. If we clearly see that people's preference is on Github issues, discussion and vote will be super straightforward. If it doesn't happen, kill the bot and enforce ASF JIRA for code contribution again. This is good for me as well, as an "attempt" of evaluating the tool change (which is not a very trivial decision).
On Fri, Jan 30, 2026 at 2:12 PM Jungtaek Lim <[email protected]> wrote: > Why can't we do this in two phases instead of trying to build Rome in a > day? > > We start to use Github issues as an entry point for questions and reports. > We see how many people would request account creations, and they end up > filing JIRA tickets (indicating they are contributing "code"). Run this > model for 3 months or even 6 months and see whether committers+ start to > feel more familiar with Github issues (assuming they look at reports - if > they don't look at reports in Github issues, we then figure out it is NOT a > tool issue), and do the discussion again. So many contributors+ here are > used to JIRA for multiple years; it sounds too ambitious to change the > workflow in one day. > > > On Fri, Jan 30, 2026 at 12:12 PM Tian Gao <[email protected]> wrote: > >> Appreciate the data. That stat also matches my personal experience. >> However, I consider that as a result of using JIRA, not a reason to stick >> to it. I think we don't have much discussions because we are using JIRA >> exclusively. >> >> I think github issues just have better user experience than JIRA, even >> not considering the registration barrier. >> >> Let me be more specific. >> >> When you enter the issue page of JIRA, it would be like this: >> >> [image: image.png] >> >> Notice that by default, we have ~7 visible tickets, ordered by priority, >> taking about 25% of the screen width. For each ticket, without clicking on >> it, I have about 7~8 words before it's truncated. I have a single icon >> indicating whether this is a task/bug/feature. >> >> On the right side, I have the details of this specific ticket, where I >> need to scroll down to get to the comment section. The comment section >> (after hitting the add comment button) has an old rich-text editor which >> does not support markdown. Syntax highlighting is supported, but hidden >> under some button. >> >> This is github issues page (of arrow) >> >> [image: image.png] >> >> Also about 7 issues by default, but much larger font, ordered by created >> time. Title is much more visible. There will be multiple labels indicating >> what the issue is about. You can also tell if the issue is assigned, how >> much discussion is in the issue and if there are PRs already. >> >> In the issue discussion comment section, it supports markdown very well, >> all the comments are clearer and better displayed. We all have worked with >> both JIRA and github PRs, I believe everyone can feel the different user >> experiences between the two. >> >> >> As a user who's browsing issues, it's much easier to find an interesting >> issue to discuss/work on. It's easier to click a label to see related >> issues (I find it quite difficult to find the component related tickets in >> JIRA). I think the UI is just more intuitive and familiar with programmers. >> >> >> "We don't have a lot of discussion on JIRA" should not be the reason that >> we don't need to migrate. On the contrary, I think that's the reason why we >> should. >> >> Tian Gao >> >> On Thu, Jan 29, 2026 at 6:42 PM Wenchen Fan <[email protected]> wrote: >> >>> Thanks Sean for taking care of the JIRA account requests! I feel guilty >>> that I almost never look at these requests... >>> >>> I did some data analysis: in Spark 4.1.0 we resolved *1865* tickets, >>> *1077(57.75%)* of them have no description, *1515(81.23%)* of them only >>> has a bot comment saying PR for it has been merged. For the rest, LLM >>> detected that some comments are not meaningful discussion, such as "PR for >>> this ticket ...", "This is backported to ...", "working on it", etc. Only >>> *128 >>> tickets (6.86%)* have actual discussion. >>> >>> It seems to me that JIRA is mostly a procedure overhead. It also matches >>> my personal experience: most discussions happen in the dev list and PRs. >>> Even if we enable Github Issues, will people discuss within it? How do >>> other open source projects manage their PRs? >>> >>> On Fri, Jan 30, 2026 at 10:14 AM Szehon Ho <[email protected]> >>> wrote: >>> >>>> +1 (non binding) for github issue. It'd be great to reduce the small >>>> but continuous duplicate work to fill out information in the JIRA and >>>> github issue/pr for every contribution. For new users, it also does seem a >>>> pain to request the JIRA account , and for PMC to approve each one. >>>> >>>> Thanks >>>> Szehon >>>> >>>> On Thu, Jan 29, 2026 at 11:52 AM Tian Gao via dev <[email protected]> >>>> wrote: >>>> >>>>> > It'd be super confusing to people that are not using these day to >>>>> day to see both. Where should they be reporting bugs? Where should they >>>>> search? If there are duplications, there's not even a structured way to >>>>> link them. >>>>> >>>>> I would imagine that if github issues are available, normal users >>>>> would just use that to report bugs. It does not quite make sense for them >>>>> to go to JIRA to report stuff if they can just do it on github. Searching >>>>> is an issue if we do not sync both sources. That's an advantage for a >>>>> full migration (or no migration at all). Still, I think we should >>>>> eventually move to github (if we start from scratch, will we use github >>>>> issues or JIRA?). >>>>> >>>>> Also interesting thoughts about linking - github supports >>>>> bidirectional links once you mention a PR/issue in another. JIRA kind of >>>>> supports this to github PRs, but requires a bot. The nice thing about the >>>>> github links is that it also supports preview and popup in their UI (well >>>>> it's native). >>>>> >>>>> My belief is to migrate to github issues and give up JIRA, but I >>>>> understand that people have concerns about benefit vs cost, so I think an >>>>> intermediate phase to have both could be helpful to the eventual goal. >>>>> >>>>> Tian Gao >>>>> >>>>> On Thu, Jan 29, 2026 at 11:40 AM Gengliang Wang <[email protected]> >>>>> wrote: >>>>> >>>>>> I checked the 2025 data: out of 492 ASF JIRA account requests for >>>>>> Spark, only *34* were rejected. Most requests were reviewed and >>>>>> approved—often on the same day—by Sean Owen ([email protected]). >>>>>> >>>>>> I don’t have data on how many approved accounts eventually filed a >>>>>> JIRA. >>>>>> >>>>>> On Thu, Jan 29, 2026 at 11:28 AM Tian Gao <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Do we have a stat about how many of them are approved and how many >>>>>>> approved accounts made at least 1 JIRA? >>>>>>> >>>>>>> We know the current flow is: >>>>>>> >>>>>>> Desire to contribute -> Find out need to use JIRA -> Go to JIRA -> >>>>>>> Realize they need an account -> Request for account -> Wait for >>>>>>> approval -> >>>>>>> Submit JIRA ticket -> Do a PR... >>>>>>> >>>>>>> For each step in this flow, we are losing contributors. As we >>>>>>> already host our repo on github, we can safely assume most of the >>>>>>> desired >>>>>>> contributors are familiar with github workflow, then the workflow could >>>>>>> be >>>>>>> >>>>>>> Desire to contribute -> submit an issue -> do a PR. >>>>>>> >>>>>>> From my experience in open source projects, contributor's desire to >>>>>>> contribute fades fast when they hit blockers, especially procedural >>>>>>> issues. >>>>>>> >>>>>>> Tian Gao >>>>>>> >>>>>>> On Thu, Jan 29, 2026 at 11:14 AM Gengliang Wang <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> I did a quick check and found that there were *492* new ASF >>>>>>>> Spark JIRA account creation requests in 2025. The extra step of >>>>>>>> requesting >>>>>>>> a JIRA account can still be a meaningful barrier—especially for >>>>>>>> contributors who are already active on GitHub but less familiar with >>>>>>>> ASF >>>>>>>> workflows. >>>>>>>> >>>>>>>> +1 to maintaining both ASF JIRA and GitHub Issues. >>>>>>>> >>>>>>>> On Thu, Jan 29, 2026 at 11:09 AM Tian Gao via dev < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> First of all, I believe the merge script is another issue that is >>>>>>>>> worth discussing but not strictly involved in this proposal. I was >>>>>>>>> talking >>>>>>>>> about potential future benefits for the merge script by migrating our >>>>>>>>> work >>>>>>>>> to github. On this specific matter, like I said, a github bot would >>>>>>>>> probably be better than a manual script - we should be able to do >>>>>>>>> whatever >>>>>>>>> we do with that. The good thing is we can just label the PR >>>>>>>>> (auto-merge) >>>>>>>>> (or a specific comment like bot merge) and run the bot, instead of >>>>>>>>> setting >>>>>>>>> up a local environment. >>>>>>>>> >>>>>>>>> Back to the real topic. I don't think we should keep two systems >>>>>>>>> stamping on each other in the long term. But we have a puzzle that >>>>>>>>> we'll >>>>>>>>> never solve if we bind all PRs to JIRA - how many more contributors >>>>>>>>> we will >>>>>>>>> have if it's easier for them to contribute code? I don't have a >>>>>>>>> definitive >>>>>>>>> answer for that and that's what I want to find out. I think the >>>>>>>>> existing >>>>>>>>> committers will benefit some from a successful migration, but the real >>>>>>>>> motivation is for people who are not familiar with JIRA or who >>>>>>>>> can't/don't >>>>>>>>> want to use JIRA. If we can get a significant boost of our community >>>>>>>>> contribution, I'd say that's worth the trouble. I think many of us are >>>>>>>>> thinking about this from a committer's perspective (which is natural >>>>>>>>> obviously), but I was a new contributor 6 months ago and the first >>>>>>>>> thing >>>>>>>>> that stopped me from contributing was the allowed-user-only JIRA. >>>>>>>>> >>>>>>>>> People may argue that almost all recent contributions are from >>>>>>>>> committers or regular contributors and they are already familiar with >>>>>>>>> JIRA >>>>>>>>> - that's true, but isn't that also evidence that we should embrace the >>>>>>>>> community a bit more? >>>>>>>>> >>>>>>>>> I think if we support a dual-rail system - it should be an >>>>>>>>> intermediate phase where we observe if it's worth it for us to >>>>>>>>> migrate to >>>>>>>>> github issues. If so, it gives us some time to build infra around >>>>>>>>> github >>>>>>>>> issues while keeping the workflow going. >>>>>>>>> >>>>>>>>> Of course, it's possible that this is just some fantasy I have and >>>>>>>>> we don't get observably more new contributions from the community with >>>>>>>>> github issues, then we can just use it as a discussion board and >>>>>>>>> feedback >>>>>>>>> channel. >>>>>>>>> >>>>>>>>> Tian Gao >>>>>>>>> >>>>>>>>> On Thu, Jan 29, 2026 at 5:07 AM Jungtaek Lim < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> The only downside I can think of is future release notes will >>>>>>>>>>> contain mixed items from Github Issues and JIRAs. >>>>>>>>>> >>>>>>>>>> I'm not sure I think this is trivial. IMHO if we want to maintain >>>>>>>>>> two systems altogether, each system should serve its purpose and not >>>>>>>>>> interleave. >>>>>>>>>> >>>>>>>>>> For example, allowing Github issues to be an easy entry point for >>>>>>>>>> questions, making Github issues to serve the major purpose of users@ >>>>>>>>>> instead of drop-in replacement of JIRA. And for code contributions >>>>>>>>>> we still >>>>>>>>>> require JIRA tickets. This strictly scopes the purpose of both >>>>>>>>>> systems. >>>>>>>>>> >>>>>>>>>> It doesn't mean I prefer maintaining two systems; I mean let's >>>>>>>>>> not leave both systems to be active for the same purpose which will >>>>>>>>>> bug us >>>>>>>>>> in future. I don't have a strong opinion to pick one system over >>>>>>>>>> another, >>>>>>>>>> but I have an opinion that we shouldn't end up with compromise and >>>>>>>>>> make the infra to be a weird state. >>>>>>>>>> >>>>>>>>>> Btw I'm not sure Github's squeeze commit in the UI page is a >>>>>>>>>> drop-in replacement of the merge script e.g. the merge script >>>>>>>>>> handles the >>>>>>>>>> tricky authorship issue via listing up lead-author and co-authors >>>>>>>>>> based on >>>>>>>>>> the author of commits before squeezing. I don't know whether it's >>>>>>>>>> supported. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Jan 29, 2026 at 4:07 PM Wenchen Fan <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> +1 to maintain both. Why not give contributors a new option with >>>>>>>>>>> Github Issues? All we need to do is to allow people to create PRs >>>>>>>>>>> with link >>>>>>>>>>> to Github Issues, in addition to JIRAs. The only downside I can >>>>>>>>>>> think of is >>>>>>>>>>> future release notes will contain mixed items from Github Issues >>>>>>>>>>> and JIRAs. >>>>>>>>>>> >>>>>>>>>>> On Thu, Jan 29, 2026 at 7:22 AM Lisa N. Cao < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> It would make it easier for the community to see the progress >>>>>>>>>>>> of features, but there is some work involved to maintain both. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> LNC >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Jan 28, 2026 at 3:10 PM Tian Gao via dev < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I'm okay with not retiring JIRA, but if we only allow PRs with >>>>>>>>>>>>> JIRA tickets, we still have the same issue - the new contributors >>>>>>>>>>>>> can't >>>>>>>>>>>>> work on any problems without access to JIRA. >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, opening issue tabs will help with community feedback, but >>>>>>>>>>>>> I don't think we get full benefit from it if we restrict it to be >>>>>>>>>>>>> a >>>>>>>>>>>>> "discussion only" place. The community of spark is not only >>>>>>>>>>>>> users, but also >>>>>>>>>>>>> occasional contributors. >>>>>>>>>>>>> >>>>>>>>>>>>> If we worry about the dramatic migration from JIRA, we can >>>>>>>>>>>>> open github issues, and start building infra around it, while >>>>>>>>>>>>> keeping the >>>>>>>>>>>>> old system working. If we see a trend of committers using github >>>>>>>>>>>>> issues >>>>>>>>>>>>> more often, that's an indicator that people like github >>>>>>>>>>>>> integration more >>>>>>>>>>>>> than the existing JIRA system. >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, migrating to github issues means we probably need to >>>>>>>>>>>>> throw away a bunch of scripts for JIRA, but some of them are not >>>>>>>>>>>>> necessary >>>>>>>>>>>>> in the first place if we use github issues. For example, linking >>>>>>>>>>>>> issues to >>>>>>>>>>>>> PRs is a native supported feature in github. Github supports >>>>>>>>>>>>> "squash-only" >>>>>>>>>>>>> merge so people won't accidentally merge PRs with all the commit >>>>>>>>>>>>> history. >>>>>>>>>>>>> Github also supports "using PR description as commit message". >>>>>>>>>>>>> >>>>>>>>>>>>> Even if we do want extra flexibility, github bots have the >>>>>>>>>>>>> advantages of authentication. For example, if I understand >>>>>>>>>>>>> correctly, >>>>>>>>>>>>> committers need their JIRA token to make the current merge script >>>>>>>>>>>>> work - >>>>>>>>>>>>> that won't be necessary if we use github. Github issues can be >>>>>>>>>>>>> closed >>>>>>>>>>>>> automatically when a linked PR is merged (with close #number) or >>>>>>>>>>>>> a github >>>>>>>>>>>>> bot can easily do that. >>>>>>>>>>>>> >>>>>>>>>>>>> Therefore, if we don't want to close JIRA, I'm totally fine >>>>>>>>>>>>> with a dual-rail system which allows users to submit a PR based >>>>>>>>>>>>> on a github >>>>>>>>>>>>> issue, instead of a JIRA ticket. We can do that gradually and >>>>>>>>>>>>> polish up all >>>>>>>>>>>>> the infra required for github issues. Then we can make a decision >>>>>>>>>>>>> whether >>>>>>>>>>>>> to migrate completely. >>>>>>>>>>>>> >>>>>>>>>>>>> Tian Gao >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Jan 28, 2026 at 2:47 PM Dongjoon Hyun < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> -1 because I don't think we should move from the existing one >>>>>>>>>>>>>> (ASF JIRA) to a new one (GitHub Issues) completely to meet the >>>>>>>>>>>>>> suggested >>>>>>>>>>>>>> ideas. It sounds like a little overkill for the goals. They can >>>>>>>>>>>>>> be used >>>>>>>>>>>>>> more harmoniously. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Specifically, I want to counter-propose a simpler alternative >>>>>>>>>>>>>> which is used already in some ASF projects: GitHub Issue Tab can >>>>>>>>>>>>>> be used as >>>>>>>>>>>>>> an additional preliminary discussion place (receiving issue >>>>>>>>>>>>>> reports before >>>>>>>>>>>>>> creating actual JIRA issues). Since this is open to all GitHub >>>>>>>>>>>>>> users, it >>>>>>>>>>>>>> already meets the proposed goals. And, there is no reason to >>>>>>>>>>>>>> abandon ASF >>>>>>>>>>>>>> JIRA because only worthy ideas will get JIRA IDs after closing >>>>>>>>>>>>>> duplicated >>>>>>>>>>>>>> issues or naive Spark questions from GitHub Issue tabs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> We can build a better layered issue reporting system by >>>>>>>>>>>>>> getting all the benefits of the existing ASF JIRA infra and >>>>>>>>>>>>>> GitHub Issue >>>>>>>>>>>>>> Tab instead of wasting lots of the community resources due to >>>>>>>>>>>>>> the drastic >>>>>>>>>>>>>> migration (or abandoning the established system, script, >>>>>>>>>>>>>> practices). >>>>>>>>>>>>>> >>>>>>>>>>>>>> > I think we should move from JIRA to github issues for >>>>>>>>>>>>>> > * more feedback from community >>>>>>>>>>>>>> > * lower barrier to entry for new contributors >>>>>>>>>>>>>> > * better integration with the whole github eco-system >>>>>>>>>>>>>> >>>>>>>>>>>>>> Dongjoon. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2026/01/27 14:57:00 Bjørn Jørgensen wrote: >>>>>>>>>>>>>> > Github use mentioned instead of related to >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Like this >>>>>>>>>>>>>> > [image: image.png] >>>>>>>>>>>>>> > https://github.com/apache/arrow/issues/48961 >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > tir. 27. jan. 2026 kl. 14:58 skrev Nicholas Chammas < >>>>>>>>>>>>>> > [email protected]>: >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > > One thing GitHub Issues doesn’t have a native equivalent >>>>>>>>>>>>>> to are issue >>>>>>>>>>>>>> > > links. GitHub will extract mentions of other tickets and >>>>>>>>>>>>>> highlight them in >>>>>>>>>>>>>> > > the side bar, but on Jira you can just link a ticket to >>>>>>>>>>>>>> another one >>>>>>>>>>>>>> > > directly. >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > Example: >>>>>>>>>>>>>> https://issues.apache.org/jira/browse/SPARK-28024 >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > [image: Screenshot 2026-01-27 at 8.55.28 AM.png] >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > Not saying this is a blocker. Just calling this out so we >>>>>>>>>>>>>> can try to >>>>>>>>>>>>>> > > preserve this information after the migration. >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > Nick >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > On Jan 26, 2026, at 8:00 PM, DB Tsai <[email protected]> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > +1, the bar for using JIRA is too high—contributors need >>>>>>>>>>>>>> a PMC/committer >>>>>>>>>>>>>> > > to create an account. Using GitHub issues would make it >>>>>>>>>>>>>> much easier for >>>>>>>>>>>>>> > > people to participate. >>>>>>>>>>>>>> > > DB Tsai | https://www.dbtsai.com/ | PGP >>>>>>>>>>>>>> 42E5B25A8F7A82C1 >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > On Jan 26, 2026, at 2:30 PM, Hyukjin Kwon < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > TBH, if we can manage to migrate all related repos in >>>>>>>>>>>>>> Apache Spark, I feel >>>>>>>>>>>>>> > > like it might be a great idea. >>>>>>>>>>>>>> > > lately I started to actively work on Apache Arrow, and >>>>>>>>>>>>>> realised that they >>>>>>>>>>>>>> > > also successfully migrate to GitHub Issues from JIRA for >>>>>>>>>>>>>> all ther repos. >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > On Tue, 27 Jan 2026 at 05:49, Tian Gao via dev < >>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>> > > wrote: >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > >> Hi all, I'd like to start a discussion on a draft SPIP: >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> https://docs.google.com/document/d/1WMaA49hKyu7gtU189fPq4k8TeI-Q73Q6bqSeWAgR3y8/edit?usp=sharing >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> tl; dr >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> I think we should move from JIRA to github issues for >>>>>>>>>>>>>> > >> * more feedback from community >>>>>>>>>>>>>> > >> * lower barrier to entry for new contributors >>>>>>>>>>>>>> > >> * better integration with the whole github eco-system >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> Many apache projects have moved from JIRA to github >>>>>>>>>>>>>> issues successfully, >>>>>>>>>>>>>> > >> including Arrow, Airflow, Beam, Maven, Lucene ... >>>>>>>>>>>>>> Actually most of apache >>>>>>>>>>>>>> > >> projects are using github issues now, with a few >>>>>>>>>>>>>> exceptions including spark. >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> I'd like to hear more about this proposal from the >>>>>>>>>>>>>> community. >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> Thanks! >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> Tian Gao >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > -- >>>>>>>>>>>>>> > Bjørn Jørgensen >>>>>>>>>>>>>> > Vestre Aspehaug 4, 6010 Ålesund >>>>>>>>>>>>>> > Norge >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > +47 480 94 297 >>>>>>>>>>>>>> > >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>> To unsubscribe e-mail: [email protected] >>>>>>>>>>>>>> >>>>>>>>>>>>>>
