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

[Igor Gnatenko]

Here I totally agree with Till and usually I'm doing the same (it doesn't
happen often, but anyway).

Because I also not available day to day. For example today I have time and
next time I will have time like month..

Just wanted to share my opinion.

On Mon, Feb 15, 2016, 7:23 PM Josh Boyer  wrote:

> On Mon, Feb 15, 2016 at 12:20 PM, Till Maas  wrote:
> > On Mon, Feb 15, 2016 at 07:47:08AM -0500, Josh Boyer wrote:
> >
> >> 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.
> >
> > I agree, that it is possible to be more informative via e-mail. However
> > at the time I reached out via IRC, I did not yet know all the details. I
> > only knew the build error from the previous build logs and a related
> > commit message in upstream git. Therefore an e-mail would be pretty
> > useless at this point, unless I stop working then. Otherwise there would
> > be several status report e-mails about my slowed-down progress. If I was
> > the targeted maintainer, I would be annoyed by this - we are not talking
> > about changes that might require an epoch bump here and therefore are
> > easily reverted.
> >
> >> As for waiting for a response, yes I think it is fine to wait a day.
> >
> > Not sure how it works for other volunteer maintainers, but this does not
> > fit with my time slots that I might have available. So waiting a day
> > might also mean wait till the next weekend, when I have time for this
> > again.
> >
> >> 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.
> >
> > To be honest, a one week old commit to dist-git that does not build due
> > to upstream bugs does not suggest to me that the maintainer has an extra
> > secret stash of changes that are just waiting of a lot of extra testing.
> > If the commit happened recently, it might be different.
>
> You and I are going to disagree on this issue and the finer points
> within it.  That is fine.  We will simply have to agree to disagree
> because spending further time with back and forth isn't going to be
> productive.
>
> Thank you for the very civil discourse.
>
> josh
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
-- 

-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Josh Boyer]

On Mon, Feb 15, 2016 at 12:20 PM, Till Maas  wrote:
> On Mon, Feb 15, 2016 at 07:47:08AM -0500, Josh Boyer wrote:
>
>> 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.
>
> I agree, that it is possible to be more informative via e-mail. However
> at the time I reached out via IRC, I did not yet know all the details. I
> only knew the build error from the previous build logs and a related
> commit message in upstream git. Therefore an e-mail would be pretty
> useless at this point, unless I stop working then. Otherwise there would
> be several status report e-mails about my slowed-down progress. If I was
> the targeted maintainer, I would be annoyed by this - we are not talking
> about changes that might require an epoch bump here and therefore are
> easily reverted.
>
>> As for waiting for a response, yes I think it is fine to wait a day.
>
> Not sure how it works for other volunteer maintainers, but this does not
> fit with my time slots that I might have available. So waiting a day
> might also mean wait till the next weekend, when I have time for this
> again.
>
>> 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.
>
> To be honest, a one week old commit to dist-git that does not build due
> to upstream bugs does not suggest to me that the maintainer has an extra
> secret stash of changes that are just waiting of a lot of extra testing.
> If the commit happened recently, it might be different.

You and I are going to disagree on this issue and the finer points
within it.  That is fine.  We will simply have to agree to disagree
because spending further time with back and forth isn't going to be
productive.

Thank you for the very civil discourse.

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

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

[Till Maas]

On Mon, Feb 15, 2016 at 07:47:08AM -0500, Josh Boyer wrote:

> 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.

I agree, that it is possible to be more informative via e-mail. However
at the time I reached out via IRC, I did not yet know all the details. I
only knew the build error from the previous build logs and a related
commit message in upstream git. Therefore an e-mail would be pretty
useless at this point, unless I stop working then. Otherwise there would
be several status report e-mails about my slowed-down progress. If I was
the targeted maintainer, I would be annoyed by this - we are not talking
about changes that might require an epoch bump here and therefore are
easily reverted.

> As for waiting for a response, yes I think it is fine to wait a day.

