On 02/02/2016 03:25 AM, Martin Pluskal wrote: <snip>
It's annoying, indeed.
This is matter of perspective, if you are contributing to multiple packages, reviewing more requests, "uniformity" of packages makes both a bit more easy. To be honest I do not consider packaging to be place where creativity/ uniqueness in packaging style is actually desirable.
Furthermore, there has been ongoing debate in matter of rights/duties of package maintainers - it seems that some package maintainers consider themselves to be owners of said packages, while in my opinion maintainer is more like a custodian/curator of package - so all matters of personal taste are secondary to actuall functional improvements.
While I agree with the notion that uniformity w.r.t. the boiler plate stuff (Requires, BuildRequires, use of macros....) is desirable and makes reviewers jobs easier I strongly disagree with the idea that project maintainers somehow have a better understanding of the functionality of every package in a given project. If the goal is simply to always have the latest version in the devel project and no one cares if dependent things break then lets have a bot for all devel projects like we do for d:l:perl. However, if we care that higher level packages actually work then bots may not be the greatest thing in the world unless we back the bots up by a database that maps out all the dependencies and then write a solver that can comprehend whether a given package can automatically be pushed to the next upstream released version. AFAIK that does not exist yet, thus the role of the package maintainer, who hopefully understands the package upstream dependencies to a certain extend and within reason is quite valuable, IMHO. Therefore, project maintainers should encourage active package maintainership in their projects rather then stepping in and ignoring package maintainers. The latter will only lead to the point where project maintainers end up being responsible for all packages in a project as package maintainers will just walk away. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo