On Sat, Dec 09, 2017 at 06:26:28PM +0000, Philip Kovacs wrote: > s/do want/do NOT want > > On Saturday, December 9, 2017 1:21 PM, Philip Kovacs <pkdevel@xxxxxxxxx> wrote: > > > I am opposed to allowing PP unfettered access to projects in which > the maintainer(s) are responsive. It's common for developers to > have artistic (volatile) temperaments , like a painter who paints > on canvas owned by someone else. It's possible that this it crux of the difference between different sides in this thread. I deeply believe that such maintainers and such packages as you describe must become a thing of a past. Don't get me wrong — I have been there, I have done that (über-complicated packages, spec files full of custom code) — and I think was a waste of time. If a program requires a complicated spec file, then usually something is wrong with the program. Look at the recent fedora-devel thread "Forge-hosted projects packaging automation": all the valiant efforts by maintainers to express their creativity by fighting with github and gitlab hosting and commit hashes and git tags and tarballs are replaced by very-strictly scripted approach where you just define a few fields and let the tooling do the rest. The same story happened with python packaging a while back: all the ways to call setup.py are replaced by a very boring %py_build and %py_install invocations. Fedora as a distro is moving away from arcane setups where only one or two people can make changes towards team maintenance and having everything simplified to avoid mistakes and documented to make things easy for newcomers. I'd say that this is a trend which is true for all of the Linux ecosystem. People have realized that bus factors of one or two are bad for long term sustainability. Eh, even the kernel now has sphinx-based docs so you can actually read the stuff. The reason why that is happening is that we have ever more packages, released more often, with a smaller maintainer/package ratio then ever. If you want to scale, you need to simplify and automate. Essentially, expressing your creativity/spirit/style in how the whitespace is organized and how macros are defined is passé. Zbyszek Does the owner have the right to change the color jars? Perhaps. Does the owner have the right to look at the painting and say "I don't like the way you painted that tree. I'm going to change it." Absolutely not. > Perhaps add a project setting that allows package maintainers to configure how PP changes can be made, by direct commit, by pull request, etc. That would allow maintainerswho are more "involved" with their packages to have more control. It's a common management problem. People who have taken on responsibility must also have control to the extent to which system allows. You certainly do want to drive good people away.. > > On Saturday, December 9, 2017 5:06 AM, Matthias Runge <mrunge@xxxxxxxxxxxxxxxxx> wrote: > > > On Fri, Dec 08, 2017 at 08:30:20PM +0100, Matthias Runge wrote: > > Now this has gone back and forth. The system worked more or less ok. > > Maybe it is more about the changes (and communication) of a > > specific provenpackager? > > After sleeping a night over this, I should have put it in different > words: > > My questionis are here: > - do we have an issue at all? > - do we have an issue with a single provenpacker > - do we have an issue of attitude or with a group of people? > > The consensus of this long thread was: no, the system works mostly ok. > That makes me believe, we don't have a generic issue. > > It's not my intention to blame anyone here, I'm still assuming best > intentions. > > Nevertheless, since people are different, and not everybody can be > friends with each other, maybe it's a good idea to make communication > mandatory, in cases where proven packagers touch others packages? For > mass changes, there is/should always be an announcement to the > devel mailing list. > > Matthias > -- > Matthias Runge <mrunge@xxxxxxxxxxxxxxxxx> > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > > > > > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