Not sure how it works for other volunteer maintainers, but this does not
fit with my time slots that I might have available. So waiting a day
might also mean wait till the next weekend, when I have time for this
again.

> 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.

To be honest, a one week old commit to dist-git that does not build due
to upstream bugs does not suggest to me that the maintainer has an extra
secret stash of changes that are just waiting of a lot of extra testing.
If the commit happened recently, it might be different.

Kind regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Hans de Goede]

Hi,

On 15-02-16 14:15, Josh Boyer wrote:

On Mon, Feb 15, 2016 at 7:57 AM, Hans de Goede  wrote:

Hi,

On 15-02-16 13:47, Josh Boyer wrote:




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.



I do not think that adding a pull-req to the process of proven packager
commits is really helpful. To me this feels like adding unnecessary red-tape
in a response to one are two cases where a provenpackager commit was
not 100% to the liking of the maintainer.

How many proven packager commits do we have a day / a week ? And how
much of those lead to "raised eyebrows" of the official package
maintainer ?

I think that with things like broken deps due to soname bumps +
mass-rebuild failures having proven=packagers help out is 99.9%
of the time very welcome help. I certainly always value such help
with my packages.


So they can continue.  I don't see why having pagure precludes them
from carrying on as normal.  YOu can even have "just commit, don't
send me pull requests" in the pagure repo info.


Ok, then I'm fine with it.


Both as a maintainer (having to respond to pull-reqs means extra work)
and as a proven packager I'm not in favor of adding this extra red-tape.


Why do people assume every change is going to be 100% mandatory for
everyone all the time?  I never said that.


I know you didn't say that I was just trying to pre-empt this possibly
becoming a mandatory thing.




If nobody else cares about this, then fine.  I'm not demanding it.
I'm simply suggesting it as a solution


I agree this maybe useful for some work flows, and people used to
the github workflow will likely like this, so if people want to work
on this as an extra option then I'm all for it.

> to the problem clearly highlighted in this thread.

I'm not sure there really is such a problem, which is exactly why
I replied. Yes there was a communication hiccup, those happen, but as
I said in my initial reply, how many provenpackager commits a day / week
do we have, and how often do we get such a communication hiccup ?

(Honest) Mistakes will always happen, we simply cannot "regulate"
mistakes away completely and trying to do so will just result
in needlessly complex procedures.

Regards,

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

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

[Peter Robinson]

>>> > 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.
>>>
>>> I do not think that adding a pull-req to the process of proven
>>> packager commits is really helpful. To me this feels like adding
>>> unnecessary red-tape in a response to one are two cases where a
>>> provenpackager commit was not 100% to the liking of the maintainer.
>>>
>>> How many proven packager commits do we have a day / a week ? And how
>>> much of those lead to "raised eyebrows" of the official package
>>> maintainer ?
>>>
>>> I think that with things like broken deps due to soname bumps +
>>> mass-rebuild failures having proven=packagers help out is 99.9%
>>> of the time very welcome help. I certainly always value such help
>>> with my packages.
>>>
>>> Both as a maintainer (having to respond to pull-reqs means extra work)
>>> and as a proven packager I'm not in favor of adding this extra
>>> red-tape.
>>>
>>> Note that it does not matter how easy you make this, it is still more
>>> work then the current process for both the proven-packager and the
>>> maintainer. And no it is not just 5 seconds with a good gui, that
>>> totally discounts the mental load of needing to do another task
>>> and loosing concentration / breaking your work flow because of those
>>> 5 seconds.
>>
>> dunno if Josh means the pull requests to be mandatory, but they would
>> add a nice option how to provide fixes for package maintainers from
>> non-proven packagers. A review of the suggested changes can be useful
>> and will be easier than patch attached in bugzilla.
>
> Yes, this is true as well.

