[all][foundation][ecosystem] External projects under the foundation hat

Sean Mooney smooney at redhat.com
Mon Jun 27 12:51:12 UTC 2022


On Mon, 2022-06-27 at 11:39 +0200, Artem Goncharov wrote:
> > > 
> > 
> > The point I was trying to make was more that nothing stops that contribution from happening today on Github if that is where those individuals
> > prefer to be. What changes if the repo moves under the Github openstack organization and we formally add the project to openstack governance?
> > There are some changes for sure, but most aren't going to be visible/important to those individuals.
> > 
> > I'm trying to get us to be explicit about the benefits and cross check them against our goals. I'm not necessarily saying it is a bad idea. It may
> > be that those people want to vote in TC elections and have a greater say in the direction of openstack as a whole. If that is the case let's say
> > that and make sure that benefits like that align with any goals of such a move.
> > 
> > I'm not saying that contributions like that don't benefit the ecosystem. I'm specifically trying to understand what benefits to this specific
> > change there are to both parties. It isn't clear to me if part of the move is explicitly ignoring the way openstack has chosen to do things.
> > 
> 
> Let me give here couple of examples:
> 
> - When I am doing some bigger changes in SDK/OSC/Ansible it is logical to have a devstack running locally to be able to try it out and somehow
> ensure tests will work without burning CI in endless patchsets due to typos and other type of bugs. Chances that I will be able just to start
> devstack on my laptop and it immediately works are terribly low. I am not going to go into details why, this is not relevant here. Due to this in
> most cases, unless I do something much bigger and ready to invest eventually 1-2 hour to get devstack running I skip this and go into the blind
> flight relying only on CI. And as mentioned earlier producing sometimes lot of patchsets.
> - My contributions to Zuul are actually facing very similar challenge. I am able to reverse engineer how to be able to run tests locally, but
> honestly this is not something I really want to do, especially in a fast evolving software. Due to that for fixing one bug I am spending 20
> patchsets and weeks of time (everybody here know perfectly how much time we usually wait for CI results and endless rechecks). With that I honestly
> think twice, do I have enough “free time” and commitement to try fix the bug properly or I have a workaround I can apply in my installation
> - I have seen from other teams, but now talking explicitly about myself: using storyboard is so inconvenient that I just stopped using it (neither
> for reporting myself, nor looking what others report to my projects). I even see often people reusing some external issue trackers just to make it
> somehow usable (I am waiting so desperately for us finally enabling gitea issues)
i dont like storyboard but i have no issue with using launch pad as it currently stands.
it does what we need of it for bug/feature tracking . i dont really object to evaluating gitia issue if they were avaiable but i dont think
there is a stong need to change form launch pad in general. its certenly preferable to the mix of bugzilla,jria and trello i also have to deal with
but i woudl hope that if we were to use gitia issues we woudl consolidate and not have 3 solution upstream.

keepign track of where we keep track of things upstream and downstream is already a full time job so adding more options is an increased
burden so i woudl hope we could consolidate.
> - Very often when somebody is asking me about particular place in code they (and this is often valid for the referred super contributors) share link
> to GitHub and not opendev.
> 
> What I am trying to say with that is that there are convenience factors we should not neglect. Once developer feels not comfortable with the
> contribution workflow he/she will not do this at all, unless he/she is a long-time committed contributor. Users willing to report issue in
> OSC/SDK/Ansible area often give up on that after seeing what they need to do in order to at least report the issue. I give up on tracking what users
> report to the projects I am responsible for in an official way. The ones willing to contribute a small fix give up after seeing their PR is auto
> closed.
> This is not about: we are bad. This is about if developer doesn’t feel comfortable in the work we will not win him for us. This is something I learn
> through pain during last 10 years or so.

ther eare some convince factors to github and many inconvenices.,
it has a vastly inferior code review model that if i was force to use would push me out of the openstack comunity long term.
im sure there are others too that feel stongly that moving to a github pull request based workflow woudl be a large regerssion
and make them less inclined to continue working on openstack.

> 
> I am very glad to hear that proper SSO is moving closer. Also awesome to hear we may be close to get issues feature of gitea. Those are the things
> that should make daily life a tick easier and we may really improve this. 
> 
> Artem
> 




More information about the openstack-discuss mailing list