On Thu, Sep 26, 2019 at 08:47:24AM -0500, Michael Cronenworth wrote: > On 9/26/19 8:42 AM, Pierre-Yves Chibon wrote: > > Again, I'd like to reinforce that the idea is not to enforce any part of this > > workflow tomorrow, it'll be a smooth, slow and long transition. My question is > > whether this is a place where we want to go or can we come up with a > > different/better one?:) > > The problem with this statement is that this is written as "come up with > something different or else we're doing it my way anyway" and not "ok, we'll > not do this." This is all very open for discussion but I'm going to defend my proposal to some extent :) There is a clear initial rejection of a PR-only contribution model. I hear that and that may mean that we never go this way. I'm honestly fine with that :) I do want to see why that is a show-stopper and if we can find ways to not have it be a show-stopper. When we work on upstream projects, I think it's pretty standard now to always go via PRs, even for your own branch. So that tests are run, so that other member of the community can see, comment, review the change. What is so different in Fedora that we cannot move to this model? Is it a tooling issue? Is it something else? > I don't want a build for every commit. Sometimes I cache changes for future > releases. A commit does *not* always equal an update. There are a few ways to approach this: - don't bump the release in the spec file, the build will be triggered and will just never complete - have a magic keyword in the commit message that prevents the build from happening at all - is an extra build in rawhide such a big deal? - gate at bodhi level builds that have the same rpm payload as the previous build shipped --> this is what OpenSUSE does btw, when you build an update, they rebuild the entire dependency tree but will filter out the RPM whose payload haven't changed from the update that is pushed to the users. > This proposed workflow model doesn't help me. It hurts. It makes me think of > dropping my roles from Fedora. Seeing you leave is really not the idea and would be the opposite result. The way I thought of this was: - is it easier to ask everyone for what their ideal workflow would be? or - present a workflow (which is hopefully not entirely insane) and encourage the community to patch it so we end up with something that is consensual between all of us? I went with the later approach. Using the brainstorming session at flock, I'm proposing *a* workflow, it's not perfect, it may not not ideal for everyone but it's a start and we can patch it as much as we want. We may end up with something entirely different from what I'm proposing and that's fine, but at least we'll have an agreed upon idea of where we want to go (ie: a long term vision) Does that make sense? I am sorry if the wording I've used didn't make this clear in my initial email :( Pierre _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
