Agreed. I've requested a new private mailing list [1] [1] https://issues.apache.org/jira/browse/INFRA-23898
On Sat, Nov 12, 2022 at 12:09 PM Márton Balassi <balassi.mar...@gmail.com> wrote: > Hi Martjin, > > Given the situation let us set up the Jira signup mailing list following > the Calcite model. This seems the most sensible to me as of now. > > On Fri, Nov 11, 2022 at 7:26 PM Martijn Visser <martijnvis...@apache.org> > wrote: > > > Hi everyone, > > > > Unfortunately ASF Infra has already implemented the change and new Jira > > users can't sign up. > > > > I think there is consensus that we shouldn't move from Jira now. My > > proposal would be to setup a separate mailing list to which users can > send > > their request for an account, which gets sent to the PMC so they can > create > > accounts for them. I don't see any other short term solution. > > > > If agreed, let's open up a vote thread on this. > > > > Thanks, Martijn > > > > > > Op do 3 nov. 2022 om 04:51 schreef Xintong Song <tonysong...@gmail.com> > > > > > Thanks all for the valuable feedback, opinions and suggestions. > > > > > > # Option 1. > > > I know this is the first choice for pretty much everyone. Many people > > from > > > the Flink community (including myself) have shared their opinion with > > > Infra. However, based on the feedback so far, TBH I don't think things > > > would turn out the way we want. I don't see what else we can do. Does > > > anyone have more suggestions on this option? Or we probably have to > > > scratch it out of the list. > > > > > > # Option 4. > > > Seems there are also quite some concerns on using solely GH issues: > > limited > > > features (thus the significant changes to the current issue/release > > > management processes), migration cost, source of truth, etc. I think > I'm > > > also convinced that this may not be a good choice. > > > > > > # Option 2 & 3. > > > Between the two options, I'm leaning towards option 2. > > > - IMO, making it as easy as possible for users to report issues should > > be a > > > top priority. Having to wait for a human response for creating an > account > > > does not meet that requirement. That makes a strong objection to > option 3 > > > from my side. > > > - Using GH issues for consumer-facing issues and reflecting the valid > > ones > > > back to Jira (either manually by committers or by bot) sounds good to > me. > > > The status (open/closed) and labels should make tracking the issues > > easier > > > compared to in mailing lists / slack, in terms of whether an issue has > > been > > > taken care of / reflected to Jira / closed as invalid. That does not > mean > > > we should not reflect things from mailing lists / slack to Jira. > Ideally, > > > we leverage every possible channel for collecting user issues / > feedback, > > > while guiding / suggesting users to choose GH issues over the others. > > > - For new contributors, they still need to request an account from a > PMC > > > member. They can even make that request on GH issues, if they do not > mind > > > posting the email address publicly. > > > - I would not be worried very much about the privacy issue, if the Jira > > > account creation is restricted to contributors. Contributors are > exposing > > > their email addresses publicly anyway, in dev@ mailing list and commit > > > history. I'm also not strongly against creating a dedicated mailing > list > > > though. > > > > > > Best, > > > > > > Xintong > > > > > > > > > > > > On Wed, Nov 2, 2022 at 9:16 PM Chesnay Schepler <ches...@apache.org> > > > wrote: > > > > > > > Calcite just requested a separate mailing list for users to request a > > > > JIRA account. > > > > > > > > > > > > I think I'd try going a similar route. While I prefer the openness of > > > > github issues, they are really limited, and while some things can be > > > > replicated with labels (like fix versions / components), things like > > > > release notes can't. > > > > We'd also lose a central place for collecting issues, since we'd have > > to > > > > (?) scope issues per repo. > > > > > > > > I wouldn't want to import everything into GH issues (it's just a > flawed > > > > approach in the long-term imo), but on the other hand I don't know if > > > > the auto linker even works if it has to link to either jira or a GH > > > issue. > > > > > > > > Given that we need to change workflows in any case, I think I'd > prefer > > > > sticking to JIRA. > > > > For reported bugs I'd wager that in most cases we can file the > tickets > > > > ourselves and communicate with users on slack/MLs to gather all the > > > > information. I'd argue that if we'd had been more pro-active with > > filing > > > > tickets for user issues (instead of relying on them to do it) we > > > > would've addressed several issues way sooner. > > > > > > > > Additionally, since either option would be a sort of experiment, then > > > > JIRA is a safer option. We have to change less and there aren't any > > > > long-term ramifications (like having to re-import GH tickets into > > JIRA). > > > > > > > > On 28/10/2022 16:49, Piotr Nowojski wrote: > > > > > Hi, > > > > > > > > > > I'm afraid of the migration cost to only github issues and lack of > > many > > > > > features that we are currently using. That would be very disruptive > > and > > > > > annoying. For me github issues are far worse compared to using the > > > Jira. > > > > > > > > > > I would strongly prefer Option 1. over the others. Option 4 I would > > > like > > > > > the least. I would be fine with Option 3, and Option 2 but assuming > > > that > > > > > Jira would stay the source of truth. > > > > > For option 2, maybe we could have a bot that would backport/copy > user > > > > > created issues in github to Jira (and link them together)? > > Discussions > > > > > could still happen in the github, but we could track all of the > > issues > > > as > > > > > we are doing right now. Bot could also sync it the other way around > > > (like > > > > > marking tickets closed, affected/fixed versions etc). > > > > > > > > > > Best, > > > > > Piotrek > > > > > > > > > > czw., 27 paź 2022 o 07:48 Martijn Visser <martijnvis...@apache.org > > > > > > > napisał(a): > > > > > > > > > >> Hi, > > > > >> > > > > >> We have to keep in mind that if a users asks for a new Jira > account, > > > > that > > > > >> person will need to provide its email address which is the Flink > PMC > > > > >> processing personal identifiable information. There needs to be a > > > > careful > > > > >> process for that and to be honest, I don't think the ASF should do > > > this > > > > >> from a privacy perspective. > > > > >> > > > > >> As an example, the Calcite community decided to create a > dedicated, > > > > private > > > > >> list where users can ask for an account to avoid making the email > > > > address > > > > >> public. > > > > >> > > > > >> Best regards, > > > > >> > > > > >> Martijn > > > > >> > > > > >> Op wo 26 okt. 2022 om 22:31 schreef Danny Cranmer < > > > > dannycran...@apache.org > > > > >>> Hello, > > > > >>> > > > > >>> I agree with Gyula. My preference is also option 1, and as a > > fallback > > > > >>> option 3. Handling new user account requests will be manageable, > > > > >> especially > > > > >>> via slack. We could setup a dedicated channel for people to ask > for > > > > >>> Jira/wiki access. > > > > >>> > > > > >>> Thanks, > > > > >>> Danny > > > > >>> > > > > >>> On Wed, 26 Oct 2022, 12:16 Gyula Fóra, <gyf...@apache.org> > wrote: > > > > >>> > > > > >>>> Hi! > > > > >>>> > > > > >>>> I would also personally prefer staying with JIRA given the > feature > > > set > > > > >>> and > > > > >>>> the past positive experience with it. > > > > >>>> I think the structured nature of JIRA with flexible components, > > > issue > > > > >>>> types, epics, release handling etc have been a great benefit to > > the > > > > >>>> project, it would be a shame to give some of these up. > > > > >>>> > > > > >>>> If for some reason Option 1 is not possible, I would still > prefer > > > > >> Option > > > > >>> 3 > > > > >>>> (requiring new contributors to ask for JIRA access) compared to > > the > > > > >>>> alternatives. > > > > >>>> > > > > >>>> Cheers, > > > > >>>> Gyula > > > > >>>> > > > > >>>> > > > > >>>> On Tue, Oct 25, 2022 at 3:48 PM Robert Metzger < > > rmetz...@apache.org > > > > > > > > >>>> wrote: > > > > >>>> > > > > >>>>> Thank you for starting this discussion Xintong! > > > > >>>>> > > > > >>>>> I would also prefer option 1. > > > > >>>>> > > > > >>>>> The ASF Jira is probably one of the largest, public Jira > > instances > > > on > > > > >>> the > > > > >>>>> internet. Most other Jiras are internal within companies, so > > > > >> Atlassian > > > > >>> is > > > > >>>>> probably not putting a lot of effort into automatically > detecting > > > and > > > > >>>>> preventing spam and malicious account creation. > > > > >>>>> If we want to convince Infra to keep the current sign up > process, > > > we > > > > >>>>> probably need to help them find a solution for the problem. > > > > >>>>> Maybe we can configure the ASF Jira to rely on GitHub as an > > > identity > > > > >>>>> provider? I've just proposed that in the discussion on > > > > >>>>> us...@infra.apache.org, let's see ;) > > > > >>>>> > > > > >>>>> Best, > > > > >>>>> Robert > > > > >>>>> > > > > >>>>> > > > > >>>>> On Tue, Oct 25, 2022 at 2:08 PM Konstantin Knauf < > > > kna...@apache.org> > > > > >>>>> wrote: > > > > >>>>> > > > > >>>>>> Hi everyone, > > > > >>>>>> > > > > >>>>>> while I see some benefits in moving to Github Issues > completely, > > > we > > > > >>>> need > > > > >>>>> to > > > > >>>>>> be aware that Github Issues lacks many features that Jira has. > > > From > > > > >>> the > > > > >>>>> top > > > > >>>>>> of my head: > > > > >>>>>> * there are no issue types > > > > >>>>>> * no priorities > > > > >>>>>> * issues can only be assigned to one milestone > > > > >>>>>> So, you need to work a lot with labels and conventions and > > > > >> basically > > > > >>>> need > > > > >>>>>> bots or actions to manage those. Agreeing on those processes, > > > > >> setting > > > > >>>>> them > > > > >>>>>> up and getting used to them will be a lot of work for the > > > > >> community. > > > > >>>>>> So, I am also in favor of 1) for now, because I don't really > > see a > > > > >>> good > > > > >>>>>> alternative option. > > > > >>>>>> > > > > >>>>>> Cheers, > > > > >>>>>> > > > > >>>>>> Konstantin > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Am Mo., 24. Okt. 2022 um 22:27 Uhr schrieb Matthias Pohl > > > > >>>>>> <matthias.p...@aiven.io.invalid>: > > > > >>>>>> > > > > >>>>>>> I agree that leaving everything as is would be the best > > option. I > > > > >>>> also > > > > >>>>>> tend > > > > >>>>>>> to lean towards option 4 as a fallback for the reasons > already > > > > >>>>> mentioned. > > > > >>>>>>> I'm still not a big fan of the Github issues. But that's > > probably > > > > >>>> only > > > > >>>>>>> because I'm used to the look-and-feel and the workflows of > > Jira. > > > > >> I > > > > >>>> see > > > > >>>>>>> certain benefits of moving to Github, though. We're still > > having > > > > >>> the > > > > >>>>> idea > > > > >>>>>>> of migrating from AzureCI to GitHub Actions. Moving the > issues > > to > > > > >>>>> GitHub > > > > >>>>>> as > > > > >>>>>>> well might improve the user experience even more. Reducing > the > > > > >>> number > > > > >>>>> of > > > > >>>>>>> services a new contributor should be aware of to reach the > > > > >>> community > > > > >>>>> is a > > > > >>>>>>> good way to reduce the confusion for newcomers, I could > > imagine. > > > > >>>>>>> Additionally, I also like the fact that I wouldn't have to > > bother > > > > >>>> about > > > > >>>>>> the > > > > >>>>>>> Apache Jira markdown anymore. 8) > > > > >>>>>>> > > > > >>>>>>> I agree with Martijn's concern about not being able to track > > all > > > > >>>>>>> Flink-related issues in a single system. I'm just wondering > > > > >> whether > > > > >>>>>>> something is holding us back from collecting all > Flink-related > > > > >>> issues > > > > >>>>> in > > > > >>>>>>> the Flink's Github repository and disabling the issue feature > > in > > > > >>> any > > > > >>>>>> other > > > > >>>>>>> Flink-related repository? > > > > >>>>>>> > > > > >>>>>>> About migrating the Jira issues: I would be hopeful that > > > > >> migrating > > > > >>> is > > > > >>>>>>> doable in the end. There is a blog post from the spring data > > guys > > > > >>>> about > > > > >>>>>>> their journey on migrating from Jira to GitHub issues [1]. > > > > >>>>> Unfortunately, > > > > >>>>>>> they didn't provide any scripts. > > > > >>>>>>> > > > > >>>>>>> For the case that infra moves forward with disabling the > signup > > > > >>>> without > > > > >>>>>> us > > > > >>>>>>> having come up with a decision and its actual execution (i.e. > > > > >>>> migrating > > > > >>>>>> the > > > > >>>>>>> Jira issues to GH), I would prefer having users send a > request > > to > > > > >>> the > > > > >>>>>>> mailing list. I would rather have a temporary phase where > > > > >> there's a > > > > >>>> bit > > > > >>>>>> of > > > > >>>>>>> overhead of registering the users in the Apache Jira than > > having > > > > >>> two > > > > >>>>>>> locations for bug tracking. I suspect that there are no > > > > >> statistics > > > > >>> on > > > > >>>>> how > > > > >>>>>>> many new users register with Jira in a given timeframe to > > > > >>> contribute > > > > >>>> to > > > > >>>>>>> Flink? > > > > >>>>>>> > > > > >>>>>>> Matthias > > > > >>>>>>> > > > > >>>>>>> [1] > > > > >>>>>>> > > > > >>>>>>> > > > > >> > > > > > > > > > > https://spring.io/blog/2021/01/07/spring-data-s-migration-from-jira-to-github-issues > > > > >>>>>>> [2] > > > > >>> https://lists.apache.org/thread/pjb5jzvw41xjtzgf4w0gggpqrt2fq6ov > > > > >>>>>>> > > > > >>>>>>> On Mon, Oct 24, 2022 at 10:28 AM Xintong Song < > > > > >>> tonysong...@gmail.com > > > > >>>>>>> wrote: > > > > >>>>>>> > > > > >>>>>>>> I agree with you that option 1) would be the best for us. > > Let's > > > > >>>> keep > > > > >>>>>>> hoping > > > > >>>>>>>> for the best. > > > > >>>>>>>> > > > > >>>>>>>> Option 4), as you said, comes with prices. At the moment, I > > > > >> don't > > > > >>>>> have > > > > >>>>>>>> thorough answers to your questions. > > > > >>>>>>>> > > > > >>>>>>>> Just one quick response, I think there's a good chance that > we > > > > >>> can > > > > >>>>>> import > > > > >>>>>>>> current Jira tickets into GH. Jira supports exporting issues > > > > >> with > > > > >>>>>> fields > > > > >>>>>>>> that you specified as CSV/XML/... files. With a brief google > > > > >>>> search, > > > > >>>>> I > > > > >>>>>>>> found some tools that help bulk creating issues in GH. E.g., > > > > >>>>>>>> github-csv-tools [1] is described to support importing > issues > > > > >>> with > > > > >>>>>> title, > > > > >>>>>>>> body, labels, status and milestones from a CSV file. That's > > > > >>>> probably > > > > >>>>>> good > > > > >>>>>>>> enough for us to search/filter the issues in GH, and a link > to > > > > >>> the > > > > >>>>> Jira > > > > >>>>>>>> ticket can be posted in the GH issue for complete > conversation > > > > >>>>> history > > > > >>>>>>> and > > > > >>>>>>>> other details. > > > > >>>>>>>> > > > > >>>>>>>> Best, > > > > >>>>>>>> > > > > >>>>>>>> Xintong > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>> [1] https://github.com/gavinr/github-csv-tools > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>> > > > > >>>>>>>> On Mon, Oct 24, 2022 at 3:58 PM Martijn Visser < > > > > >>>>>> martijnvis...@apache.org > > > > >>>>>>>> wrote: > > > > >>>>>>>> > > > > >>>>>>>>> Hi Xintong, > > > > >>>>>>>>> > > > > >>>>>>>>> I'm also not in favour of option 2, I think that two > systems > > > > >>> will > > > > >>>>>>> result > > > > >>>>>>>>> in an administrative burden and less-efficient workflow. > I'm > > > > >>> also > > > > >>>>> not > > > > >>>>>>> in > > > > >>>>>>>>> favour of option 3, I think that this will result in first > > > > >> time > > > > >>>>>>>>> users/contributors in not-filling their first bug report, > > > > >> user > > > > >>>>>> question > > > > >>>>>>>> or > > > > >>>>>>>>> feature request. > > > > >>>>>>>>> > > > > >>>>>>>>> I'm still hoping for option 1 while the discussion is not > > > > >>>> finished > > > > >>>>>> with > > > > >>>>>>>>> Infra. > > > > >>>>>>>>> > > > > >>>>>>>>> If we assume that option 1 won't be possible, then I think > > > > >>>> option 4 > > > > >>>>>>> will > > > > >>>>>>>>> be the best-option-left. I'm not necessarily in favour, > > > > >> because > > > > >>>> of > > > > >>>>> a > > > > >>>>>>>> number > > > > >>>>>>>>> of problems it will introduce: > > > > >>>>>>>>> > > > > >>>>>>>>> 1. I don't think importing current Jira tickets into Github > > > > >>>> Issues > > > > >>>>>> is a > > > > >>>>>>>>> realistic option. So we would have two administrations. > > > > >> Before > > > > >>>> you > > > > >>>>>>>> create a > > > > >>>>>>>>> new ticket, you should check if it exists both as a Jira > > > > >> ticket > > > > >>>> and > > > > >>>>>> as > > > > >>>>>>> a > > > > >>>>>>>>> Github Issue. > > > > >>>>>>>>> 2. How would we deal with completing a PR? There must be > one > > > > >>>>>>>>> administration leading for the changelog generation (to > avoid > > > > >>>> that > > > > >>>>>>> you're > > > > >>>>>>>>> missing an item), which could then only be Github Issues. > So > > > > >>>> would > > > > >>>>> we > > > > >>>>>>>>> require all PRs that are merged to exist as a Github Issue? > > > > >>>>>>>>> 3. There's no longer one central administration, which is > > > > >>>>> especially > > > > >>>>>>>>> valuable to track all issues across projects like the > > > > >> different > > > > >>>>>>>> connectors, > > > > >>>>>>>>> Flink ML, Table Store etc. > > > > >>>>>>>>> 4. Our current CI labeling works on the Jira issues, not on > > > > >> the > > > > >>>>>> Github > > > > >>>>>>>>> Issues labels. > > > > >>>>>>>>> > > > > >>>>>>>>> Best regards, > > > > >>>>>>>>> > > > > >>>>>>>>> Martijn > > > > >>>>>>>>> > > > > >>>>>>>>> On Mon, Oct 24, 2022 at 7:29 AM Xintong Song < > > > > >>>>> tonysong...@gmail.com> > > > > >>>>>>>>> wrote: > > > > >>>>>>>>> > > > > >>>>>>>>>> Hi devs and users, > > > > >>>>>>>>>> > > > > >>>>>>>>>> As many of you may have already noticed, Infra announced > > > > >> that > > > > >>>> they > > > > >>>>>>> will > > > > >>>>>>>>>> soon disable public Jira account signups [1]. That means, > in > > > > >>>> order > > > > >>>>>> for > > > > >>>>>>>>>> someone who is not yet a Jira user to open or comment on > an > > > > >>>> issue, > > > > >>>>>>>> he/she > > > > >>>>>>>>>> has to first reach out to a PMC member to create an > account > > > > >>> for > > > > >>>>>>> him/her. > > > > >>>>>>>>>> This raises the bar for new contributors and users to > > > > >>>> participate > > > > >>>>> in > > > > >>>>>>>>>> community interactions, making it necessary for us to > > > > >> consider > > > > >>>>>> whether > > > > >>>>>>>> (and > > > > >>>>>>>>>> how) we should change our issue tracking workflows. > > > > >>>>>>>>>> > > > > >>>>>>>>>> I can see a few possible options. > > > > >>>>>>>>>> > > > > >>>>>>>>>> 1. Reaching out to Infra and trying to change their mind > on > > > > >>> this > > > > >>>>>>>>>> decision. I’ve already been trying this [2], and so far > the > > > > >>>>> feedback > > > > >>>>>>>> seems > > > > >>>>>>>>>> unoptimistic. > > > > >>>>>>>>>> 2. Using both Jira (for development issues) & Github > Issues > > > > >>> (for > > > > >>>>>>>>>> customer-facing issues), as Infra suggested. > > > > >>>>>>>>>> 3. Stay with using Jira only, so that new Jira users need > to > > > > >>> ask > > > > >>>>> on > > > > >>>>>>> the > > > > >>>>>>>>>> mailing lists / Slack for creating accounts. > > > > >>>>>>>>>> 4. Migrating to Github Issues completely. > > > > >>>>>>>>>> > > > > >>>>>>>>>> Personally, I’m leaning toward option 4). > > > > >>>>>>>>>> > > > > >>>>>>>>>> TBH, I don’t see any good reason for option 2). I’d expect > > > > >>> using > > > > >>>>> two > > > > >>>>>>>>>> different issue tracking tools at the same time would be > > > > >>> complex > > > > >>>>> and > > > > >>>>>>>>>> chaotic. Option 3) is probably more friendly to existing > > > > >>>>> developers > > > > >>>>>>> and > > > > >>>>>>>>>> users, while being less friendly to newcomers. Option 4) > on > > > > >>> the > > > > >>>>>>>> contrary, > > > > >>>>>>>>>> is more friendly to newcomers, at some migration cost > which > > > > >>>> might > > > > >>>>> be > > > > >>>>>>>>>> non-trivial but once for all. > > > > >>>>>>>>>> > > > > >>>>>>>>>> Github issues have been widely used by many open source > > > > >>>> projects, > > > > >>>>>>>>>> including Kubernetes, Flink CDC, and Apache projects > Iceberg > > > > >>> and > > > > >>>>>>>> Airflow. > > > > >>>>>>>>>> With a set of well-designed labels, we should be able to > > > > >>> achieve > > > > >>>>>> most > > > > >>>>>>> of > > > > >>>>>>>>>> the Jira functions / features that we currently rely on. > > > > >>>> Moreover, > > > > >>>>>> it > > > > >>>>>>>>>> better integrates the issue tracking and code contributing > > > > >>>>> systems, > > > > >>>>>>> and > > > > >>>>>>>>>> would be easier to access (I believe there’s more GH users > > > > >>> than > > > > >>>>>> Jira / > > > > >>>>>>>>>> mailing lists). > > > > >>>>>>>>>> > > > > >>>>>>>>>> All in all, I’d suggest to keep monitoring Infra’s > feedback > > > > >> on > > > > >>>>>> option > > > > >>>>>>>> 1), > > > > >>>>>>>>>> while taking steps (investigation, workflow & label > design) > > > > >>>>>> preparing > > > > >>>>>>>> for > > > > >>>>>>>>>> option 4). > > > > >>>>>>>>>> > > > > >>>>>>>>>> Looking forward to hearing what you think about this. > > > > >>>>>>>>>> > > > > >>>>>>>>>> Best, > > > > >>>>>>>>>> > > > > >>>>>>>>>> Xintong > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> [1] > > > > >>>>>> > > https://lists.apache.org/thread/jx9d7sp690ro660pjpttwtg209w3m39w > > > > >>>>>>>>>> [2] > > > > >>>>>> > > https://lists.apache.org/thread/fjjtk30dxf6fyoo4q3rmkhh028or40fw > > > > >>>>>>>>>> > > > > >>>>>> > > > > >>>>>> -- > > > > >>>>>> https://twitter.com/snntrable > > > > >>>>>> https://github.com/knaufk > > > > >>>>>> > > > > >> -- > > > > >> Martijn > > > > >> https://twitter.com/MartijnVisser82 > > > > >> https://github.com/MartijnVisser > > > > >> > > > > > > > > > > > > > -- > > Martijn > > https://twitter.com/MartijnVisser82 > > https://github.com/MartijnVisser > > >
