[emelfm2] remove vendor tag from desktop file. https://fedorahosted.org/fpc/ticket/247

[Michael Schwendt]

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