>I deeply believe that such maintainers and such packages as you
>describe must become a thing of a past.
>describe must become a thing of a past.
For the moment, until your new world order arrives, packages are maintained by people
of all types volunteering their time and effort. These are people who will probably never
even hear a thank you from anyone for their efforts. One important way to extend to them
respect and gratitude for that contribution is to notify them prior to changing the files they
spent time maintaining. It's just simple human courtesy.
On Saturday, December 9, 2017 2:13 PM, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote:
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
> 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
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