Agreed, I know there was a discussion at some point of putting pagure
on top of dist-git to facilitate this sort of thing, having dealt with
a LOT of packages when doing arch bringups etc having to file bugs,
await responses from maintainers is a lot of work for often what is a
few line fix which is blocking a vast work flow so the ability for
people to push directly is essential but the ability to have pull
requests would be a great addition to the work flow.

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

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

[Jonathan Wakely]

On 15/02/16 13:57 +0100, Hans de Goede wrote:

Hi,

On 15-02-16 13:47, Josh Boyer wrote:




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.


I do not think that adding a pull-req to the process of proven packager
commits is really helpful. To me this feels like adding unnecessary red-tape
in a response to one are two cases where a provenpackager commit was
not 100% to the liking of the maintainer.


Personally I'd be happy with it. When patching lots of packages for
mass rebuilds I don't want to have to wait for dozens of email
responses and context-switch back to repos I was working in hours or
days earlier.  But if instead of pushing a fix I could send a pull
request and still "forget about" the package I'd be happy. The fix
would be shared with the maintainer, and I no longer need to track it
myself locally and chase people to respond.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Josh Boyer]

On Mon, Feb 15, 2016 at 8:09 AM, Dan Horák  wrote:
> On Mon, 15 Feb 2016 13:57:39 +0100
> Hans de Goede  wrote:
>
>> Hi,
>>
>> On 15-02-16 13:47, Josh Boyer wrote:
>>
>> 
>>
>> > 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.
>>
>> I do not think that adding a pull-req to the process of proven
>> packager commits is really helpful. To me this feels like adding
>> unnecessary red-tape in a response to one are two cases where a
>> provenpackager commit was not 100% to the liking of the maintainer.
>>
>> How many proven packager commits do we have a day / a week ? And how
>> much of those lead to "raised eyebrows" of the official package
>> maintainer ?
>>
>> I think that with things like broken deps due to soname bumps +
>> mass-rebuild failures having proven=packagers help out is 99.9%
>> of the time very welcome help. I certainly always value such help
>> with my packages.
>>
>> Both as a maintainer (having to respond to pull-reqs means extra work)
>> and as a proven packager I'm not in favor of adding this extra
>> red-tape.
>>
>> Note that it does not matter how easy you make this, it is still more
>> work then the current process for both the proven-packager and the
>> maintainer. And no it is not just 5 seconds with a good gui, that
>> totally discounts the mental load of needing to do another task
>> and loosing concentration / breaking your work flow because of those
>> 5 seconds.
>
> dunno if Josh means the pull requests to be mandatory, but they would
> add a nice option how to provide fixes for package maintainers from
> non-proven packagers. A review of the suggested changes can be useful
> and will be easier than patch attached in bugzilla.

Yes, this is true as well.

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

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

[Josh Boyer]

On Mon, Feb 15, 2016 at 7:57 AM, Hans de Goede  wrote:
> Hi,
>
> On 15-02-16 13:47, Josh Boyer wrote:
>
> 
>
>> 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.
>
>
> I do not think that adding a pull-req to the process of proven packager
> commits is really helpful. To me this feels like adding unnecessary red-tape
> in a response to one are two cases where a provenpackager commit was
> not 100% to the liking of the maintainer.
>
> How many proven packager commits do we have a day / a week ? And how
> much of those lead to "raised eyebrows" of the official package
> maintainer ?
>
> I think that with things like broken deps due to soname bumps +
> mass-rebuild failures having proven=packagers help out is 99.9%
> of the time very welcome help. I certainly always value such help
> with my packages.

So they can continue.  I don't see why having pagure precludes them
from carrying on as normal.  YOu can even have "just commit, don't
send me pull requests" in the pagure repo info.

> Both as a maintainer (having to respond to pull-reqs means extra work)
> and as a proven packager I'm not in favor of adding this extra red-tape.

Why do people assume every change is going to be 100% mandatory for
everyone all the time?  I never said that.

