Re: Please stop modifying other people's packages without coordinating with them first

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Feb 14, 2016 at 2:32 PM, Till Maas <opensource@xxxxxxxxx> wrote:
> On Sat, Feb 13, 2016 at 04:29:38PM -0500, Josh Boyer wrote:
>
>> I'm not going to weigh in on the changes, but I did want to address
>> this in public so others can learn.
>
> IMHO the kind of changes are important here. The situation was that
> there were was an incomplete update to the sigrok packages in Rawhide
> and Fedora 23 testing for about a week. This means that any Rawhide user
> wanting to use pulseview (the GUI tool for sigrok) could not install it
> freshly or would get broken dependency warnings when trying to update
> Rawhide. The same goes for F23 testing. Also the necessary buildroot
> overrides required for F23 were expired, requiring them to be extended
> to be able to build pulseview and also sigrok-cli, which just failed in
> F23 because of missing dependencies from the buildroot overrides.
> But pulseview also did not compile because of errors already fixed by
> upstream.
>
> So the main change I did was adding unmodified upstream patches to
> pulseview getting it to compile. While doing this I noticed that
> pulseview was not using the %license macro yet, so I fixed this as well.

The changes all sound fine and well intended.

>> IRC alone is not sufficient.  We cannot expect volunteer maintainers
>> to be on IRC all the time.  In the future, please email and wait at
>> least a bit for a reply.
>
> Given the changes that I described, do you still state that this (fixing
> incomplete updates/dependencies/package building) is something that
> provenpackagers should first get permission to do by the package
> maintainer? I mainly cared about not doing the same work twice and
> making sure that I do not commit something conflicting to the GIT as the
> same time the maintainer might commit something, which is why I found
> IRC sufficient at that time. Also IMHO it is beneficial to the Fedora
> project to fix breakage in the repositories as soon as possible. And as
> a package maintainer myself I would be thankful for every other package
> maintainer fixing bugs in my packages while I sleep. Since I am a
> volunteer maintainer myself, the strict requirement to get permission
> via e-mail to fix sigrok in this situation would have meant that I would
> have done nothing. Yesterday I had time and motivation to look into it
> and fix it. But if I asked "May I please fix your package?", it is very
> likely that I would not have the time or motivation to actually do it
> once I get the response.

You misunderstand.  I was not suggesting you ask for permission.  I
was stating that IRC contact alone, for whatever reason, is not
necessarily sufficient as an attempt to contact a maintainer.  You can
convey _much_ more information in an email, to the point of telling
them exactly what you are committing and why.  It is so much better
than a simple ping or brief sentence or two in IRC.

As for waiting for a response, yes I think it is fine to wait a day.
Timezones alone may mean that the duplicate work you wished to avoid
was already queued on the maintainer's side and he was just waiting to
finish testing before pushing.  Who knows.  Urgency in fixing packages
is certainly appreciated, but this is not a critical package and it
had already been broken for a week.

While I'm still very much on the fence about this, moving to pagure
for dist-git might very much help in these situations.  Being able to
send a pull request with your changes easily means you've fixed it,
the maintainer just needs to pull it in.  All of the information is
contained within that pull request.  It would seem to solve many of
our communication issues.

josh
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux