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.
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.
- 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.
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?
The only interesting part is the automated testing and automated push to stable, but
that would take years to implement distro wide.
Thanks,
Michael
_______________________________________________
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