> Note that it does not matter how easy you make this, it is still more
> work then the current process for both the proven-packager and the
> maintainer. And no it is not just 5 seconds with a good gui, that
> totally discounts the mental load of needing to do another task
> and loosing concentration / breaking your work flow because of those
> 5 seconds.

Yet it forces one to write up what you're changing and why they're
changing it, instead of just changing things and throwing in a crappy
commit message that doesn't actually explain anything.  It forces the
communication that was clearly missing in the originating problem to
happen if the maintainer has set up the repo that way.  What you view
as red tape is the very thing that makes high quality open source
projects high quality in the long run.  Imagine if kernel commits
didn't have descriptive changelogs or random people committing well
intentioned fixes without talking to the subsystem maintainer.  It'd
be terrible.  I don't see why we think it's OK for pkg-git commits in
a multi-committer environment to resort to the wild west days of
software development when we have tools that can help us if people
want.

I'm not suggesting your specific commits or Till's commits are like
this, but from an overall project standpoint I think improving our
commit logs and communication would be great.  If people just want to
go do that without tooling, fantastic.  Send patches to devel list or
something.  Pagure isn't _the_ solution, it just provides more prompts
to get there.

If nobody else cares about this, then fine.  I'm not demanding it.
I'm simply suggesting it as a solution to the problem clearly
highlighted in this thread.

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

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

[Dan Horák]

On Mon, 15 Feb 2016 13:57:39 +0100
Hans de Goede  wrote:

> Hi,
> 
> On 15-02-16 13:47, Josh Boyer wrote:
> 
> 
> 
> > 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.
> 
> I do not think that adding a pull-req to the process of proven
> packager commits is really helpful. To me this feels like adding
> unnecessary red-tape in a response to one are two cases where a
> provenpackager commit was not 100% to the liking of the maintainer.
> 
> How many proven packager commits do we have a day / a week ? And how
> much of those lead to "raised eyebrows" of the official package
> maintainer ?
> 
> I think that with things like broken deps due to soname bumps +
> mass-rebuild failures having proven=packagers help out is 99.9%
> of the time very welcome help. I certainly always value such help
> with my packages.
> 
> Both as a maintainer (having to respond to pull-reqs means extra work)
> and as a proven packager I'm not in favor of adding this extra
> red-tape.
> 
> Note that it does not matter how easy you make this, it is still more
> work then the current process for both the proven-packager and the
> maintainer. And no it is not just 5 seconds with a good gui, that
> totally discounts the mental load of needing to do another task
> and loosing concentration / breaking your work flow because of those
> 5 seconds.

dunno if Josh means the pull requests to be mandatory, but they would
add a nice option how to provide fixes for package maintainers from
non-proven packagers. A review of the suggested changes can be useful
and will be easier than patch attached in bugzilla.


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

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

[Hans de Goede]

Hi,

On 15-02-16 13:47, Josh Boyer wrote:




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.


I do not think that adding a pull-req to the process of proven packager
commits is really helpful. To me this feels like adding unnecessary red-tape
in a response to one are two cases where a provenpackager commit was
not 100% to the liking of the maintainer.

How many proven packager commits do we have a day / a week ? And how
much of those lead to "raised eyebrows" of the official package
maintainer ?

I think that with things like broken deps due to soname bumps +
mass-rebuild failures having proven=packagers help out is 99.9%
of the time very welcome help. I certainly always value such help
with my packages.

Both as a maintainer (having to respond to pull-reqs means extra work)
and as a proven packager I'm not in favor of adding this extra red-tape.

Note that it does not matter how easy you make this, it is still more
work then the current process for both the proven-packager and the
maintainer. And no it is not just 5 seconds with a good gui, that
totally discounts the mental load of needing to do another task
and loosing concentration / breaking your work flow because of those
5 seconds.

Regards,

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

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

[Josh Boyer]

On Sun, Feb 14, 2016 at 2:32 PM, Till Maas  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@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Martin Kolman]

