Ah, thanks Duo, now I understand you. I see your point about how Github Issues could help to enhance the community. I didn't realize that email has become so old-fashioned, but then one of my colleagues just created an internal channel that imports mail to this dev list...
I'm personally fine with adopting more features of Github, despite very real concerns from Apache about self-hosting. Should the HBase developer community be beholden to the whims of any company? However, short of ASF infra beefing up its capabilities, or we the HBase developer community taking infrastructure into our own hands (I think we can get VMs provisioned...), adopting more capabilities out of Github does seem like a practical path forward. What I don't want is multiple places of authority for reporting bugs, tracking changes, managing releases. I think this is a fruitful discussion but has wondered a bit off topic. Might I suggest that we split this off to a separate discussion? I'd like to see how folks are thinking specifically around CI. Thanks, Nick On Wed, Oct 9, 2024 at 5:04 AM 张铎(Duo Zhang) <palomino...@gmail.com> wrote: > About github issues, I'm only talking about how to enlarge the > community, not about other things. For now using github issues and > github actions are independent, unless we plan to move off from jira > too in the future. > > To be honest, most developers in China today do not use email any > more, enabling github issues will give them a good place to ask > questions and discuss things. We do not need to change our current > workflow, we still use jira for issue management. > There are Apache projects that use github issues for issue management > so I think there are ways to not break the ASF policy when using > github issues, like sending all things to issues at a.o? > > Thanks. > > Istvan Toth <st...@cloudera.com.invalid> 于2024年10月8日周二 18:08写道： > > > > I'm not sure about enabling github issues. > > > > We already have the mailing lists, JIRA, and the pull requests to keep > > track of, I'm afraid that adding another forum would overcomplicate > things. > > > > IMO migrating to GH actions and using GH issues are independent from each > > other. > > > > The current JIRA signup process is definitely bad, we are often supposed > to > > be making decisions on cutesy usernames without > > any real context, and we cannot even ask for more information. > > > > Maybe we could add some kind of form to the docs where we list some > > questions from ppl trying to sign up that would be too much work > > for a spammer ? > > > > Istvan > > > > > > > > > > On Tue, Oct 8, 2024 at 9:30 AM 张铎(Duo Zhang) <palomino...@gmail.com> > wrote: > > > > > Oh, typo, PMCs -> PMC members > > > > > > 张铎(Duo Zhang) <palomino...@gmail.com> 于2024年10月8日周二 11:46写道： > > > > > > > > For me I think we could first enable the github issues, for users to > > > > ask questions and discuss things. And if there are actual bugs or > > > > something which require code changes, we could file an jira, and also > > > > let the contributor to register a jira account. > > > > I think this is also easier for our PMCs to decide whether a jira > > > > account is necessary for a given user comparing to the current > > > > workflow. The private mailing list is full of jira registrations > > > > notifications and hard to find other useful information... > > > > > > > > And on moving to github actions, in general I'm +1 on this. We should > > > > try to follow modern ways. > > > > > > > > And on the funding side, we still have 10 machines, we could contact > > > > INFRA to see how to make use of these machines if we switch to github > > > > actions. > > > > > > > > Thanks. > > > > > > > > Istvan Toth <st...@cloudera.com.invalid> 于2024年10月2日周三 17:31写道： > > > > > > > > > > I've been working on modifying the existing Jenkinsfile, and it has > > > been a > > > > > horrible experience, especially as I'm trying to mix declarative > and > > > > > scripted syntax. > > > > > I think from a usability standpoint GH actions would be a win. > > > > > > > > > > On the other hand, our Jenkinsfiles don't do that much, as most of > the > > > > > actual CI process is performed via Yetus, so migration shouldn't > be a > > > huge > > > > > amount of work. > > > > > > > > > > I seem to recall seeing similar discussions on ASF mailing lists, > but I > > > > > haven't followed them closely. > > > > > > > > > > Istvan > > > > > > > > > > Istvan > > > > > > > > > > On Wed, Oct 2, 2024 at 11:23 AM Nick Dimiduk <ndimi...@apache.org> > > > wrote: > > > > > > > > > > > Heya, > > > > > > > > > > > > I'd like to take the community temperature on migrating our build > > > infra > > > > > > from the ci-hbase.a.o Jenkins instance to something built on > GitHub > > > > > > Actions. I have several reasons that justify this proposal. > > > > > > > > > > > > As some of you may know, our community funding has reduced and we > > > will no > > > > > > longer be able to sustain the current fleet of build > infrastructure. > > > So, > > > > > > one motivation for this proposal is cost-cutting: I think that > we'll > > > be > > > > > > able to operate at lower costs if we can migrate to a > > > provisioned-as-needed > > > > > > model of consumption. > > > > > > > > > > > > My second reason is an optimistic appeal to a larger contributor > > > base. I > > > > > > suspect that if we can modernize our infrastructure then we will > > > increase > > > > > > the pool of contributors who might be able to participate in this > > > area. I > > > > > > believe that GH Actions (and systems like it) is more prevalent > in > > > the > > > > > > industry than Jenkins, which means that more people already have > > > experience > > > > > > with the platform and more people will feel compelled to offer > > > support to > > > > > > an OSS project that uses the platform as a means of growing > their own > > > > > > skillset and as a means of bolstering their CVs. > > > > > > > > > > > > Dove-tailed into reason two is reason three: I believe that > there is > > > a > > > > > > large community of folks who are developing GitHub Actions on its > > > > > > marketplace. We would effectively open ourselves up to more > > > off-the-shelf > > > > > > offerings and those offerings would be in our hands directly. By > > > contrast, > > > > > > I don't think there's as much development in Jenkins plugins, > and the > > > > > > process of adding a new plugin to our Jenkins instance requires > > > filing an > > > > > > INFRA ticket. > > > > > > > > > > > > These are my motivations. I'm still not clear on what's possible > yet > > > for > > > > > > ASF projects. I have filed an INFRA ticket, requesting whatever > is > > > > > > necessary for us to start an experiment. Indeed, I believe that > > > there are > > > > > > some major limitations on the current implementation provided by > the > > > ASF, > > > > > > and as far as I can tell, only one project with a build footprint > > > that > > > > > > resembles HBase has pursued this effort. I've catalogued the > > > applicable > > > > > > information that I've found so far on that issue. > > > > > > > > > > > > https://issues.apache.org/jira/browse/INFRA-26170 > > > > > > > > > > > > Thanks, > > > > > > Nick > > > > > > > > > > > > > > > > > > > > > -- > > > > > *István Tóth* | Sr. Staff Software Engineer > > > > > *Email*: st...@cloudera.com > > > > > cloudera.com <https://www.cloudera.com> > > > > > [image: Cloudera] <https://www.cloudera.com/> > > > > > [image: Cloudera on Twitter] <https://twitter.com/cloudera> > [image: > > > > > Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: > > > Cloudera > > > > > on LinkedIn] <https://www.linkedin.com/company/cloudera> > > > > > ------------------------------ > > > > > ------------------------------ > > > > > > > > > -- > > *István Tóth* | Sr. Staff Software Engineer > > *Email*: st...@cloudera.com > > cloudera.com <https://www.cloudera.com> > > [image: Cloudera] <https://www.cloudera.com/> > > [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: > > Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: > Cloudera > > on LinkedIn] <https://www.linkedin.com/company/cloudera> > > ------------------------------ > > ------------------------------ >
