On Tue, 05 Mar 2013 04:36:11 -0500, Rahul Sundaram wrote: > > Some of the changes have been applied with good intentions. I > > understand that. But they are still controversial. > > I have made some actual mistakes in some of the previous builds but I > thought in this case my changes were really straight forward. This > package has never been built for EPEL And still that is no justification to drop %rhel conditionals that may be used in future builds. Perhaps by a co-maintainer, who would focus on EPEL. Afterall, some of them explicitly cover RHEL > 6, so the spec file also tries to cover RHEL < 7. To you they may appear unused and superfluous, but you cannot be certain without talking to somebody who has taken care of the package so far. It's pretty convenient that a Fedora src.rpm can be built for RHEL/EPEL, even if it isn't published and maintained in EPEL _yet_. That's not a bug, so time is spent better on fixing real bugs. > and I dropped some of the > conditionals for very very old releases such as Fedora 11 and Fedora > 13, Which can be a good thing, also with regard to ancient Obsoletes we don't want to keep forever. I explain that to packagers regularly. Spec files ought to contain comments on special Obsoletes/Provides to mention when they have been added, so it becomes easy to remove them in the future. However, in some cases it might be beneficial to not simply delete old %fedora conditionals, but replace them with explanatory comments. For example, to mention when one component was replaced with another one. The package maintainer(s) might be interested in such details when tracking down bugs. > dropped INSTALL file (rpmlint warning). defattr and %clean section > which are entirely redundant for all current Fedora releases. I think you could have fixed also the %buildroot and $RPM_BUILD_ROOT mix, too. *g* > > Btw, I'm surprised that there is not a single "sorry" in the reply to > > Christoph's message > Sorry if anyone is bothered by this. I think we would benefit from less > personal style and "ownership" model to more standardized changes and > group "care taking" model but perhaps very minimal changes by > non-maintainers that addresses only one thing is what is preferred for now. Of course. More team-work would be great! Don't forget that communication is essential when collaborating. Especially when a team member disagrees with something. If all team members stay silent, one can assume that they agree or don't care or have lost interest. But this thread is about controversial changes. For true team-work, however, you would monitor the commits to this package and become a real co-maintainer, so you would not jump in and revert something just because it meets _your_ personal preferences. I have doubts that if you edited random packages again in 1-2 months, you would not drop again things another packager may have added back meanwhile. -- Fedora release 19 (Rawhide) - Linux 3.9.0-0.rc0.git15.1.fc19.x86_64 loadavg: 0.03 0.09 0.12 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
