Thanks for volunteering, Marton. Since the discussion has been open for quite long and no one else is volunteering, I'll reply to the INFRA with the list of 4 maintainers (Xintong, Jinsong, Till, Marton).
Thank you~ Xintong Song On Sat, May 7, 2022 at 3:15 PM Márton Balassi <balassi.mar...@gmail.com> wrote: > Hi team, > > I volunteer for the flink-kubernetes-operator repo. > > On Fri, May 6, 2022 at 1:42 PM Xintong Song <tonysong...@gmail.com> wrote: > > > @Till, > > > > Thanks for volunteering. > > > > @Konstantin, > > > > From my experience, the effort that requires DockerHub access in the main > > project release process is quite limited. I helped Yun Gao on releasing > the > > 1.15.0 images, and what I did was just check out the `flink-docker` repo > > and run the release script, that's it. If all the sub-projects are as > easy > > as the main project, then it's probably ok that only a small group of > > people have access. Concerning the redundancy, if a maintainer from a > > sub-project is temporarily unreachable, I believe the other maintainers > > would be glad to help. > > > > It would of course be good to have more seats. I just haven't come up > with > > good reasons to persuade the INFRA folks. What's your suggestions? > > > > > > Thank you~ > > > > Xintong Song > > > > > > > > On Fri, May 6, 2022 at 6:38 PM Konstantin Knauf <kna...@apache.org> > wrote: > > > > > Hi Xintong, > > > > > > it is a pity that we can only have 5 maintainers. Every (patch) release > > of > > > flink, flink-statefun, the flink-kubernetes-operator requires a > > maintainer > > > to publish the image then, if I am not mistaken. As its mostly > different > > > groups managing the sub-projects, this is quite the bottleneck. If we > > give > > > one seat to flink-statefun maintainers, one to the > > > flink-kubernetes-operator maintainers, this leaves three seats for > Apache > > > Flink core, and there is no redundancy for the other projects. When I > > > managed the last two patch releases, the DockerHub access was also the > > > biggest hurdle. Maybe we can talk to the INFRA people again. We can > > > certainly reduce it, but 5 is very little. > > > > > > Cheers, > > > > > > Konstantin > > > > > > > > > > > > > > > > > > > > > Am Fr., 6. Mai 2022 um 09:00 Uhr schrieb Till Rohrmann < > > > trohrm...@apache.org > > > >: > > > > > > > Hi everyone, > > > > > > > > thanks for starting this discussion Xintong. I would volunteer as a > > > > maintainer of the flink-statefun Docker repository if you need one. > > > > > > > > Cheers, > > > > Till > > > > > > > > On Fri, May 6, 2022 at 6:22 AM Xintong Song <tonysong...@gmail.com> > > > wrote: > > > > > > > >> It seems to me we at least don't have a consensus on dropping the > use > > of > > > >> apache namespace, which means we need to decide on a list of > > maintainers > > > >> anyway. So maybe we can get the discussion back to the maintainers. > We > > > may > > > >> continue the official-image vs. apache-namespace in a separate > thread > > if > > > >> necessary. > > > >> > > > >> As mentioned previously, we need to reduce the number of maintainers > > > from > > > >> 20 to 5, as required by INFRA. Jingsong and I would like to > volunteer > > > as 2 > > > >> of the 5, and we would like to learn who else wants to join us. Of > > > course > > > >> the list of maintainers can be modified later. > > > >> > > > >> *This also means the current maintainers may be removed from the > > list.* > > > >> Please let us know if you still need that privilege. CC-ed all the > > > current > > > >> maintainers for attention. > > > >> > > > >> Thank you~ > > > >> > > > >> Xintong Song > > > >> > > > >> > > > >> > > > >> On Wed, May 4, 2022 at 3:14 PM Chesnay Schepler <ches...@apache.org > > > > > >> wrote: > > > >> > > > >> > One advantage is that the images are periodically rebuilt to get > > > >> > security fixes. > > > >> > > > > >> > The operator is a different story anyway because it is AFAIK only > > > >> > supposed to be used via docker > > > >> > (i.e., no standalone mode), which alleviates concerns about > keeping > > > the > > > >> > logic within the image > > > >> > to a minimum (which bit us in the past on the flink side). > > > >> > > > > >> > On 03/05/2022 16:09, Yang Wang wrote: > > > >> > > The flink-kubernetes-operator project is only published > > > >> > > via apache/flink-kubernetes-operator on docker hub and github > > > >> packages. > > > >> > > We do not find the obvious advantages by using docker hub > official > > > >> > images. > > > >> > > > > > >> > > Best, > > > >> > > Yang > > > >> > > > > > >> > > Xintong Song <tonysong...@gmail.com> 于2022年4月28日周四 19:27写道： > > > >> > > > > > >> > >> I agree with you that doing QA for the image after the release > > has > > > >> been > > > >> > >> finalized doesn't feel right. IIUR, that is mostly because > > official > > > >> > image > > > >> > >> PR needs 1) the binary release being deployed and propagated > and > > 2) > > > >> the > > > >> > >> corresponding git commit being specified. I'm not completely > sure > > > >> about > > > >> > >> this. Maybe we can improve the process by investigating more > > about > > > >> the > > > >> > >> feasibility of pre-verifying an official image PR before > > finalizing > > > >> the > > > >> > >> release. It's definitely a good thing to do if possible. > > > >> > >> > > > >> > >> I also agree that QA from DockerHub folks is valuable to us. > > > >> > >> > > > >> > >> I'm not against publishing official-images, and I'm not against > > > >> working > > > >> > >> closely with the DockerHub folks to improve the process of > > > delivering > > > >> > the > > > >> > >> official image. However, I don't think these should become > > reasons > > > >> that > > > >> > we > > > >> > >> don't release our own apache/flink images. > > > >> > >> > > > >> > >> Taking the 1.12.0 as an example, admittedly it would be nice > for > > us > > > >> to > > > >> > >> comply with the DockerHub folks' standards and not have a > > > >> > >> just-for-kubernetes command in our entrypoint. However, this is > > IMO > > > >> far > > > >> > >> less important compared to delivering the image to our users > > > timely. > > > >> I > > > >> > >> guess that's where the DockerHub folks and us have different > > > >> > >> priorities, and that's why I think we should have a path that > is > > > >> fully > > > >> > >> controlled by this community to deliver images. We could take > > their > > > >> > >> valuable inputs and improve afterwards. Actually, that's what > we > > > did > > > >> for > > > >> > >> 1.12.0 by starting to release to apache/flink. > > > >> > >> > > > >> > >> Thank you~ > > > >> > >> > > > >> > >> Xintong Song > > > >> > >> > > > >> > >> > > > >> > >> > > > >> > >> On Thu, Apr 28, 2022 at 6:30 PM Chesnay Schepler < > > > ches...@apache.org > > > >> > > > > >> > >> wrote: > > > >> > >> > > > >> > >>> I still think that's mostly a process issue. > > > >> > >>> Of course we can be blind-sided if we do the QA for a release > > > >> artifact > > > >> > >>> after the release has been finalized. > > > >> > >>> But that's a clearly broken process from the get-go. > > > >> > >>> > > > >> > >>> At the very least we should already open a PR when the RC is > > > >> created to > > > >> > >>> get earlier feedback. > > > >> > >>> > > > >> > >>> Moreover, nowadays the docker images are way slimmer and we > are > > > much > > > >> > >>> more careful on what is actually added to the scripts. > > > >> > >>> > > > >> > >>> Finally, the problems they found did show that their QA is > very > > > >> > valuable > > > >> > >>> to us. And side-stepping that for such an essential piece of a > > > >> release > > > >> > >>> isn't a good idea imo. > > > >> > >>> > > > >> > >>> On 28/04/2022 11:31, Xintong Song wrote: > > > >> > >>>> I'm overall against only releasing to official-images. > > > >> > >>>> > > > >> > >>>> We started releasing to apache/flink, in addition to the > > > >> > >> official-image, > > > >> > >>> in > > > >> > >>>> 1.12.0. That was because releasing the official-image needs > > > >> approval > > > >> > >> from > > > >> > >>>> the DockerHub folks, which is not under control of the Flink > > > >> > community. > > > >> > >>> For > > > >> > >>>> 1.12.0 there were unfortunately some divergences between us > and > > > the > > > >> > >>>> DockerHub folks, and it ended-up taking us nearly 2 months to > > get > > > >> that > > > >> > >>>> official-image PR merged [1][2]. Many users, especially those > > who > > > >> need > > > >> > >>>> Flink's K8s & Native-K8s deployment modes, were asking for > the > > > >> image > > > >> > >>> after > > > >> > >>>> 1.12.0 was announced. > > > >> > >>>> > > > >> > >>>> One could argue that what happened for 1.12.0 is not a > regular > > > >> case. > > > >> > >>>> However, I'd like to point out that the docker images are not > > > >> > something > > > >> > >>>> nice-to-have, but a practically necessary piece of the > release > > > for > > > >> the > > > >> > >>> k8s > > > >> > >>>> / native-k8s deployments to work. I'm strongly against a > > release > > > >> > >> process > > > >> > >>>> where such an important piece depends on the approval of a > 3rd > > > >> party. > > > >> > >>>> > > > >> > >>>> Thank you~ > > > >> > >>>> > > > >> > >>>> Xintong Song > > > >> > >>>> > > > >> > >>>> > > > >> > >>>> [1] https://issues.apache.org/jira/browse/FLINK-20650 > > > >> > >>>> > > > >> > >>>> [2] > > https://github.com/docker-library/official-images/pull/9249 > > > >> > >>>> > > > >> > >>>> > > > >> > >>>> > > > >> > >>>> On Thu, Apr 28, 2022 at 2:43 PM Chesnay Schepler < > > > >> ches...@apache.org> > > > >> > >>> wrote: > > > >> > >>>>> We could just stop releasing to apache/flink and only go for > > the > > > >> > >>>>> official-images route. > > > >> > >>>>> > > > >> > >>>>> On 28/04/2022 07:43, Xintong Song wrote: > > > >> > >>>>>> Forgot to mention that, we have also proposed to use one > > shared > > > >> > >> account > > > >> > >>>>> and > > > >> > >>>>>> limit its access to the PMC members, like what we do with > the > > > >> PyPI > > > >> > >>>>> account. > > > >> > >>>>>> Unfortunately, INFRA rejected this proposal [1]. > > > >> > >>>>>> > > > >> > >>>>>> > > > >> > >>>>>> Thank you~ > > > >> > >>>>>> > > > >> > >>>>>> Xintong Song > > > >> > >>>>>> > > > >> > >>>>>> > > > >> > >>>>>> [1] https://issues.apache.org/jira/browse/INFRA-23208 > > > >> > >>>>>> > > > >> > >>>>>> On Thu, Apr 28, 2022 at 1:39 PM Xintong Song < > > > >> tonysong...@gmail.com > > > >> > > > > > >> > >>>>> wrote: > > > >> > >>>>>>> Hi devs, > > > >> > >>>>>>> > > > >> > >>>>>>> I'd like to start a discussion about maintainers for > > DockerHub > > > >> > >>>>>>> repositories under the *apache* namespace [1]. > > > >> > >>>>>>> > > > >> > >>>>>>> Currently, the Flink community maintains various > > repositories > > > >> > >> (flink, > > > >> > >>>>>>> flink-statefun, flink-statefun-playground, and > > > >> > >>>>> flink-kubernetes-operator) > > > >> > >>>>>>> on DockerHub under the *apache* namespace. There's a > > > limitation > > > >> on > > > >> > >> how > > > >> > >>>>> many > > > >> > >>>>>>> members the *apache* namespace can add, and recently INFRA > > is > > > >> > >>>>> complaining > > > >> > >>>>>>> about Flink taking too many places [2][3]. They would like > > us > > > to > > > >> > >>> reduce > > > >> > >>>>> our > > > >> > >>>>>>> maintainers from 20 now to 5. > > > >> > >>>>>>> > > > >> > >>>>>>> Jingsong and I would like to volunteer as two of the > > > >> maintainers, > > > >> > >> and > > > >> > >>> we > > > >> > >>>>>>> would like to learn who else wants to join us. While any > > > >> committer > > > >> > >> may > > > >> > >>>>>>> serve as one of the maintainers, it's probably nice to > also > > > >> involve > > > >> > >> at > > > >> > >>>>>>> least one maintainer from statefun and one from > > > >> > kubernetes-operator. > > > >> > >>>>>>> > > > >> > >>>>>>> What do you think? > > > >> > >>>>>>> > > > >> > >>>>>>> Thank you~ > > > >> > >>>>>>> > > > >> > >>>>>>> Xintong Song > > > >> > >>>>>>> > > > >> > >>>>>>> > > > >> > >>>>>>> [1] https://hub.docker.com/orgs/apache > > > >> > >>>>>>> > > > >> > >>>>>>> [2] https://issues.apache.org/jira/browse/INFRA-23208 > > > >> > >>>>>>> > > > >> > >>>>>>> [3] https://issues.apache.org/jira/browse/INFRA-23213 > > > >> > >>>>>>> > > > >> > >>>>>>> > > > >> > >>> > > > >> > > > > >> > > > > >> > > > > > > > > > > -- > > > https://twitter.com/snntrable > > > https://github.com/knaufk > > > > > >