- Original Message -
> From: "Josh Boyer" <jwbo...@fedoraproject.org>
> To: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>
> Sent: Saturday, February 13, 2016 10:29:38 PM
> Subject: Re: Please stop modifying other people's packages without 
> coordinating with them first
> 
> On Sat, Feb 13, 2016 at 12:57 PM, Till Maas <opensou...@till.name> wrote:
> > Hi Alex,
> >
> > On Sa, Feb 13, 2016 at 09:43:06 -0800, Alex Gagniuc wrote:
> >
> >> I was in the process of upgrading to the latest upstream releases,
> >> which came out about a week ago. You've interrupted the process by
> >> pushing some unrelated changes, and now I have to figure out what
> >
> > the changes were not unrelated but fixed the build error for pulseview
> > on Rawhide and extending the build overrides fixed the build errors on
> > F23 (which you can also read in the changelog).
> >
> >> You've done that without  any attempt at contacting me. There are
> >
> > This is not true, since I tried to contact you via IRC.
> 
> I'm not going to weigh in on the changes, but I did want to address
> this in public so others can learn.
> 
> 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.
I think some automated tooling for this would be very beneficial - basically 
something
like a GitHub/GitLab pull request for the distgit repo, that fires an email 
notification once submitted.

There could be two types of pull requests - one "normal" that needs to be 
accepted by the maintainer
and one "timed" that proven-packagers can submit that self-applies after say 48 
hours.

The main advantage would be that you can just "fire away" without having to ask 
for permission and the system
takes care for the rest - by notifying the maintainer and giving him the chance 
to review the changes before
they are applied (and to possibly apply them differently, etc.).
> 
> josh
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
> 
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Till Maas]

On Sun, Feb 14, 2016 at 08:50:34PM +0100, Till Maas wrote:
> On Sat, Feb 13, 2016 at 05:40:07PM -0800, Alex Gagniuc wrote:

> > yes, I have an IRC bouncer server, so I was able to find your question
> > after some grepping. It was posted before dawn in my timezone, so I
> > wouldn't have had a chance to respond anyhow.
> 
> Since I assumed that you would like it if pulseview was fixed and the
> update complete.

Sorry, I forgot half the sentence here:
Since I assumed that you would like it if pulseview was fixed and the
update complete I just wanted to make sure that you are not working on
it right now to avoid any conflicting commits. Therefore if you were not
available on IRC I assumed you were also not working on it at that time.

Kind regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Till Maas]

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.

> 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.

Kind regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Till Maas]

On Sat, Feb 13, 2016 at 05:40:07PM -0800, Alex Gagniuc wrote:
> On Sat, Feb 13, 2016 at 9:57 AM, Till Maas 
> wrote:

> # Zero-day patches after 0.3.0 release. Extract using:
> # $ git clone git://sigrok.org/pulseview.git
> # $ cd pulseview
> # $ git checkout a1a3656b4e18cb9fc078a51bf4256066ee307620
> # $ git format-patch pulseview-0.3.0

These instructions are great. Btw. I was told on IRC that there might be
a bugfix sigrok release soonish that includes these fixes.

> yes, I have an IRC bouncer server, so I was able to find your question
> after some grepping. It was posted before dawn in my timezone, so I
> wouldn't have had a chance to respond anyhow.

Since I assumed that you would like it if pulseview was fixed and the
update complete.

> > Also pushing
> > dependent builds in separate updates is against best practices as this
> > will lead to broken updates.
> 
> I haven't been able to stay up-to date with the latest and greatest
> guidelines in the past several years due to jobs, military training,
> etc, though I'm always looking for hints on how to improve the process
> of pushing out these updates.

Probably everyone has not enough time to keep up with everything. I am
sure that some of my packages are also still using %doc instead of
%license, since I update this when I need to update the package anyhow -
and sometimes someone else is kind enough to do it.  However, I guess I
was not clear enough about the updates bundling. You should publish all
related builds in one update, i.e. add the sigrok-cli build to the big
other update. This ensures that all builds are pushed together and
avoids that only some of the builds are updated on a system breaking the
other tools.

