So I guess this would be easier if we also said that contributions would only now be accepted via pull request. Is that too onerous? Instead of requiring everyone to have an Apache Jira account we require them to have a GitHub account.
Moving issue tracking to GitHub seems unlikely, as it's lacking a lot of features we depend on from Jira. Doug On Thu, Apr 26, 2018 at 10:31 AM Sean Busbey <bus...@cloudera.com> wrote: > so we'd still do issue tracking in JIRA, but specifically for looking at > who's contributed we'd use the github tooling? > > we could do a clean cut over for that. We'd have to get more rigorous at > making sure the author on commits is the contributor. the current > discrepency is a combination of svn days where it wasn't possible to > attribute authorship in the metadata and folks not setting it when using > git to commit a patch that comes in without metadata. > > On Thu, Apr 26, 2018 at 12:25 PM, Doug Cutting <cutt...@gmail.com> wrote: > > > Might we instead switch from Jira to GitHub for contribution tracking? > > Then we might not need to worry so much about who the Jira issue is > > assigned to. > > > > GitHub has contribution history: > > > > https://github.com/apache/avro/graphs/contributors > > > > Is this sufficient? It seems like it's missing a lot of older > > contributors, as compared with Jira: > > > > https://s.apache.org/mgf9 > > > > Thoughts? > > > > Doug > > > > > > On Thu, Apr 26, 2018 at 4:53 AM Sean Busbey <bus...@cloudera.com> wrote: > > > > > how about we create a PMC-controlled jira account to represent "pull > > > request from someone without a jira ID"? then we can follow your > > suggestion > > > of "encourage the contributor to create a jira id and assign to them" > and > > > we have a clear way to mark "you need to look at git or github to find > > the > > > author" when we go to look later. > > > > > > for CHANGES.txt we can either a) start asking contributors to update it > > as > > > a part of their PR, b) have the merging maintainer add a commit to the > PR > > > that does the CHANGES.txt update, c) switch to generating CHANGES.txt > at > > > release time rather than incrementally. > > > > > > for (c) we could use something like Apache Yetus Release Doc Maker[1], > > > which currently would require us to ensure everything is represented in > > > JIRA. Personally, I favor this last option. > > > > > > > > > [1]: http://yetus.apache.org/documentation/0.7.0/releasedocmaker/ > > > > > > On Mon, Apr 23, 2018 at 8:08 PM, Thiruvalluvan M. G <th...@apache.org> > > > wrote: > > > > > > > Hi all, > > > > > > > > Officially, we say that we track issues using Jira: > > > > https://avro.apache.org/ > > > > issue_tracking.html and suggest contributors to manage issues on > Jira. > > > But > > > > we receive several pull requests on github with or without > > corresponding > > > > Jira tickets. What is the best way to handle them? How do other > Apache > > > > projects handle these? > > > > > > > > I see two levels of problems: > > > > > > > > 1. When we have a Jira ticket for an issue, we sometimes see > > contribution > > > > come from someone who does not have an account on Jira. Whom do we > > assign > > > > the Jira ticket to? We have a few options, none of them pretty: > > > > > > > > a. Insist that the contributor creates and account in our Jira and > > assign > > > > the ticket to themselves. This could leave the fixes unnecessarily > > > blocked > > > > for long time. > > > > b. Leave the ticket unassigned. This is sloppy book-keeping. > > > > c. Assign to the person who created the ticket. This is wrong > > > attribution. > > > > Will cause trouble in evaluating contributors for committership. > > > > d. Assign to the person who merges the pull request. This is also > wrong > > > > attribution, but will encourage existing committers to consider and > > merge > > > > fixes expediously. > > > > > > > > My personal preference is the combination of (a) and (d). We should > > > > encourage the contributor to assign the Jira to themselves. If they > > don't > > > > do it in reasonable time (1 week?) let's assign to the person > > committing > > > > it. But if the contributor comes back later with their Jira id, we > > should > > > > reassign the ticket to them. > > > > > > > > 2. Pull requests are raised without a corresponding Jira ticket. Here > > one > > > > of us can create a new Jira ticket. When we do this, the situation is > > the > > > > same as the previous one. > > > > > > > > A related question: When we merge the pull request it typically does > > not > > > > update CHANGES.txt. How and when do we update this file? > > > > > > > > Any suggestions? > > > > > > > > Thank you, > > > > > > > > Thiru > > > > > > > > > > > > > > > > -- > > > busbey > > > > > > > > > -- > busbey >
