On Mon, Feb 15, 2016 at 7:57 AM, Hans de Goede <hdego...@redhat.com> wrote: > Hi, > > On 15-02-16 13:47, Josh Boyer wrote: > > <snip> > >> While I'm still very much on the fence about this, moving to pagure >> for dist-git might very much help in these situations. Being able to >> send a pull request with your changes easily means you've fixed it, >> the maintainer just needs to pull it in. All of the information is >> contained within that pull request. It would seem to solve many of >> our communication issues. > > > I do not think that adding a pull-req to the process of proven packager > commits is really helpful. To me this feels like adding unnecessary red-tape > in a response to one are two cases where a provenpackager commit was > not 100% to the liking of the maintainer. > > How many proven packager commits do we have a day / a week ? And how > much of those lead to "raised eyebrows" of the official package > maintainer ? > > I think that with things like broken deps due to soname bumps + > mass-rebuild failures having proven=packagers help out is 99.9% > of the time very welcome help. I certainly always value such help > with my packages.
So they can continue. I don't see why having pagure precludes them from carrying on as normal. YOu can even have "just commit, don't send me pull requests" in the pagure repo info. > Both as a maintainer (having to respond to pull-reqs means extra work) > and as a proven packager I'm not in favor of adding this extra red-tape. Why do people assume every change is going to be 100% mandatory for everyone all the time? I never said that. > Note that it does not matter how easy you make this, it is still more > work then the current process for both the proven-packager and the > maintainer. And no it is not just 5 seconds with a good gui, that > totally discounts the mental load of needing to do another task > and loosing concentration / breaking your work flow because of those > 5 seconds. Yet it forces one to write up what you're changing and why they're changing it, instead of just changing things and throwing in a crappy commit message that doesn't actually explain anything. It forces the communication that was clearly missing in the originating problem to happen if the maintainer has set up the repo that way. What you view as red tape is the very thing that makes high quality open source projects high quality in the long run. Imagine if kernel commits didn't have descriptive changelogs or random people committing well intentioned fixes without talking to the subsystem maintainer. It'd be terrible. I don't see why we think it's OK for pkg-git commits in a multi-committer environment to resort to the wild west days of software development when we have tools that can help us if people want. I'm not suggesting your specific commits or Till's commits are like this, but from an overall project standpoint I think improving our commit logs and communication would be great. If people just want to go do that without tooling, fantastic. Send patches to devel list or something. Pagure isn't _the_ solution, it just provides more prompts to get there. If nobody else cares about this, then fine. I'm not demanding it. I'm simply suggesting it as a solution to the problem clearly highlighted in this thread. josh -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