Kind Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Alex Gagniuc]

I was in the process of upgrading to the latest upstream releases,
which came out about a week ago. You've interrupted the process by
pushing some unrelated changes, and now I have to figure out what
happened.

You've done that without  any attempt at contacting me. There are
other persons who helped considerably with these packages, such as
Dan, and every time, they coordinated with me before stepping on my
toes.

I've considered what to do next in order to complete upgrading to the
shiniest upstream release. I've decided that I will revert your
changes, and continue the process where I left it off.

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

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

[Till Maas]

Hi Alex,

On Sa, Feb 13, 2016 at 09:43:06 -0800, Alex Gagniuc wrote:

> I was in the process of upgrading to the latest upstream releases,
> which came out about a week ago. You've interrupted the process by
> pushing some unrelated changes, and now I have to figure out what

the changes were not unrelated but fixed the build error for pulseview
on Rawhide and extending the build overrides fixed the build errors on
F23 (which you can also read in the changelog).

> You've done that without  any attempt at contacting me. There are

This is not true, since I tried to contact you via IRC.

> I've considered what to do next in order to complete upgrading to the
> shiniest upstream release. I've decided that I will revert your
> changes, and continue the process where I left it off.

If you think that is the best way forward, please do it. But please make
sure that you also restore compliance to the packaging guidelines by
starting the release with 1 and using the %license macro. Also pushing
dependent builds in separate updates is against best practices as this
will lead to broken updates.

Kind regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Josh Boyer]

On Sat, Feb 13, 2016 at 12:57 PM, Till Maas  wrote:
> Hi Alex,
>
> On Sa, Feb 13, 2016 at 09:43:06 -0800, Alex Gagniuc wrote:
>
>> I was in the process of upgrading to the latest upstream releases,
>> which came out about a week ago. You've interrupted the process by
>> pushing some unrelated changes, and now I have to figure out what
>
> the changes were not unrelated but fixed the build error for pulseview
> on Rawhide and extending the build overrides fixed the build errors on
> F23 (which you can also read in the changelog).
>
>> You've done that without  any attempt at contacting me. There are
>
> This is not true, since I tried to contact you via IRC.

I'm not going to weigh in on the changes, but I did want to address
this in public so others can learn.

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.

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

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

[Alex Gagniuc]

On Sat, Feb 13, 2016 at 9:57 AM, Till Maas  wrote:
> Hi Alex,

Hi Till,

> the changes were not unrelated but fixed the build error for pulseview
> on Rawhide and extending the build overrides fixed the build errors on
> F23 (which you can also read in the changelog).

I noticed the changes were zero-day patches. I have added instructions
on how to obtain those patches:

# Zero-day patches after 0.3.0 release. Extract using:
# $ git clone git://sigrok.org/pulseview.git
# $ cd pulseview
# $ git checkout a1a3656b4e18cb9fc078a51bf4256066ee307620
# $ git format-patch pulseview-0.3.0

It's important to have such instructions so that the origin of the
patches can be verified.


>> You've done that without  any attempt at contacting me. There are
>
> This is not true, since I tried to contact you via IRC.

yes, I have an IRC bouncer server, so I was able to find your question
after some grepping. It was posted before dawn in my timezone, so I
wouldn't have had a chance to respond anyhow.

> If you think that is the best way forward, please do it. But please make
> sure that you also restore compliance to the packaging guidelines by
> starting the release with 1 and using the %license macro.

I have restored your changes, with the appropriate modifications.
You're still listed as the author in git, as you're the one who
figured it out. Thanks for that.

> Also pushing
> dependent builds in separate updates is against best practices as this
> will lead to broken updates.

I haven't been able to stay up-to date with the latest and greatest
guidelines in the past several years due to jobs, military training,
etc, though I'm always looking for hints on how to improve the process
of pushing out these updates.

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