Re: It's very hard to become a committer on the project

[Юли Волкова]

Hi, Sid, thanks for some clarification about JIRA. At now, I walking
through jira's task and ask Ash or other guys with admins right to close
issues (for example:
https://issues.apache.org/jira/browse/AIRFLOW-307?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel),
because PRs was successful merged 2 years ago. I would like to help in this
scope: 1) If I have same moderators rights I can close tickets by myself
2) JIRA is a powerful tool on about integration - question only in do we
have admin rights to add different integrations and triggers-hooks to JIRA.
First of all, I propose to create hook what close task after PR was merged
in master. Many task are open without any status changing with  already
merged PRs.

On Tue, Sep 18, 2018 at 11:58 AM Sid Anand  wrote:

> Hi Folks!
> For some history, Airlfow started on GH issues. We also had a very popular
> Google group. When we moved to Apache, we were told that Jira was the way
> we needed to go for issue tracking because it resided on Apache
> infrastructure. When we moved over, we had to drop 100+ GH issues on the
> floor -- there was no way to transfer them to Jira and maintain the
> original submitter/owner info since there was no mapping of users between
> the 2 systems.
>
> Here's a pie chart of our existing issues by status:
>
> https://issues.apache.org/jira/secure/ConfigureReport.jspa?projectOrFilterId=project-12320023=statuses=12320023=com.atlassian.jira.jira-core-reports-plugin%3Apie-report_token=A5KQ-2QAV-T4JA-FDED|a85ff737799378265f90bab4f1456b5e2811a507|lin=Next
> 
>
> I'm attaching a screen shot as well.
>
> [image: Screenshot 2018-09-16 11.28.57.png]
>
> I think we all agree that there is better integration between GH PRs and
> GH Issues than between GH PRs and Jira issues.
>
> There are some practical matters to consider:
>
>- For the 1100-1200 unclosed/unresolved issues, how will we transfer
>them to GH or will we drop those on the floor? How would we map submitters
>between the 2 systems, and how would we transfer the 
> content/comments,etc...
>- For the existing closed PRs (>3k), whose PRs reference JIRA, we'd
>need to keep JIRA around in read-only mode so we could reference the
>bug/feature details, but somehow disallow new JIRA creations, lest some
>people continue to use it to create new issues
>- I'm assuming the GH issue naming would not conflict with that of
>JIRA naming in commit message subjects and PRs. In other words,
>incubator-airlow-1 vs AIRFLOW-1 or airflow-1 vs AIRFLOW-1 or possibly
>conflict at AIRFLOW-1? Once we graduate, I'm pretty sure the incubator name
>will be dropped, so there may be a naming conflict.
>
> In the end, these are 2 different tools. The issues you raise are mainly
> around governance.
>
> If you folks would like to propose a new means to manage the JIRAs, can
> you outline a solution on Wiki and drop a link into an email on this list?
> We can then raise a vote.
>
> IMHO, our community would scale the best if more people picked up
> responsibilities such as these. Grooming/Organizing JIRAs doesn't need to
> be a responsibility owned by the maintainers. Anyone can take the lead on
> discussions, etc...
>
> -s
>
> On Mon, Sep 17, 2018 at 2:09 AM Sumit Maheshwari 
> wrote:
>
>> Strong +1 for moving to GitHub from Jira.
>>
>> On Mon, Sep 17, 2018 at 12:35 PM George Leslie-Waksman > >
>> wrote:
>>
>> > Are there Apache rules preventing us from switching to GitHub Issues?
>> >
>> > That seems like it might better fit much of Airflow's user base.
>> >
>> >
>> > On Sun, Sep 16, 2018, 9:21 AM Jeff Payne  wrote:
>> >
>> > > I agree that Jira could be better utilized. I read the original
>> > > conversation on the mailing list about how Jira should be used (or if
>> it
>> > > should be used at all) and I'm still unclear about why it was picked
>> over
>> > > just using github issues. It refers to a dashboard, which I've yet to
>> > > investigate, but Jira is much more than just dashboards.
>> > >
>> > > If this project is going to use Jira, then:
>> > >
>> > > 1) It would be great to see moderation and labeling of the Jira
>> issues by
>> > > the main contributors to make it easier for people to break into
>> > > contributing.
>> > > 2) It would also be nice if the initial conversation of whether or
>> not an
>> > > issue warrants development at all happened on the Jira issue, or at
>> least
>> > > some acknowledgement by the main contributors.
>> > > 3) Larger enhancements and efforts or vague suggestions still get
>> > > discussed on the dev mailing list before a Jira is even opened, but
>> after
>> > > that, the discussion moves to the Jira, with a link back to the
>> mailing
>> > > list email for 

Re: Plan to change type of dag_id from String to Number?

[Юли Волкова]

Because in case what you described nothing about backward compatibility.
You think what all who use need to change all theirs DAG's? It's very
strange, because you propose one of the most critical change and it will
side everyone. If you want id - call it dag_metadata_id and add it. But not
propose change what hasn't backward compatibility. It's to strange.

On Thu, Aug 9, 2018 at 7:04 AM vardangupta...@gmail.com <
vardangupta...@gmail.com> wrote:

>
>
> On 2018/08/09 11:55:11, Ash Berlin-Taylor  wrote:
> > Absolutely - there will still need to be a human-readable DAG id, even
> we end up with an auto-icrementing integer ID column internally and for
> table join performance reasons.
> >
> > -ash
> >
> > > On 9 Aug 2018, at 12:35, Юли Волкова  wrote:
> > >
> > > How will you understand what your DAG 2 doing enter to it? For
> each of
> > > 100, for example?
> > > Especially, if you are not a developer, who create it. You are a
> support
> > > team and have 120 DAGs.
> > >
> > > The first time, when want to also send the answer to dev-mail list.
> Please,
> > > don't do it.
> > >
> > > I think it's will be really bad to all who use dag_id like a saying
> name of
> > > dag. If I will be looked at 0329313 this does not say anything useful
> for
> > > me and it will be very very complicated to identify for which process
> dag
> > > using.  It could be another id for the indexes in DB if it's real
> problem
> > > for somebody. But, please, do not change dag_id.
> > >
> > > On Mon, Aug 6, 2018 at 1:32 AM vardangupta...@gmail.com <
> > > vardangupta...@gmail.com> wrote:
> > >
> > >> Hi Everyone,
> > >>
> > >> Do we have any plan to change type of dag_id from String to Number,
> this
> > >> will make queries on metadata more performant, proposal could be
> generating
> > >> an auto-incremental value in dag table and this id getting used in
> rest of
> > >> the other tables?
> > >>
> > >>
> > >> Regards,
> > >> Vardan Gupta
> > >>
> > >
> > >
> > > --
> > > _
> > >
> > > С уважением, Юлия Волкова
> > > Тел. : +7 (911) 116-71-82
> >
> >
>
> Thanks Ash for your reply, I am aligned with what you're saying.
>
> I was not proposing to take away human readable dag_id instead I was
> thinking, why can't we create another field like dag_name which will hold
> this information at all front facing sites while dag_id is changed to
> integer, this will help in making joins work faster in metastore. Though,
> currently dag_id is indexed but still indexing int (4 bytes) vs
> varchar(250) are going to take more index blocks and therefore more look up
> time. Also, if dag_id is not trivial to change to int, let it be present
> and let's introduce another col which is actually integer in type and let
> joining happen on this column across all tables.
>


-- 
_

С уважением, Юлия Волкова
Тел. : +7 (911) 116-71-82