On Thu, Sep 26, 2019 at 11:24:28AM -0500, Michael Cronenworth wrote: > On 9/26/19 9:07 AM, Pierre-Yves Chibon wrote: > > What is so different in Fedora that we cannot move to this model? > > Is it a tooling issue? > > Is it something else? > > As others have already stated that may work in projects with tens, hundreds, > or thousands of contributors, but most of Fedora packages are owned and > maintained by a single person. I'm not going to wait around for anyone to > review my commit or comment on it. No one tests or comments on most of my > Bodhi updates. > > The same development model for upstream projects is not 1:1 to Fedora > packaging. Stop trying to force it. It may just be a wording issue, but I would really appreciate if you would not attribute me thoughts I've never had. I think I have been clear that this thread is about proposing something, everything in it is up for debate and discussion. If every discussion that is started is treated as something that is "forced" then it's questioning (at least to me). > > > 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 > > It should be an opt-in feature. Who called for this feature? I don't > remember seeing anyone ask for it. If you want a name then I'll put mine, this is something that I've found would be useful in more than one occasion. Making it opt-in is definitely possible but the rest of your comment makes me wonder if it's even wanted. > > - have a magic keyword in the commit message that prevents the build from > > happening at all > No, thanks. Requires way too much human interaction (memory). > > - is an extra build in rawhide such a big deal? > It may fail to build because of a dependency on other features not yet in > place... so it *must* be opt-in. > > - 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. > > If you want to spend time doing this go ahead, but it feels like a waste of > resources and talent. It's also what would provide one of the greatest return on investment. It should basically solve all the broken-deps reports, the un-announced soname bumps and so on. > > > 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 > > :( > > If you want to have fedpkg do all of this for you buy default, sure, fine. > It should /also/ have a configuration able to be defined to disable all of > this automatic stuff. The reverse could also happen. Bake all this > functionality in and make it opt-in. > > Again, who was asking for all of this? Why do we need to have someone asking to propose something? There are regularly people complaining on this very list about how hard packaging has become. So here is a thread trying to see if you can come up with a long term, ideal, vision of what the packager workflow should be so we can work towards it. I'm going to ask again what was in my original email: What is your ideal workflow? How do you think things should work? Is what we have today the ideal state of things? If so, great! If not, what can we improve and are there things we can easily change that will make it easier for a majority of packagers? > The only interesting part is the automated testing and automated push to > stable, but that would take years to implement distro wide. The CI SIG folks are actively working towards this. It is a slow process but hopefully we are improving things there. 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
