Re: What to I have to do....

[Graham Leggett]

On 12 Dec 2017, at 2:44 PM, Philip Kovacs  wrote:
> 
> >Artistic (volatile) temperament” is just a euphemistic way of saying 
> >“engages in unchecked abusive behaviour toward their peers”, and no member 
> >of the community should be expected to bend over backwards to >tolerate this 
> >or to turn a blind eye to it.
> 
> You completely, utterly and totally misread the meaning and spirit of what I 
> said.  
> 
> To reiterate, if the maintainer is responsive, my opinion is that is a 
> courtesy to notify him/her. 
>  
> That's all.  Some people are more attached and involved with their code and 
> would appreciate 
> the gesture. 

What you’re describing is passive aggressive behaviour, and this too is 
unacceptable.

It is not fair on people who do work in good faith to be scared of having 
sudden abuse flung at them by collaborators who refuse to abide by the 
established rules, and impose rules of their own. To be clear, none of what you 
propose is reasonable or acceptable.

> No need to imagine that the maintainer is demonstrating "unchecked abusive 
> behavior."  
> 
> For Pete's sake.  

As I made clear in another message, the message that started this thread is a 
clear example of unchecked abusive behaviour. I am calling this behaviour out 
explicitly as unacceptable in an open source community.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Philip Kovacs]

>Artistic (volatile) temperament” is just a euphemistic way of saying “engages 
>in unchecked abusive behaviour toward their peers”, and no member of the 
>community should be expected to bend over backwards to >tolerate this or to 
>turn a blind eye to it.

You completely, utterly and totally misread the meaning and spirit of what I 
said.  
To reiterate, if the maintainer is responsive, my opinion is that is a courtesy 
to notify him/her.  
That's all.  Some people are more attached and involved with their code and 
would appreciate the gesture. 
No need to imagine that the maintainer is demonstrating "unchecked abusive 
behavior."  
For Pete's sake.  
 

On Tuesday, December 12, 2017 7:09 AM, Graham Leggett  
wrote:
 

 On 09 Dec 2017, at 8:21 PM, Philip Kovacs  wrote:

I am opposed to allowing PP unfettered access to projects in which the 
maintainer(s) are responsive.  It's common for developers to have artistic 
(volatile) temperaments , like a painter who paints on canvas owned by someone 
else.

We need to nip this kind of thing in the bud.
“Artistic (volatile) temperament” is just a euphemistic way of saying “engages 
in unchecked abusive behaviour toward their peers”, and no member of the 
community should be expected to bend over backwards to tolerate this or to turn 
a blind eye to it.
Even more specifically nobody at Fedora should be forced to ask special 
permission from or give special notification to specific individuals over and 
above the established procedures before doing their work. Their commit 
privileges / karma / following the established procedure give them that 
permission.
If someone makes a change to your code, start with the premise that the person 
who made the change did so in good faith, and respond appropriately from there.
Regards,Graham—
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Graham Leggett]

On 09 Dec 2017, at 8:21 PM, Philip Kovacs  wrote:

> I am opposed to allowing PP unfettered access to projects in which the 
> maintainer(s) 
> are responsive.  It's common for developers to have artistic (volatile) 
> temperaments , 
> like a painter who paints on canvas owned by someone else.

We need to nip this kind of thing in the bud.

“Artistic (volatile) temperament” is just a euphemistic way of saying “engages 
in unchecked abusive behaviour toward their peers”, and no member of the 
community should be expected to bend over backwards to tolerate this or to turn 
a blind eye to it.

Even more specifically nobody at Fedora should be forced to ask special 
permission from or give special notification to specific individuals over and 
above the established procedures before doing their work. Their commit 
privileges / karma / following the established procedure give them that 
permission.

If someone makes a change to your code, start with the premise that the person 
who made the change did so in good faith, and respond appropriately from there.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[R P Herrold]

On Sun, 10 Dec 2017, Graham Leggett wrote:

> In this case, we have the needs of the Fedora project (this 
> change) stacked up against your needs (your reluctance to 
> perform a task).

This line of argument is a 'straw man' as are several other 
rationalizations advanced for NOT giving effective notice.  
As I read the thread, Steve has never said he was 'reluctant' 
nor that he was unwilling to make changes, but rather he said 
that he was troubled when PP changes 'get dropped on him' as 
maintainer without effective prior indication that there is an 
issue

The bugzilla, and tracking bugs, and Blockers and Depends are 
just not that hard to use.  Much automation in this regard 
exists -- FTBFS, etc -- bugzilla had an API for just such a 
purpose

The proponents of simply making a change and letting the 
maintainer take his luck, seem to think that using the tracker 
and the overhead of opening bugs would cause load would go 
up

I doubt it would turn out that way; This is almost certainly 
not the case.  If a maintainer gets a notification via a bug 
filing that some 'Future Feature' change is needed, and there 
is a pointer in the parent bug as to the 'why' and the 
approach to modify matters, I have to think that the proposed 
will get applied next update round, and BY THE MAINTAINER, and 
the dependent bug closed through the release automation

And where there is an impediment -- there was one on the font 
removal matter 'blasted through' by a PP, and if asked, as in 
a bug, the maintainer would so indicate, in such a case, 
probably in the dependent bug.  He promptly did so for me, 
when I asked directly


If filing bugs, and mostly having maintainers respond and make 
changes does not work, why then the Fedoraproject model of 
self-selecting volunteers maintaining packages is broken, and 
Red Hat employees (which, if one examines the poster's 
employer, is who want to 'parachute in' and use PP rights, in 
the first five cases I checked) should simply do all the 
commits

> The needs of Fedora must win in this case.

The predicate was a straw man based on facts not present in 
this thread --- 'must win' seems to overstate the case.  Why 
then even bother to have process?  Let it all hang out and 
anyone commit as one will.  Well, this turns out not to work, 
as we tried this with release three of the post RHL cAos 
project, long ago, and got a royal mess with such a lack of 
process

...
 
> Given your email address, I am going to assume you’re paid 
> by you’re employer to work on Fedora, and are not working on 
> Fedora by your own volition. This is the time when your 
> mentor should step in set some of the ground rules for how 
> you interact with a community.

so, now, an 'ad hominem' attack in rhetoric as well?  So much 
for 'being excellent' to one another

-- Russ herrold
 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Miroslav Suchý]

Dne 8.12.2017 v 18:33 Adam Williamson napsal(a):
> How long will it be before you can get the modernization/cleanup
> finished? You're going to be sitting there waiting for 50 people to
> respond to pull requests,

A week? And only then do the change directly? Sometimes the maintainers have a 
reason to not include such change.

Mirek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removing old cruft, e.g. Provides: systemd-units (was Re: What to I have to do....)

[Richard Shaw]

On Sun, Dec 10, 2017 at 4:28 AM, Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> After reading all responses in thread which is mentioned in subject I
> think we
> need to develop some policies / procedures how to deal with old cruft, for
> example:
>
> - - Requires: systemd-units
> - - Requires: /bin/mktemp
>
> Former has changed to systemd in guidelines X years ago (not sure when
> exactly,
> before I did my first package which contains systemd units, so I would
> guess
> something like 5-6 years ago). Latter was removed more then decade ago but
> we
> kept old Provides around for compatibility and seems after 10 years people
> still rely on them.
>
> Do you have ideas how policy / procedure of removal those should look like?


Maybe a good first step would be to add detection of these to rpmlint? I
usually try the skim my spec files for modernization stuff but I know I
don't catch everything. A tool (rpmlint or otherwise) would be very helpful.

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Graham Leggett]

On 07 Dec 2017, at 5:31 PM, Steve Dickson  wrote:

> Where committed to the master branch and not to any other
> branch make the maintenance of those branches a pain 
> because I can no longer cherry-pick between branches.
> I have to make multiple commits to multiple branches
> which sucks... Something random people do not understand!

In this case, we have the needs of the Fedora project (this change) stacked up 
against your needs (your reluctance to perform a task).

The needs of Fedora must win in this case.

The Fedora project, as with all collaborative open source projects, succeeds 
when the collaborators collaborate. The Fedora project fails when people carve 
out a niche for themselves and refuse to play nice with others within that 
niche.

Given your email address, I am going to assume you’re paid by you’re employer 
to work on Fedora, and are not working on Fedora by your own volition. This is 
the time when your mentor should step in set some of the ground rules for how 
you interact with a community.

When you work on Fedora you’re working on a shared codebase that isn’t yours. 
Other people will make changes to code you’ve worked on, and they are not only 
allowed to do that, and they should be actively encouraged to do that, and be 
thanked for their work.

As an end user of Fedora, I am grateful for the work done, including this 
change, and thank the person who made the change to have taken the time to do 
it.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Removing old cruft, e.g. Provides: systemd-units (was Re: What to I have to do....)

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

After reading all responses in thread which is mentioned in subject I think we
need to develop some policies / procedures how to deal with old cruft, for
example:

- - Requires: systemd-units
- - Requires: /bin/mktemp

Former has changed to systemd in guidelines X years ago (not sure when exactly,
before I did my first package which contains systemd units, so I would guess
something like 5-6 years ago). Latter was removed more then decade ago but we
kept old Provides around for compatibility and seems after 10 years people
still rely on them.

Do you have ideas how policy / procedure of removal those should look like?
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlotDFMACgkQaVcUvRu8
X0yN2w//ZXwg9/bPRlBDSB7qe9dIEJEdJS4XAC1OdLGLDiscrCXjxhEj6HUpQ/nw
Y0SQsICNs+QSsU2rggZ0n6w5DzWNU0CFPZbN73YfGnNvG8r6Tcv2Gy3zwKg8KwVq
ihmr9HJwJvRpYs+ACwIIXZZUxhFnp4/ZM8skyqoN/V8TRBZiLqmaGozZ8xkkx8c/
4R1PEXYxWgoIVAarV3JFo7SEqU2VXFjfHQXTsGfinHkgfpp5U5tRcUShFJDMlo8/
90AtOXLd6wNh3pBTz9feM2PpAguQHXWDVFOWH+7dAlERZw6CeUmFMko0dqsR8UN7
6M/jOnXHO8eVRqKn8A41fXx1TeMoRsjHHSd2D+fb3ghHNzLKHX0fxphZJwgdGYce
1c00DoguOl7WIPRzIL+yrdNF3DbJeRTUhN4/ch+T5M08itOLQSDWxGDxbdfOxwNs
55pNHrD7QaupZjLox3zOZag5Uq378ZK80mwp0pochl0xBQ3L1xQLuBOEcye7Sh6+
niwQF/oMFn0y6F59N0arYi9d6Izg53Zf7FeZUuiiZDC93Uf9ifdZC6hLwjlZUToa
8Kf2tiSQI75WuUXZdUhTbeQJ8JNExxCSy6275KPbU4fB7hTd7tRkr/SclRek1ifz
pGU4xIyC3cu5h1XlfgvTp/zeKS69x3ZimI7ZtdN37nbhlzwRc7I=
=XP3c
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2017-12-08 at 08:40 -0500, Steve Dickson wrote:
> Hey,
> 
> On 12/07/2017 02:31 PM, Florian Weimer wrote:
> > On 12/07/2017 04:31 PM, Steve Dickson wrote:
> > > Where committed to the master branch and not to any other
> > > branch make the maintenance of those branches a pain
> > > because I can no longer cherry-pick between branches.
> > 
> > Maybe you can elaborate on how this causes problems for your 
> > development process, and we can find a way to avoid that?
> 
> I think the best way to avoid these problems is have any all changes
> go through the maintainer... Now I understand build issue where 
> the flux capacitor breaks and the issue needs to be fix relatively
> quickly... fine... but is was not the case... This was remove/changing
> logic in the packaging... which easily gone through the maintainer 
> via the push mechanism.

One of commits **was** the case. It would cause broken dependencies / FTBFS of
package and users would notice this.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlotCgYACgkQaVcUvRu8
X0zIvA//bMFOnXaA1cPsMOKNU+5qSf8s7gHvXl6IjnsU0Bdy5eelwxk7XTWgzctb
08m9FkPCUIX/hqMfbOxgublBaS6R9LqFtXlNB+rT4lqe54UyjZKc7FROYFuWjg9N
2HrSGeSviB8aLhIwqKQe/LM/48c6Chq4M6wrfasZi5Yzktw9nGUV+hSMvFCmOJd+
14xOHlIMVSn6AqlBzeylgCpJOuiBt7Em4IZkAPLNwfm1Lixip5gcofUz7Gd8K4Df
GQWzgVlDkl+xIpSkPZ0naJcshivXduEZSKQVx6R5x7vTgaZDHqttCfExdVbB/TCK
2sb5U0FRAEQOhsFVpRbjdsQYCZLyJaO/mjd26kQlL+C6E9m69layoF0uzALmlGWo
UFWlfyKJw+Va8WyRT8dNLzq8hH8HnyePmLW441ayxVlEqJ8y70vuL5N/FS+Fue6U
azVAupUcrvWaV0rXQBVnHeI6ZdCrZrSZ6Xi3pJw9S0CWGHQt/T64bCshQfbYKh9I
LVorIr5bJgw6SXMX6uuJbTarJBmEaRGWvdGrE1RQn730tQGbmc97lVF+TTAC/mDa
3PE7b0ZkuxsxBsr+tKWavXz0NBFrjGAiwpIe66oZdG03uFnyz5gbDIscAtwpOXjg
TCOhLH5KCp0bXLDpYNz8sLCXG05sbkrrcG4/R+A20MIFrbKiOOs=
=bNOc
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Zbigniew Jędrzejewski-Szmek]

On Sat, Dec 09, 2017 at 09:10:13PM +, Philip Kovacs wrote:
> It's just simple human courtesy. 

A good analogy is saying "Hello" when you meet somebody on the street.
You live in a village and it's unthinkable not do it. Then you move to
a small town and everybody still does, except when it's the market day.
And then you move to a city and you stop, because you wouldn't be able
to do it fast enough even if you wanted.

My point is that when circumstances change, what is "courteous" also
changes. For you the short message from the pp doing the cleanup is
something you expect, but for him or her it's hours of overhead
because human communication¹ is much harder to automatize then the
actual changes, and for the other 350 maintainers also receiving the
"courteous" message it's unwanted communication that prevents them
from doing their work.

Zbyszek

¹ Sending a template e-mail or bugzilla is not a big issue, but monitoring
the tickets, and reading the replies, and closing the bugs over the course
of months or years _is_.

PS. Something is off with your quoting — your reply runs directly into
the quote you are replying to. You can see how your message looks in
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TMO2IK7EE67P7MBYHIQDOEMWPRDXHHI4/.
Make sure to start your reply from a new line.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2017-12-07 at 10:31 -0500, Steve Dickson wrote:
> Hello,
> 
> What do I have to do to stop random people 
> from making random changes to packages I maintain? 
> 
> How do people get this type of permission?
> 
> Case in point;
> 
> commit 358a8fff974f0e124527a3281c90fa04cb7c7a7f (HEAD -> master,
> origin/master, origin/HEAD)
> Author: Igor Gnatenko 
> Date:   Tue Nov 7 16:31:21 2017 +0100
> 
> Remove old crufty coreutils requires
> 
> Signed-off-by: Igor Gnatenko 

Would be better if you would get broken dependencies and people would complain?
I saved time for you.

> commit 66851ea12370a786844262620a40b0a2ac9632ce
> Author: Igor Gnatenko 
> Date:   Tue Nov 7 16:31:14 2017 +0100
> 
> systemd-units -> systemd
> 
> Signed-off-by: Igor Gnatenko 

systemd-units is deprecated for very long time, since I was fixing your
package, I decided to bring it up with current packaging guidelines (also given
how this change is trivial).

> Where committed to the master branch and not to any other
> branch make the maintenance of those branches a pain 
> because I can no longer cherry-pick between branches.
> I have to make multiple commits to multiple branches
> which sucks... Something random people do not understand!

You can merge those commits into any other branches (if you want to), nothing
prevents you from this.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlotCMcACgkQaVcUvRu8
X0ycchAAmzObjEq5+oOlxg/wUqdBkWD6c623XkAOd1Rbg0DoSdQWnOCISMbtes6p
3906dpz0gvLcuKXx4+5yBxBP3wuXauXV5YgNvzNu6H9wUCLMZ+A83TwphvoZoOsr
PCPhTwWZjDQA5Z1llNX8w6imZbj5wm3fccE0FeEXBA0aKWntFbDemRXcVrKUO9EF
DVtKtzmiUcFnhkgEpYlRuQsM59hbCbIZZsYPNy8XPIy/5wFLA4yJJS9Te4X1cE1M
NTq1QXneC+NIHMNw8nlUIA4sXw7pQskGlm/W6MmOz6YtUk9lX2sNbl9oI7XDBfq8
y/GAOkckvR25fQnNiB26G9uZMhxEXSdqKWmwiBsgTzHAJtx6hYL4wS/lOmUmzjri
jY03zcFplx87Tn9yBW6E+HrQg1f6RAC73GmVabP8uTlJ4XicpKq1xrlSkFUk2pMO
onZ2+e2x4bZpgVXshMFjZuEWvoiosKepknckjChC30hSmTCNVRHnP9C5aUxhO9xB
v6y1zJUZB0T22rkUI/+P2moDCFra3tdiXt4y4rNJU274Wrln81PMHGX6N5Nf9lTb
aZF7fDzTqKUvd6TQ1nRyriZ8LkL6qMDQ3V60RbWhV1OBxhDURwHc6n4wCC6mrmxz
j+4r5duGWVc0dc7CdhoApZEdIoubXidfr2fUXbS/dpIwsPOvMh4=
=wawh
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Philip Kovacs]

>I deeply believe that such maintainers and such packages as you
>describe must become a thing of a past.  For the moment, until your new world 
>order arrives, packages are maintained by people of all types volunteering 
>their time and effort.  These are people who will probably never even hear a 
>thank you from anyone for their efforts.  One important way to extend to them 
>respect and gratitude for that contribution is to notify them prior to 
>changing the files they spent time maintaining.   It's just simple human 
>courtesy. 

On Saturday, December 9, 2017 2:13 PM, Zbigniew Jędrzejewski-Szmek 
 wrote:
 

 On Sat, Dec 09, 2017 at 06:26:28PM +, Philip Kovacs wrote:
> s/do want/do NOT want 
> 
>    On Saturday, December 9, 2017 1:21 PM, Philip Kovacs  
>wrote:
>  
> 
>  I am opposed to allowing PP unfettered access to projects in which
>  the maintainer(s) are responsive.  It's common for developers to
>  have artistic (volatile) temperaments , like a painter who paints
>  on canvas owned by someone else.

It's possible that this it crux of the difference between different
sides in this thread.

I deeply believe that such maintainers and such packages as you
describe must become a thing of a past. Don't get me wrong — I have
been there, I have done that (über-complicated packages, spec files
full of custom code) — and I think was a waste of time. If a program
requires a complicated spec file, then usually something is wrong with
the program.

Look at the recent fedora-devel thread "Forge-hosted projects
packaging automation": all the valiant efforts by maintainers to
express their creativity by fighting with github and gitlab hosting and
commit hashes and git tags and tarballs are replaced by very-strictly
scripted approach where you just define a few fields and let the
tooling do the rest.

The same story happened with python packaging a while back: all the
ways to call setup.py are replaced by a very boring %py_build and
%py_install invocations.

Fedora as a distro is moving away from arcane setups where only one or
two people can make changes towards team maintenance and having
everything simplified to avoid mistakes and documented to make things
easy for newcomers. I'd say that this is a trend which is true for all
of the Linux ecosystem. People have realized that bus factors of one
or two are bad for long term sustainability. Eh, even the kernel now
has sphinx-based docs so you can actually read the stuff.

The reason why that is happening is that we have ever more packages,
released more often, with a smaller maintainer/package ratio then
ever. If you want to scale, you need to simplify and automate.
Essentially, expressing your creativity/spirit/style in how the
whitespace is organized and how macros are defined is passé.

Zbyszek


  Does the owner have the right to change the color jars?  Perhaps.  Does the  
owner have the right to look at the painting and say "I don't like the way you 
painted that tree.  I'm going to change it."  Absolutely not.
> Perhaps add a project setting that allows package maintainers to configure 
> how PP changes can be made, by direct commit, by pull request, etc.  That 
> would allow maintainerswho are more "involved" with their packages to have 
> more control.   It's a common management problem.  People who have taken on 
> responsibility must also have control to the extent to which system allows.  
> You certainly do want to drive good people away..  
> 
>    On Saturday, December 9, 2017 5:06 AM, Matthias Runge 
> wrote:
>  
> 
>  On Fri, Dec 08, 2017 at 08:30:20PM +0100, Matthias Runge wrote:
> > Now this has gone back and forth. The system worked more or less ok.
> > Maybe it is more about the changes (and communication) of a
> > specific provenpackager?
> 
> After sleeping a night over this, I should have put it in different
> words:
> 
> My questionis are here:
> - do we have an issue at all?
> - do we have an issue with a single provenpacker
> - do we have an issue of attitude or with a group of people?
> 
> The consensus of this long thread was: no, the system works mostly ok.
> That makes me believe, we don't have a generic issue.
> 
> It's not my intention to blame anyone here, I'm still assuming best
> intentions.
> 
> Nevertheless, since people are different, and not everybody can be
> friends with each other, maybe it's a good idea to make communication
> mandatory, in cases where proven packagers touch others packages? For
> mass changes, there is/should always be an announcement to the
> devel mailing list.
> 
> Matthias
> -- 
> Matthias Runge 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> 
>    
> 
>    

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To 

Re: What to I have to do....

[Zbigniew Jędrzejewski-Szmek]

On Sat, Dec 09, 2017 at 06:26:28PM +, Philip Kovacs wrote:
> s/do want/do NOT want 
> 
> On Saturday, December 9, 2017 1:21 PM, Philip Kovacs  
> wrote:
>  
> 
>  I am opposed to allowing PP unfettered access to projects in which
>  the maintainer(s) are responsive.  It's common for developers to
>  have artistic (volatile) temperaments , like a painter who paints
>  on canvas owned by someone else.

It's possible that this it crux of the difference between different
sides in this thread.

I deeply believe that such maintainers and such packages as you
describe must become a thing of a past. Don't get me wrong — I have
been there, I have done that (über-complicated packages, spec files
full of custom code) — and I think was a waste of time. If a program
requires a complicated spec file, then usually something is wrong with
the program.

Look at the recent fedora-devel thread "Forge-hosted projects
packaging automation": all the valiant efforts by maintainers to
express their creativity by fighting with github and gitlab hosting and
commit hashes and git tags and tarballs are replaced by very-strictly
scripted approach where you just define a few fields and let the
tooling do the rest.

The same story happened with python packaging a while back: all the
ways to call setup.py are replaced by a very boring %py_build and
%py_install invocations.

Fedora as a distro is moving away from arcane setups where only one or
two people can make changes towards team maintenance and having
everything simplified to avoid mistakes and documented to make things
easy for newcomers. I'd say that this is a trend which is true for all
of the Linux ecosystem. People have realized that bus factors of one
or two are bad for long term sustainability. Eh, even the kernel now
has sphinx-based docs so you can actually read the stuff.

The reason why that is happening is that we have ever more packages,
released more often, with a smaller maintainer/package ratio then
ever. If you want to scale, you need to simplify and automate.
Essentially, expressing your creativity/spirit/style in how the
whitespace is organized and how macros are defined is passé.

Zbyszek


  Does the owner have the right to change the color jars?  Perhaps.  Does the  
owner have the right to look at the painting and say "I don't like the way you 
painted that tree.  I'm going to change it."  Absolutely not.
> Perhaps add a project setting that allows package maintainers to configure 
> how PP changes can be made, by direct commit, by pull request, etc.  That 
> would allow maintainerswho are more "involved" with their packages to have 
> more control.   It's a common management problem.  People who have taken on 
> responsibility must also have control to the extent to which system allows.  
> You certainly do want to drive good people away..  
> 
> On Saturday, December 9, 2017 5:06 AM, Matthias Runge 
>  wrote:
>  
> 
>  On Fri, Dec 08, 2017 at 08:30:20PM +0100, Matthias Runge wrote:
> > Now this has gone back and forth. The system worked more or less ok.
> > Maybe it is more about the changes (and communication) of a
> > specific provenpackager?
> 
> After sleeping a night over this, I should have put it in different
> words:
> 
> My questionis are here:
> - do we have an issue at all?
> - do we have an issue with a single provenpacker
> - do we have an issue of attitude or with a group of people?
> 
> The consensus of this long thread was: no, the system works mostly ok.
> That makes me believe, we don't have a generic issue.
> 
> It's not my intention to blame anyone here, I'm still assuming best
> intentions.
> 
> Nevertheless, since people are different, and not everybody can be
> friends with each other, maybe it's a good idea to make communication
> mandatory, in cases where proven packagers touch others packages? For
> mass changes, there is/should always be an announcement to the
> devel mailing list.
> 
> Matthias
> -- 
> Matthias Runge 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> 
>
> 
>

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Philip Kovacs]

s/do want/do NOT want 

On Saturday, December 9, 2017 1:21 PM, Philip Kovacs  
wrote:
 

 I am opposed to allowing PP unfettered access to projects in which the 
maintainer(s) are responsive.  It's common for developers to have artistic 
(volatile) temperaments , like a painter who paints on canvas owned by someone 
else.  Does the owner have the right to change the color jars?  Perhaps.  Does 
the  owner have the right to look at the painting and say "I don't like the way 
you painted that tree.  I'm going to change it."  Absolutely not.
Perhaps add a project setting that allows package maintainers to configure how 
PP changes can be made, by direct commit, by pull request, etc.  That would 
allow maintainerswho are more "involved" with their packages to have more 
control.   It's a common management problem.  People who have taken on 
responsibility must also have control to the extent to which system allows.  
You certainly do want to drive good people away..  

On Saturday, December 9, 2017 5:06 AM, Matthias Runge 
 wrote:
 

 On Fri, Dec 08, 2017 at 08:30:20PM +0100, Matthias Runge wrote:
> Now this has gone back and forth. The system worked more or less ok.
> Maybe it is more about the changes (and communication) of a
> specific provenpackager?

After sleeping a night over this, I should have put it in different
words:

My questionis are here:
- do we have an issue at all?
- do we have an issue with a single provenpacker
- do we have an issue of attitude or with a group of people?

The consensus of this long thread was: no, the system works mostly ok.
That makes me believe, we don't have a generic issue.

It's not my intention to blame anyone here, I'm still assuming best
intentions.

Nevertheless, since people are different, and not everybody can be
friends with each other, maybe it's a good idea to make communication
mandatory, in cases where proven packagers touch others packages? For
mass changes, there is/should always be an announcement to the
devel mailing list.

Matthias
-- 
Matthias Runge 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   

   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Philip Kovacs]

I am opposed to allowing PP unfettered access to projects in which the 
maintainer(s) are responsive.  It's common for developers to have artistic 
(volatile) temperaments , like a painter who paints on canvas owned by someone 
else.  Does the owner have the right to change the color jars?  Perhaps.  Does 
the  owner have the right to look at the painting and say "I don't like the way 
you painted that tree.  I'm going to change it."  Absolutely not.
Perhaps add a project setting that allows package maintainers to configure how 
PP changes can be made, by direct commit, by pull request, etc.  That would 
allow maintainerswho are more "involved" with their packages to have more 
control.   It's a common management problem.  People who have taken on 
responsibility must also have control to the extent to which system allows.  
You certainly do want to drive good people away..  

On Saturday, December 9, 2017 5:06 AM, Matthias Runge 
 wrote:
 

 On Fri, Dec 08, 2017 at 08:30:20PM +0100, Matthias Runge wrote:
> Now this has gone back and forth. The system worked more or less ok.
> Maybe it is more about the changes (and communication) of a
> specific provenpackager?

After sleeping a night over this, I should have put it in different
words:

My questionis are here:
- do we have an issue at all?
- do we have an issue with a single provenpacker
- do we have an issue of attitude or with a group of people?

The consensus of this long thread was: no, the system works mostly ok.
That makes me believe, we don't have a generic issue.

It's not my intention to blame anyone here, I'm still assuming best
intentions.

Nevertheless, since people are different, and not everybody can be
friends with each other, maybe it's a good idea to make communication
mandatory, in cases where proven packagers touch others packages? For
mass changes, there is/should always be an announcement to the
devel mailing list.

Matthias
-- 
Matthias Runge 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Matthias Runge]

On Fri, Dec 08, 2017 at 08:30:20PM +0100, Matthias Runge wrote:
> Now this has gone back and forth. The system worked more or less ok.
> Maybe it is more about the changes (and communication) of a
> specific provenpackager?

After sleeping a night over this, I should have put it in different
words:

My questionis are here:
- do we have an issue at all?
- do we have an issue with a single provenpacker
- do we have an issue of attitude or with a group of people?

The consensus of this long thread was: no, the system works mostly ok.
That makes me believe, we don't have a generic issue.

It's not my intention to blame anyone here, I'm still assuming best
intentions.

Nevertheless, since people are different, and not everybody can be
friends with each other, maybe it's a good idea to make communication
mandatory, in cases where proven packagers touch others packages? For
mass changes, there is/should always be an announcement to the
devel mailing list.

Matthias
-- 
Matthias Runge 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Florian Weimer]

On 12/08/2017 06:48 PM, Adam Williamson wrote:

On Fri, 2017-12-08 at 10:45 -0600, Michael Cronenworth wrote:

On 12/08/2017 10:40 AM, Steve Dickson wrote:

You are telling me there hundreds of people that have complete
control over all the packages in fedora with no boundaries???
They can do anything they what??? Wow...


Not really. There are a handful of packages that are protected. I tried to push 
a
grub2 update for a change that maintainers ignored for years. I couldn't create
updates in Bodhi and my rawhide build, although successful, was not properly 
signed
for release to the repos.


The whole boot chain is restricted in this way due to Secure Boot,
basically; we have to restrict who is allowed to build boot chain
packages to satisfy requirements of the Secure Boot signing program.


I'm not in any special Fedora group and I can build and tag glibc, so 
whatever protection is in place (if any is at all), it is very limited 
at best.


(While glibc is not itself part of the boot chain, it is part of its 
build process, and thus among of the trusted set of packages.)


Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Matthias Runge]

On Fri, Dec 08, 2017 at 11:46:03AM -0500, Steve Dickson wrote:
> 
> 
> On 12/08/2017 11:21 AM, Charalampos Stratakis wrote:
> > The kernel is actually blacklisted from proven packager access, you can't 
> > make changes there.
> This is good to know... how do you get on that list? ;-) 
> > 
> > Apart from that though, I don't really see any reasons for creating this 
> > thread.
> > 
> > Proven packagers do trivial and non-trivial cleanups all the time. While I 
> > agree that a PR would be better,
> > when dealing with changes on a vast amount of packages that should be 
> > ideally done in a timely manner, waiting for a
> > timely response from every single maintainer of the respective packages is 
> > just not realistic.
> I understand the need to make massive changes... I no problem with that...
> The problem is random people are making non-critical, non-massive 
> changes because they "feel" its the right thing to do. Those
> changes should go through the maintainer. 

Now this has gone back and forth. The system worked more or less ok.
Maybe it is more about the changes (and communication) of a
specific provenpackager?

There has been a recent thread "stop messing with other people packages",
and Iwonder who the mentioned proven packager was in that case.

I had once a case, where even a bug was filed by the pp, the change
submitted and bug closed after. I was online and reading emails at
that time, but I didn't had the chance to react. I asked the pp to
wait for my reaction in a reasonable time before doing that again.

Unfortunately, some time later, the same proven packager changed
something else. It was just a cosmetic change, and he didn't even
try to contact me, neither via irc, nor email or bugzilla.

So, maybe this is just caused by the behaviour of a single person?

Matthias
-- 
Matthias Runge 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Steve Dickson]

On 12/08/2017 12:33 PM, Adam Williamson wrote:
> On Fri, 2017-12-08 at 12:01 -0500, Steve Dickson wrote:
>> Then on the other hand I get these pull-requests that
>> work so well! 
>>
>> So I just don't understand why for non-massive changes
>> why is it not required to go through the pull-request
>> process?
> 
> There is a pedestrian reason, which is that the pull request system is
> very *new*. It's only been there a couple of months. So it's not
> surprising that all existing policies haven't been rewritten around it.
Fair enough... It is a very good system. 

> 
> But there are also the practical reasons others have given several
> times but you have just ignored in your multiple replies. Put yourself
> in the shoes of a provenpackager who needs to make corresponding
> changes to, say, 50 packages. All those changes need to go through
> before an important modernization/cleanup to another package can be
> completed, for instance.
> 
> Now you file 50 pull requests. And wait. And wait. And wait...
Guilty as charged... :-) 

This is a massive change... I do get that.. 

> 
> How long will it be before you can get the modernization/cleanup
> finished? You're going to be sitting there waiting for 50 people to
> respond to pull requests, and it's a racing certainty at least one of
> them just *won't*. In the mean time you'll be working on other things,
> and losing track. It just makes it much harder to get important stuff
> done. Fedora is a *distribution*, and a large part of being a
> distribution is some level of consistency in the way we provide
> software to people. It's *important* that we have a mechanism by which
> we can make a reasonable cut at having multiple packages, maintained by
> different people, do things the same way - and have the packages
> changed promptly when those policies change.
> 
> I wouldn't say this is an open-and-shut case, there are reasonable
> arguments in favor of using the PR process for changes, sometimes or
> always. But I agree with other folks that you're not doing yourself any
> favours by acting as if this policy is clearly insane and you're the
> only sane person in the room, and as if there had been some sort of
> major controversy or disaster when there hasn't. 
Sane person?? You are actually calling me a sane person!?? That's a first... ;-)

I just think its odd to have so many people that can changes so
much without any boundaries... I just didn't realize that was the case.

> Someone fixed up some
> dependencies in your package which you should've fixed yourself years
> ago. That's the sum total of what happened. Your git complaints don't
> seem to make sense to anyone else and you've refused to explain exactly
> what this special workflow you have is despite more than one person
> specifically asking you.
This time... but there has been other changes... 

> 
> Important note: I'm a proven packager. I make changes to other packages
> when I judge that it's appropriate to do so, under the policy.
> 
I think making these single changes via the PR system would be
the best policy.

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Adam Williamson]

On Fri, 2017-12-08 at 10:45 -0600, Michael Cronenworth wrote:
> On 12/08/2017 10:40 AM, Steve Dickson wrote:
> > You are telling me there hundreds of people that have complete
> > control over all the packages in fedora with no boundaries???
> > They can do anything they what??? Wow...
> 
> Not really. There are a handful of packages that are protected. I tried to 
> push a 
> grub2 update for a change that maintainers ignored for years. I couldn't 
> create 
> updates in Bodhi and my rawhide build, although successful, was not properly 
> signed 
> for release to the repos.

The whole boot chain is restricted in this way due to Secure Boot,
basically; we have to restrict who is allowed to build boot chain
packages to satisfy requirements of the Secure Boot signing program.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Simo Sorce]

On Fri, 2017-12-08 at 12:11 -0500, Steve Dickson wrote:
> 
> On 12/08/2017 11:54 AM, Simo Sorce wrote:
> > On Fri, 2017-12-08 at 11:40 -0500, Steve Dickson wrote:
> > > 
> > > On 12/08/2017 11:12 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > > > Well, I'd say this works great. There's maybe a hundred or two hundred
> > > > proven packagers and somehow none of them decide to mess up the kernel
> > > > any day. In fact, the commits which caused this thread are _correct_:
> > > > so far I haven't heard one word to the contrary. I don't see any point
> > > > in discussing hypotheticals.
> > > 
> > > You are telling me there hundreds of people that have complete
> > > control over all the packages in fedora with no boundaries???
> > > They can do anything they what??? Wow...
> > 
> > 
> > Steve, this is not really shocking.
> > Git has history, so you can always see anything that changes, and
> > maintainers are supposed to keep an eye on their packages and so they
> > will see any malicious intent immediately, right ?
> 
> Right.
> > If it is not malicious it is just helping, and there is nothing wrong
> > with that.
> 
> But if it is non-massive, non-critical shouldn't the maintainer be notified?
> All I'm saying yes, via a pull-request.

This would be ideal, yes, but for very trivial and obviously correct
changes I do not see the strict need for that overhead.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Kevin Fenzi]

On 12/08/2017 08:33 AM, Pierre-Yves Chibon wrote:
> On Fri, Dec 08, 2017 at 11:21:10AM -0500, Charalampos Stratakis wrote:
>> - Original Message -
 Unless you want to say that the change is somehow wrong, please
 don't say that "poeple [...] are clueless", because that's disingenuous.
>>> Fair enough... "clueless" was probably not the most appropriate
>>> term to use... But I just read this policy.
>>>
>>>https://fedoraproject.org/wiki/Provenpackager_policy
>>>
>>> It is very broad... IHMO.. You open a ticket, get three acks
>>> a boom! You know have complete access every Fedora package
>>> including the kernel... hmm...
>>>
>>
>> The kernel is actually blacklisted from proven packager access, you can't 
>> make changes there.
> 
> While this used to be true it hasn't been for a while now, I think the last
> packages that are restricted are: xulrunner, thunderbird and firefox due to
> mozilla's trademark policy on them.

The be 100% clear, there's 2 different kinds of packages that
provenpackagers cannot "affect":

1. as mentioned, firefox and thunderbird due to trademark (xulrunner
used to be, but it's dead now) provenpackagers cannot commit to these
packages.

2. There's a small number of packages in the secure-boot channel that
build on secure boot builders, but only if submitted by users with the
secure-boot permission. Provenpackages can commit changes to these
packages fine, but any builds they do will not be tagged in.
These packages currently are: kernel shim grub2 fedora-release
fedora-repos pesign.

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Justin Forbes]

On Fri, Dec 8, 2017 at 10:33 AM, Pierre-Yves Chibon  wrote:
> On Fri, Dec 08, 2017 at 11:21:10AM -0500, Charalampos Stratakis wrote:
>> - Original Message -
>> > > Unless you want to say that the change is somehow wrong, please
>> > > don't say that "poeple [...] are clueless", because that's disingenuous.
>> > Fair enough... "clueless" was probably not the most appropriate
>> > term to use... But I just read this policy.
>> >
>> >https://fedoraproject.org/wiki/Provenpackager_policy
>> >
>> > It is very broad... IHMO.. You open a ticket, get three acks
>> > a boom! You know have complete access every Fedora package
>> > including the kernel... hmm...
>> >
>>
>> The kernel is actually blacklisted from proven packager access, you can't 
>> make changes there.
>
> While this used to be true it hasn't been for a while now, I think the last
> packages that are restricted are: xulrunner, thunderbird and firefox due to
> mozilla's trademark policy on them.
>
Kernel has a different protection mechanism, where anyone with commit
access can do a build, but only the kernel team can do a signed build.
Even people who contribute to the kernel regularly cannot do signed
builds.

Justin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Adam Williamson]

On Fri, 2017-12-08 at 12:01 -0500, Steve Dickson wrote:
> Then on the other hand I get these pull-requests that
> work so well! 
> 
> So I just don't understand why for non-massive changes
> why is it not required to go through the pull-request
> process?

There is a pedestrian reason, which is that the pull request system is
very *new*. It's only been there a couple of months. So it's not
surprising that all existing policies haven't been rewritten around it.

But there are also the practical reasons others have given several
times but you have just ignored in your multiple replies. Put yourself
in the shoes of a provenpackager who needs to make corresponding
changes to, say, 50 packages. All those changes need to go through
before an important modernization/cleanup to another package can be
completed, for instance.

Now you file 50 pull requests. And wait. And wait. And wait...

How long will it be before you can get the modernization/cleanup
finished? You're going to be sitting there waiting for 50 people to
respond to pull requests, and it's a racing certainty at least one of
them just *won't*. In the mean time you'll be working on other things,
and losing track. It just makes it much harder to get important stuff
done. Fedora is a *distribution*, and a large part of being a
distribution is some level of consistency in the way we provide
software to people. It's *important* that we have a mechanism by which
we can make a reasonable cut at having multiple packages, maintained by
different people, do things the same way - and have the packages
changed promptly when those policies change.

I wouldn't say this is an open-and-shut case, there are reasonable
arguments in favor of using the PR process for changes, sometimes or
always. But I agree with other folks that you're not doing yourself any
favours by acting as if this policy is clearly insane and you're the
only sane person in the room, and as if there had been some sort of
major controversy or disaster when there hasn't. Someone fixed up some
dependencies in your package which you should've fixed yourself years
ago. That's the sum total of what happened. Your git complaints don't
seem to make sense to anyone else and you've refused to explain exactly
what this special workflow you have is despite more than one person
specifically asking you.

Important note: I'm a proven packager. I make changes to other packages
when I judge that it's appropriate to do so, under the policy.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Dominik 'Rathann' Mierzejewski]

On Friday, 08 December 2017 at 18:07, Steve Dickson wrote:
[...]
> > A proven packager is not someone random, they were given access
> > based on various criteria and that IMHO includes the fact that
> > their perception or "feels" about what has to be done on other
> > people's packages, is aligned with what has to be done for the
> > overall improvement of the distribution. 
> Fine... I understand your point... they have broader perspective...
> 
> But can't they ask the maintainer to act on their feeling via a
> pull-request?

Who says they can't or shouldn't? I think you're preaching to the
choir here... Before pagure, I used to open a bug on bugzilla
and threaten to commit the proposed change myself if there was no
reaction in a week or two. Now, for one-off change I'd definitely
open a pull request.

Regards,
Dominik (provenpackager)
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Emmanuel Seyman]

* Steve Dickson [08/12/2017 12:11] :
>
> But if it is non-massive, non-critical shouldn't the maintainer be notified?

If it's trivial, I'm ok with being informed via fedmsg telling me a commit has
been made. In this case, this was a trivial fix that the maintainer should have
done years ago so I can understand the provenpackager not going through the
whole pull-request song and dance.

In another thread, another fedora packager is asking that we stop sending all
email to packagers, arguing that nobody actually needs to know the history of
their packages, only their current state. The contrast between this packager's
opinion and yours is... interesting.

Emmanuel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Steve Dickson]

On 12/08/2017 12:10 PM, Mathieu Bridon wrote:
> On Fri, 2017-12-08 at 12:01 -0500, Steve Dickson wrote:
>> On 12/08/2017 11:46 AM, Mathieu Bridon wrote:
>>> You're blowing this way out of proportion, as if this was a
>>> catastrophe. History shows that it isn't.
>>
>> Maybe I am... Would not be the first time! ;-)
>>
>> In last couple of months there were a couple of changes
>> that were non-critical so I'm getting the feeling
>> people are getting a bit embolden... which is worrisome.
>>
>> Then on the other hand I get these pull-requests that
>> work so well! 
>>
>> So I just don't understand why for non-massive changes
>> why is it not required to go through the pull-request
>> process?
> 
> This wasn't a trivial change.
> 
> It certainly was trivial for each package it got applied to, but it got
> applied to quite a few packages.
> 
> That's essentially a similar change to mass-rebuilds, just at a smaller
> scale.
> 
> It was also announced properly on this list, enough time in advance, so
> it shouldn't have taken you by surprise.
> 
> If you really want to insist on the maintainers's responsibilities,
> start by reading announcements on this list.
:-) This is a very tough list to keep up with I generally 
look for things on delve-annou...@lists.fedoraproject.org
I must have missed it... 

pull-request go directly to my in box... much easier to find ;-)

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Steve Dickson]

On 12/08/2017 11:54 AM, Simo Sorce wrote:
> On Fri, 2017-12-08 at 11:40 -0500, Steve Dickson wrote:
>>
>> On 12/08/2017 11:12 AM, Zbigniew Jędrzejewski-Szmek wrote:
>>> Well, I'd say this works great. There's maybe a hundred or two hundred
>>> proven packagers and somehow none of them decide to mess up the kernel
>>> any day. In fact, the commits which caused this thread are _correct_:
>>> so far I haven't heard one word to the contrary. I don't see any point
>>> in discussing hypotheticals.
>>
>> You are telling me there hundreds of people that have complete
>> control over all the packages in fedora with no boundaries???
>> They can do anything they what??? Wow...
> 
> 
> Steve, this is not really shocking.
> Git has history, so you can always see anything that changes, and
> maintainers are supposed to keep an eye on their packages and so they
> will see any malicious intent immediately, right ?
Right.
> If it is not malicious it is just helping, and there is nothing wrong
> with that.
But if it is non-massive, non-critical shouldn't the maintainer be notified?
All I'm saying yes, via a pull-request.

steved.
> 
> Simo.
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Mathieu Bridon]

On Fri, 2017-12-08 at 12:01 -0500, Steve Dickson wrote:
> On 12/08/2017 11:46 AM, Mathieu Bridon wrote:
> > You're blowing this way out of proportion, as if this was a
> > catastrophe. History shows that it isn't.
> 
> Maybe I am... Would not be the first time! ;-)
> 
> In last couple of months there were a couple of changes
> that were non-critical so I'm getting the feeling
> people are getting a bit embolden... which is worrisome.
> 
> Then on the other hand I get these pull-requests that
> work so well! 
> 
> So I just don't understand why for non-massive changes
> why is it not required to go through the pull-request
> process?

This wasn't a trivial change.

It certainly was trivial for each package it got applied to, but it got
applied to quite a few packages.

That's essentially a similar change to mass-rebuilds, just at a smaller
scale.

It was also announced properly on this list, enough time in advance, so
it shouldn't have taken you by surprise.

If you really want to insist on the maintainers's responsibilities,
start by reading announcements on this list.


-- 
Mathieu
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 08, 2017 at 11:52:21AM -0500, Steve Dickson wrote:
> 
> 
> On 12/08/2017 11:28 AM, Kalev Lember wrote:
> > On 12/08/2017 05:17 PM, Zbigniew Jędrzejewski-Szmek wrote:
> >> On Fri, Dec 08, 2017 at 10:59:20AM -0500, Steve Dickson wrote:
> >>>
> >>>
> >>> On 12/08/2017 10:12 AM, Zbigniew Jędrzejewski-Szmek wrote:
>  How would the overhead be lower? Instead of a single clean commit that
>  does what needs to be done you want the person doing this cleanup on a
>  hundred packages to send you a special message and wait while you make
>  the decision whether to allow a three line change or not? Please explain.
> >>> Who determines "needs to be done" Shouldn't the owner of the package be in
> >>> on the determination, with silents being acceptance after a certain amount
> >>> of time? I think so.
> >>
> >> This is completely infeasible to contact each maintainer individually
> >> when doing massive changes. The policy specifies that the mass change
> >> should be pre-announced, discussed, and announced on the mailing list.
> >> This procedure was followed, the changes are simple and correct.
> My apologies for not making myself clear... I understand the
> need to make massive changes... The problem I have is a single
> change is made because it "feels" right... Those changes need to
> go by the maintainer.
> 
> >>
> >>> Yes to your second question... For one reason... maintaining stability.
> >>> You give people the ability to change anything and everything they
> >>> want w/out any review... that is called instability... 
> >>
> >> No, those changes don't have any effect on the way that your package
> >> operates, they just change the reference from an obsolete name to
> >> one that actually exists. Without such changes we would have more
> >> and more obsolete cruft in packages. It's great that somebody is willing
> >> to spend their time keeping the distro tidy. Change, if done carefully,
> >> does not mean instability.
> > 
> > I wholeheartedly agree with Zbyszek here. Well said.
> I too agree WRT massive build and/or changes... but anything
> else need to go through them maintainer. 

Well, it _is_ a massive change: ignatenkobrain is removing references
to systemd-units. According to repoquery, in F26 there are 369
packages with R: systemd-units. I'd say that 369 qualifies as "mass".

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Steve Dickson]

On 12/08/2017 11:59 AM, Charalampos Stratakis wrote:
> 
> 
> - Original Message -
>> From: "Steve Dickson" <ste...@redhat.com>
>> To: "Development discussions related to Fedora" 
>> <devel@lists.fedoraproject.org>, "Charalampos Stratakis"
>> <cstra...@redhat.com>
>> Cc: "Zbigniew Jędrzejewski-Szmek" <zbys...@in.waw.pl>, "Yaakov Selkowitz" 
>> <yselk...@redhat.com>
>> Sent: Friday, December 8, 2017 5:46:03 PM
>> Subject: Re: What to I have to do
>>
>>
>>
>> On 12/08/2017 11:21 AM, Charalampos Stratakis wrote:
>>> The kernel is actually blacklisted from proven packager access, you can't
>>> make changes there.
>> This is good to know... how do you get on that list? ;-)
>>>
>>> Apart from that though, I don't really see any reasons for creating this
>>> thread.
>>>
>>> Proven packagers do trivial and non-trivial cleanups all the time. While I
>>> agree that a PR would be better,
>>> when dealing with changes on a vast amount of packages that should be
>>> ideally done in a timely manner, waiting for a
>>> timely response from every single maintainer of the respective packages is
>>> just not realistic.
>> I understand the need to make massive changes... I no problem with that...
>> The problem is random people are making non-critical, non-massive
>> changes because they "feel" its the right thing to do. Those
>> changes should go through the maintainer.
>>
>> steved.
>>
> 
> You will have to realize though, that at the moment you are currently talking 
> from your perspective and only, so basically about your "feels" on the matter.
> 
> And while certainly there might have been cases where a proven packager acted 
> inappropriately, I don't see that particular case as such.
I agree..
> 
> A proven packager is not someone random, they were given access based on 
> various criteria and that IMHO includes the fact that their perception or 
> "feels"
> about what has to be done on other people's packages, is aligned with what 
> has to be done for the overall improvement of the distribution. 
Fine... I understand your point... they have broader perspective...

But can't they ask the maintainer to act on their feeling via a pull-request?

steved. 
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 08, 2017 at 10:45:47AM -0600, Michael Cronenworth wrote:
> On 12/08/2017 10:40 AM, Steve Dickson wrote:
> >You are telling me there hundreds of people that have complete
> >control over all the packages in fedora with no boundaries???
> >They can do anything they what??? Wow...
> 
> Not really. There are a handful of packages that are protected. I
> tried to push a grub2 update for a change that maintainers ignored
> for years. I couldn't create updates in Bodhi and my rawhide build,
> although successful, was not properly signed for release to the
> repos.

That's true. I made a stab [1] at having those "special" packages
documented in the spec file a while back, so that proven packagers
would know that certain packages should not be touched, but it never
went anywhere (FPC only clarified the guideline that dist-git is the
canonical source of the spec file).

[1] https://pagure.io/packaging-committee/issue/613

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Steve Dickson]

On 12/08/2017 11:46 AM, Mathieu Bridon wrote:
> On Fri, 2017-12-08 at 11:40 -0500, Steve Dickson wrote:
>>
>> On 12/08/2017 11:12 AM, Zbigniew Jędrzejewski-Szmek wrote:
>>> Well, I'd say this works great. There's maybe a hundred or two
>>> hundred proven packagers and somehow none of them decide to mess up
>>> the kernel any day. In fact, the commits which caused this thread
>>> are _correct_:
>>> so far I haven't heard one word to the contrary. I don't see any
>>> point in discussing hypotheticals.
>>
>> You are telling me there hundreds of people that have complete
>> control over all the packages in fedora with no boundaries???
>> They can do anything they what??? Wow...
> 
> And it's working just fine, because overall people understand their
> responsibilities and don't abuse their powers.
> 
> If someone ever does go too far, their probvenpackagers permissions can
> be revoked and the bad changes they made can be reverted.
Good to know... 
> 
> You're blowing this way out of proportion, as if this was a
> catastrophe. History shows that it isn't.
Maybe I am... Would not be the first time! ;-)

In last couple of months there were a couple of changes
that were non-critical so I'm getting the feeling
people are getting a bit embolden... which is worrisome.

Then on the other hand I get these pull-requests that
work so well! 

So I just don't understand why for non-massive changes
why is it not required to go through the pull-request
process?

steved.
> 
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Charalampos Stratakis]

- Original Message -
> From: "Steve Dickson" <ste...@redhat.com>
> To: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>, "Charalampos Stratakis"
> <cstra...@redhat.com>
> Cc: "Zbigniew Jędrzejewski-Szmek" <zbys...@in.waw.pl>, "Yaakov Selkowitz" 
> <yselk...@redhat.com>
> Sent: Friday, December 8, 2017 5:46:03 PM
> Subject: Re: What to I have to do
> 
> 
> 
> On 12/08/2017 11:21 AM, Charalampos Stratakis wrote:
> > The kernel is actually blacklisted from proven packager access, you can't
> > make changes there.
> This is good to know... how do you get on that list? ;-)
> > 
> > Apart from that though, I don't really see any reasons for creating this
> > thread.
> > 
> > Proven packagers do trivial and non-trivial cleanups all the time. While I
> > agree that a PR would be better,
> > when dealing with changes on a vast amount of packages that should be
> > ideally done in a timely manner, waiting for a
> > timely response from every single maintainer of the respective packages is
> > just not realistic.
> I understand the need to make massive changes... I no problem with that...
> The problem is random people are making non-critical, non-massive
> changes because they "feel" its the right thing to do. Those
> changes should go through the maintainer.
> 
> steved.
> 

You will have to realize though, that at the moment you are currently talking 
from your perspective and only, so basically about your "feels" on the matter.

And while certainly there might have been cases where a proven packager acted 
inappropriately, I don't see that particular case as such.

A proven packager is not someone random, they were given access based on 
various criteria and that IMHO includes the fact that their perception or 
"feels"
about what has to be done on other people's packages, is aligned with what has 
to be done for the overall improvement of the distribution. 

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Simo Sorce]

On Fri, 2017-12-08 at 11:40 -0500, Steve Dickson wrote:
> 
> On 12/08/2017 11:12 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > Well, I'd say this works great. There's maybe a hundred or two hundred
> > proven packagers and somehow none of them decide to mess up the kernel
> > any day. In fact, the commits which caused this thread are _correct_:
> > so far I haven't heard one word to the contrary. I don't see any point
> > in discussing hypotheticals.
> 
> You are telling me there hundreds of people that have complete
> control over all the packages in fedora with no boundaries???
> They can do anything they what??? Wow...


Steve, this is not really shocking.
Git has history, so you can always see anything that changes, and
maintainers are supposed to keep an eye on their packages and so they
will see any malicious intent immediately, right ?
If it is not malicious it is just helping, and there is nothing wrong
with that.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Stephen John Smoogen]

On 8 December 2017 at 11:40, Steve Dickson  wrote:
>
>
> On 12/08/2017 11:12 AM, Zbigniew Jędrzejewski-Szmek wrote:
>> Well, I'd say this works great. There's maybe a hundred or two hundred
>> proven packagers and somehow none of them decide to mess up the kernel
>> any day. In fact, the commits which caused this thread are _correct_:
>> so far I haven't heard one word to the contrary. I don't see any point
>> in discussing hypotheticals.
> You are telling me there hundreds of people that have complete
> control over all the packages in fedora with no boundaries???
> They can do anything they what??? Wow...
>

This seems to come up after every major release.. a change is
announced, it goes through the process, and then the proven developer
makes the change.. and then some developer has their package changed
and complains that they didn't read the announcements, they don't like
the fact that proven packagers can touch their packages, and similar
things. We then have a long thread war where the developer finds out
how many proven packagers there are and go on a tear about how did
this happen?

In the past, the next step is "If you don't like it open a ticket with
FESCO with a plan on how to deal with this because the mailing list is
just going to be an echo chamber and nothing will be changed".

I believe in the past this has led to some changes but I am not as
much a developer as someone with a long memory of regular flamewars.

> steved.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Steve Dickson]

On 12/08/2017 11:28 AM, Kalev Lember wrote:
> On 12/08/2017 05:17 PM, Zbigniew Jędrzejewski-Szmek wrote:
>> On Fri, Dec 08, 2017 at 10:59:20AM -0500, Steve Dickson wrote:
>>>
>>>
>>> On 12/08/2017 10:12 AM, Zbigniew Jędrzejewski-Szmek wrote:
 How would the overhead be lower? Instead of a single clean commit that
 does what needs to be done you want the person doing this cleanup on a
 hundred packages to send you a special message and wait while you make
 the decision whether to allow a three line change or not? Please explain.
>>> Who determines "needs to be done" Shouldn't the owner of the package be in
>>> on the determination, with silents being acceptance after a certain amount
>>> of time? I think so.
>>
>> This is completely infeasible to contact each maintainer individually
>> when doing massive changes. The policy specifies that the mass change
>> should be pre-announced, discussed, and announced on the mailing list.
>> This procedure was followed, the changes are simple and correct.
My apologies for not making myself clear... I understand the
need to make massive changes... The problem I have is a single
change is made because it "feels" right... Those changes need to
go by the maintainer.

>>
>>> Yes to your second question... For one reason... maintaining stability.
>>> You give people the ability to change anything and everything they
>>> want w/out any review... that is called instability... 
>>
>> No, those changes don't have any effect on the way that your package
>> operates, they just change the reference from an obsolete name to
>> one that actually exists. Without such changes we would have more
>> and more obsolete cruft in packages. It's great that somebody is willing
>> to spend their time keeping the distro tidy. Change, if done carefully,
>> does not mean instability.
> 
> I wholeheartedly agree with Zbyszek here. Well said.
I too agree WRT massive build and/or changes... but anything
else need to go through them maintainer. 

steved.

> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Mathieu Bridon]

On Fri, 2017-12-08 at 11:40 -0500, Steve Dickson wrote:
> 
> On 12/08/2017 11:12 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > Well, I'd say this works great. There's maybe a hundred or two
> > hundred proven packagers and somehow none of them decide to mess up
> > the kernel any day. In fact, the commits which caused this thread
> > are _correct_:
> > so far I haven't heard one word to the contrary. I don't see any
> > point in discussing hypotheticals.
> 
> You are telling me there hundreds of people that have complete
> control over all the packages in fedora with no boundaries???
> They can do anything they what??? Wow...

And it's working just fine, because overall people understand their
responsibilities and don't abuse their powers.

If someone ever does go too far, their probvenpackagers permissions can
be revoked and the bad changes they made can be reverted.

You're blowing this way out of proportion, as if this was a
catastrophe. History shows that it isn't.


-- 
Mathieu
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Steve Dickson]

On 12/08/2017 11:21 AM, Charalampos Stratakis wrote:
> The kernel is actually blacklisted from proven packager access, you can't 
> make changes there.
This is good to know... how do you get on that list? ;-) 
> 
> Apart from that though, I don't really see any reasons for creating this 
> thread.
> 
> Proven packagers do trivial and non-trivial cleanups all the time. While I 
> agree that a PR would be better,
> when dealing with changes on a vast amount of packages that should be ideally 
> done in a timely manner, waiting for a
> timely response from every single maintainer of the respective packages is 
> just not realistic.
I understand the need to make massive changes... I no problem with that...
The problem is random people are making non-critical, non-massive 
changes because they "feel" its the right thing to do. Those
changes should go through the maintainer. 

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Michael Cronenworth]

On 12/08/2017 10:40 AM, Steve Dickson wrote:

You are telling me there hundreds of people that have complete
control over all the packages in fedora with no boundaries???
They can do anything they what??? Wow...


Not really. There are a handful of packages that are protected. I tried to push a 
grub2 update for a change that maintainers ignored for years. I couldn't create 
updates in Bodhi and my rawhide build, although successful, was not properly signed 
for release to the repos.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Steve Dickson]

On 12/08/2017 11:12 AM, Zbigniew Jędrzejewski-Szmek wrote:
> Well, I'd say this works great. There's maybe a hundred or two hundred
> proven packagers and somehow none of them decide to mess up the kernel
> any day. In fact, the commits which caused this thread are _correct_:
> so far I haven't heard one word to the contrary. I don't see any point
> in discussing hypotheticals.
You are telling me there hundreds of people that have complete
control over all the packages in fedora with no boundaries???
They can do anything they what??? Wow...

steved. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Pierre-Yves Chibon]

On Fri, Dec 08, 2017 at 11:21:10AM -0500, Charalampos Stratakis wrote:
> - Original Message -
> > > Unless you want to say that the change is somehow wrong, please
> > > don't say that "poeple [...] are clueless", because that's disingenuous.
> > Fair enough... "clueless" was probably not the most appropriate
> > term to use... But I just read this policy.
> > 
> >https://fedoraproject.org/wiki/Provenpackager_policy
> > 
> > It is very broad... IHMO.. You open a ticket, get three acks
> > a boom! You know have complete access every Fedora package
> > including the kernel... hmm...
> > 
> 
> The kernel is actually blacklisted from proven packager access, you can't 
> make changes there.

While this used to be true it hasn't been for a while now, I think the last
packages that are restricted are: xulrunner, thunderbird and firefox due to
mozilla's trademark policy on them.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Kalev Lember]

On 12/08/2017 05:17 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Dec 08, 2017 at 10:59:20AM -0500, Steve Dickson wrote:
>>
>>
>> On 12/08/2017 10:12 AM, Zbigniew Jędrzejewski-Szmek wrote:
>>> How would the overhead be lower? Instead of a single clean commit that
>>> does what needs to be done you want the person doing this cleanup on a
>>> hundred packages to send you a special message and wait while you make
>>> the decision whether to allow a three line change or not? Please explain.
>> Who determines "needs to be done" Shouldn't the owner of the package be in
>> on the determination, with silents being acceptance after a certain amount
>> of time? I think so.
> 
> This is completely infeasible to contact each maintainer individually
> when doing massive changes. The policy specifies that the mass change
> should be pre-announced, discussed, and announced on the mailing list.
> This procedure was followed, the changes are simple and correct.
> 
>> Yes to your second question... For one reason... maintaining stability.
>> You give people the ability to change anything and everything they
>> want w/out any review... that is called instability... 
> 
> No, those changes don't have any effect on the way that your package
> operates, they just change the reference from an obsolete name to
> one that actually exists. Without such changes we would have more
> and more obsolete cruft in packages. It's great that somebody is willing
> to spend their time keeping the distro tidy. Change, if done carefully,
> does not mean instability.

I wholeheartedly agree with Zbyszek here. Well said.

-- 
Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Charalampos Stratakis]

- Original Message -
> From: "Steve Dickson" <ste...@redhat.com>
> To: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>, "Zbigniew Jędrzejewski-Szmek"
> <zbys...@in.waw.pl>
> Cc: "Yaakov Selkowitz" <yselk...@redhat.com>
> Sent: Friday, December 8, 2017 4:31:58 PM
> Subject: Re: What to I have to do
> 
> 
> 
> On 12/08/2017 10:07 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Fri, Dec 08, 2017 at 08:31:44AM -0500, Steve Dickson wrote:
> >>
> >>
> >> On 12/07/2017 02:18 PM, Yaakov Selkowitz wrote:
> >>> On 2017-12-07 09:31, Steve Dickson wrote:
> >>>> What do I have to do to stop random people
> >>>> from making random changes to packages I maintain?
> >>>>
> >>>> How do people get this type of permission?
> >>>
> >>> https://fedoraproject.org/wiki/Provenpackager_policy
> >>>
> >>>> Case in point;
> >>> [snip]
> >>>
> >>> These were properly announced:
> >>>
> >>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RJYQNLIWBAVQPGLIGUT77WGY5D4TK334/
> >>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YKPCYY2JJOAQG67X4I6ZNYRHNYDCNQFL/
> >>>
> >>> This is proper use of the provenpackager privileges.
> >> Which will lead to the instability... IMHO... Allowing people to
> >> to change technology that they are clueless of is just wrong.
> > 
> > I think that's exactly the point ;)
> > We are allowing people who have the knack and inclination to do "boring"
> > cleanups to do them so that _maintainers_ can actually concentrate on
> > _technology_.
> > 
> > From your message one could think that the changes are some massive
> > reworking, but both commits are completely trivial updates of
> > dependencies on package names that have been gone for _years_.
> > 
> > Unless you want to say that the change is somehow wrong, please
> > don't say that "poeple [...] are clueless", because that's disingenuous.
> Fair enough... "clueless" was probably not the most appropriate
> term to use... But I just read this policy.
> 
>https://fedoraproject.org/wiki/Provenpackager_policy
> 
> It is very broad... IHMO.. You open a ticket, get three acks
> a boom! You know have complete access every Fedora package
> including the kernel... hmm...
> 
> steved.
> 

The kernel is actually blacklisted from proven packager access, you can't make 
changes there.

Apart from that though, I don't really see any reasons for creating this thread.

Proven packagers do trivial and non-trivial cleanups all the time. While I 
agree that a PR would be better,
when dealing with changes on a vast amount of packages that should be ideally 
done in a timely manner, waiting for a
timely response from every single maintainer of the respective packages is just 
not realistic.

> > 
> > Zbyszek
> > 
> >> What is the point of maintainers-ship if any one and everyone can
> >> make changes? Any and all changes must go through the maintainer
> >> if that is not the case the way even have them?
> >>  
> >> steved.
> >>  
> >>>
> >>>
> >>>
> >>> ___
> >>> devel mailing list -- devel@lists.fedoraproject.org
> >>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >>>
> >> ___
> >> devel mailing list -- devel@lists.fedoraproject.org
> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Sérgio Basto]

On Fri, 2017-12-08 at 09:14 -0500, Steve Dickson wrote:
> 
> On 12/07/2017 06:13 PM, Sérgio Basto wrote:
> > On Thu, 2017-12-07 at 10:31 -0500, Steve Dickson wrote:
> > > Hello,
> > > 
> > > What do I have to do to stop random people 
> > > from making random changes to packages I maintain? 
> > > 
> > > How do people get this type of permission?
> > > 
> > > Case in point;
> > > 
> > > commit 358a8fff974f0e124527a3281c90fa04cb7c7a7f (HEAD -> master,
> > > origin/master, origin/HEAD)
> > > Author: Igor Gnatenko 
> > > Date:   Tue Nov 7 16:31:21 2017 +0100
> > > 
> > > Remove old crufty coreutils requires
> > > 
> > > Signed-off-by: Igor Gnatenko  > > g>
> > > 
> > > commit 66851ea12370a786844262620a40b0a2ac9632ce
> > > Author: Igor Gnatenko 
> > > Date:   Tue Nov 7 16:31:14 2017 +0100
> > > 
> > > systemd-units -> systemd
> > > 
> > > Signed-off-by: Igor Gnatenko  > > g>
> > > 
> > > Where committed to the master branch and not to any other
> > > branch make the maintenance of those branches a pain 
> > > because I can no longer cherry-pick between branches.
> > > I have to make multiple commits to multiple branches
> > > which sucks... Something random people do not understand!
> > > 
> > > There is a pull mechanism... Why was that not used??
> > > 
> > > Maintaining the stability of packages is hard enough
> > > esp packages everybody uses... but that stability
> > > goes out the window when random people allowed to
> > > make random changes...
> > > 
> > > Who are these super humans, how do they become 
> > > super humans and why aren't they required to 
> > > use the pull mechanism?? 
> > 
> > I don't agree with you, you may contact the super human and ask him
> > why
> > ? you may revert the commit . 
> 
> Overhead that is simply not needed if the maintainer was consulted
> first.
> 
> > 
> > IMHO we shouldn't inhibit people do his best, we already have lots
> > of
> > work, is kernel updates , glibc updates , gcc updates , systemd ,
> > etc
> > etc ... (hopefully) 
> 
> Ah so you can make a changes to Linus' kernel at anytime you what?? 
> Wow I'm impressed 8-) (sarcasm... probably not necessary)

I mean, I (and others packagers maintainers) have lots of work after
one gcc or kernel or other features update. I can enumerate lots of
changes that requires me to work on updates of the packages, if you
saw, my emails on this list, now I'm try to deal with drop of
the webkitgtk and webkitgtk3, just for example.

> My point is this... People with the best intentions can easily
> introduce stability issues by changes packages they don't fully
> understand. All changes, other than time critical ones, should
> go through the maintainer... I just don't understand why that
> is too much to ask?

I think we live in 2 different worlds (one is the world of well
maintained packages and other is the world of abandoned packages), as
described above the lots of work to well maintain the packages leads in
abandoned packages. Even I, which do my best, I don't have all packages
well maintained, so make one pull request may be a waste of time. 
Even have to wait some hours or days for a reply is a problem for who
want help to maintain the packages. 

> > 
> > As wrote in coreuitls commit 
> > " Remove very old Provides (mktemp, sh-utils, textwrap, fileutils,
> > stat) Those are gone in fc9, more than decade ago."
> > 
> > Nobody takes care of opencv for example , despite a very long bug
> > report, we got bugs like  822844 [1] opened in 2012-05-18  to
> > update
> > giflib, my problem here is I don't know if giflib is used anymore
> > or if
> > have a replacement etc, so just do a monkey update is not enough
> > for
> > me. 
> > I got more and more SELinux bugs, people more and more enable
> > SELinux ,
> > but SE team doesn't have time to fix it or something like that . 
> > 
> > So I think you should write (offlist) to the people which made the
> > commits , and understand the motivation , and organize with him the
> > best way of committing in "your" packages. 
> 
> This is the second this happen and the first time I did go offlist. 
> 

But the commit that I mention here, should be done 10 years ago ! , so
for me, that is the main problem, why the package wasn't not updated
before ?  

Best regards, 

> So I'm going onlist because I'm seeing a trend... People seems
> to think they can make any changes they want w/out going 
> through the maintainer. That is a very bad trend... IMHO.
> 
> steved.
> 
> > 
> > Best regards,
> > 
> > [1]
> > https://bugzilla.redhat.com/show_bug.cgi?id=822844
> > 
> > > steved.
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-leave@lists.fedoraproject.o
> > > rg
-- 
Sérgio M. B.
___

Re: What to I have to do....

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 08, 2017 at 10:59:20AM -0500, Steve Dickson wrote:
> 
> 
> On 12/08/2017 10:12 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Fri, Dec 08, 2017 at 09:14:35AM -0500, Steve Dickson wrote:
> >>
> >>
> >> On 12/07/2017 06:13 PM, Sérgio Basto wrote:
> >>> On Thu, 2017-12-07 at 10:31 -0500, Steve Dickson wrote:
>  Hello,
> 
>  What do I have to do to stop random people 
>  from making random changes to packages I maintain? 
> 
>  How do people get this type of permission?
> 
>  Case in point;
> 
>  commit 358a8fff974f0e124527a3281c90fa04cb7c7a7f (HEAD -> master,
>  origin/master, origin/HEAD)
>  Author: Igor Gnatenko 
>  Date:   Tue Nov 7 16:31:21 2017 +0100
> 
>  Remove old crufty coreutils requires
>  
>  Signed-off-by: Igor Gnatenko 
> 
>  commit 66851ea12370a786844262620a40b0a2ac9632ce
>  Author: Igor Gnatenko 
>  Date:   Tue Nov 7 16:31:14 2017 +0100
> 
>  systemd-units -> systemd
>  
>  Signed-off-by: Igor Gnatenko 
> 
>  Where committed to the master branch and not to any other
>  branch make the maintenance of those branches a pain 
>  because I can no longer cherry-pick between branches.
>  I have to make multiple commits to multiple branches
>  which sucks... Something random people do not understand!
> 
>  There is a pull mechanism... Why was that not used??
> 
>  Maintaining the stability of packages is hard enough
>  esp packages everybody uses... but that stability
>  goes out the window when random people allowed to
>  make random changes...
> 
>  Who are these super humans, how do they become 
>  super humans and why aren't they required to 
>  use the pull mechanism?? 
> >>>
> >>> I don't agree with you, you may contact the super human and ask him why
> >>> ? you may revert the commit . 
> >> Overhead that is simply not needed if the maintainer was consulted first.
> > 
> > How would the overhead be lower? Instead of a single clean commit that
> > does what needs to be done you want the person doing this cleanup on a
> > hundred packages to send you a special message and wait while you make
> > the decision whether to allow a three line change or not? Please explain.
> Who determines "needs to be done" Shouldn't the owner of the package be in
> on the determination, with silents being acceptance after a certain amount
> of time? I think so.

This is completely infeasible to contact each maintainer individually
when doing massive changes. The policy specifies that the mass change
should be pre-announced, discussed, and announced on the mailing list.
This procedure was followed, the changes are simple and correct.

> Yes to your second question... For one reason... maintaining stability.
> You give people the ability to change anything and everything they
> want w/out any review... that is called instability... 

No, those changes don't have any effect on the way that your package
operates, they just change the reference from an obsolete name to
one that actually exists. Without such changes we would have more
and more obsolete cruft in packages. It's great that somebody is willing
to spend their time keeping the distro tidy. Change, if done carefully,
does not mean instability.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 08, 2017 at 10:31:58AM -0500, Steve Dickson wrote:
> 
> 
> On 12/08/2017 10:07 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Fri, Dec 08, 2017 at 08:31:44AM -0500, Steve Dickson wrote:
> >>
> >>
> >> On 12/07/2017 02:18 PM, Yaakov Selkowitz wrote:
> >>> On 2017-12-07 09:31, Steve Dickson wrote:
>  What do I have to do to stop random people 
>  from making random changes to packages I maintain? 
> 
>  How do people get this type of permission?
> >>>
> >>> https://fedoraproject.org/wiki/Provenpackager_policy
> >>>
>  Case in point;
> >>> [snip]
> >>>
> >>> These were properly announced:
> >>>
> >>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RJYQNLIWBAVQPGLIGUT77WGY5D4TK334/
> >>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YKPCYY2JJOAQG67X4I6ZNYRHNYDCNQFL/
> >>>
> >>> This is proper use of the provenpackager privileges.
> >> Which will lead to the instability... IMHO... Allowing people to
> >> to change technology that they are clueless of is just wrong.
> > 
> > I think that's exactly the point ;)
> > We are allowing people who have the knack and inclination to do "boring"
> > cleanups to do them so that _maintainers_ can actually concentrate on
> > _technology_.
> > 
> > From your message one could think that the changes are some massive
> > reworking, but both commits are completely trivial updates of
> > dependencies on package names that have been gone for _years_.
> > 
> > Unless you want to say that the change is somehow wrong, please
> > don't say that "poeple [...] are clueless", because that's disingenuous.
> Fair enough... "clueless" was probably not the most appropriate 
> term to use... But I just read this policy.
> 
>https://fedoraproject.org/wiki/Provenpackager_policy
> 
> It is very broad... IHMO.. You open a ticket, get three acks
> a boom! You know have complete access every Fedora package
> including the kernel... hmm...

Well, I'd say this works great. There's maybe a hundred or two hundred
proven packagers and somehow none of them decide to mess up the kernel
any day. In fact, the commits which caused this thread are _correct_:
so far I haven't heard one word to the contrary. I don't see any point
in discussing hypotheticals.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Steve Dickson]

On 12/08/2017 10:12 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Dec 08, 2017 at 09:14:35AM -0500, Steve Dickson wrote:
>>
>>
>> On 12/07/2017 06:13 PM, Sérgio Basto wrote:
>>> On Thu, 2017-12-07 at 10:31 -0500, Steve Dickson wrote:
 Hello,

 What do I have to do to stop random people 
 from making random changes to packages I maintain? 

 How do people get this type of permission?

 Case in point;

 commit 358a8fff974f0e124527a3281c90fa04cb7c7a7f (HEAD -> master,
 origin/master, origin/HEAD)
 Author: Igor Gnatenko 
 Date:   Tue Nov 7 16:31:21 2017 +0100

 Remove old crufty coreutils requires
 
 Signed-off-by: Igor Gnatenko 

 commit 66851ea12370a786844262620a40b0a2ac9632ce
 Author: Igor Gnatenko 
 Date:   Tue Nov 7 16:31:14 2017 +0100

 systemd-units -> systemd
 
 Signed-off-by: Igor Gnatenko 

 Where committed to the master branch and not to any other
 branch make the maintenance of those branches a pain 
 because I can no longer cherry-pick between branches.
 I have to make multiple commits to multiple branches
 which sucks... Something random people do not understand!

 There is a pull mechanism... Why was that not used??

 Maintaining the stability of packages is hard enough
 esp packages everybody uses... but that stability
 goes out the window when random people allowed to
 make random changes...

 Who are these super humans, how do they become 
 super humans and why aren't they required to 
 use the pull mechanism?? 
>>>
>>> I don't agree with you, you may contact the super human and ask him why
>>> ? you may revert the commit . 
>> Overhead that is simply not needed if the maintainer was consulted first.
> 
> How would the overhead be lower? Instead of a single clean commit that
> does what needs to be done you want the person doing this cleanup on a
> hundred packages to send you a special message and wait while you make
> the decision whether to allow a three line change or not? Please explain.
Who determines "needs to be done" Shouldn't the owner of the package be in
on the determination, with silents being acceptance after a certain amount
of time? I think so.

Yes to your second question... For one reason... maintaining stability.
You give people the ability to change anything and everything they
want w/out any review... that is called instability... 

With the only accept being the mass rebuild that are done.
If something is breaking that then that has to be fixed, asap.
 
steved. 
   
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Steve Dickson]

On 12/08/2017 10:07 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Dec 08, 2017 at 08:31:44AM -0500, Steve Dickson wrote:
>>
>>
>> On 12/07/2017 02:18 PM, Yaakov Selkowitz wrote:
>>> On 2017-12-07 09:31, Steve Dickson wrote:
 What do I have to do to stop random people 
 from making random changes to packages I maintain? 

 How do people get this type of permission?
>>>
>>> https://fedoraproject.org/wiki/Provenpackager_policy
>>>
 Case in point;
>>> [snip]
>>>
>>> These were properly announced:
>>>
>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RJYQNLIWBAVQPGLIGUT77WGY5D4TK334/
>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YKPCYY2JJOAQG67X4I6ZNYRHNYDCNQFL/
>>>
>>> This is proper use of the provenpackager privileges.
>> Which will lead to the instability... IMHO... Allowing people to
>> to change technology that they are clueless of is just wrong.
> 
> I think that's exactly the point ;)
> We are allowing people who have the knack and inclination to do "boring"
> cleanups to do them so that _maintainers_ can actually concentrate on
> _technology_.
> 
> From your message one could think that the changes are some massive
> reworking, but both commits are completely trivial updates of
> dependencies on package names that have been gone for _years_.
> 
> Unless you want to say that the change is somehow wrong, please
> don't say that "poeple [...] are clueless", because that's disingenuous.
Fair enough... "clueless" was probably not the most appropriate 
term to use... But I just read this policy.

   https://fedoraproject.org/wiki/Provenpackager_policy

It is very broad... IHMO.. You open a ticket, get three acks
a boom! You know have complete access every Fedora package
including the kernel... hmm...

steved.

> 
> Zbyszek
> 
>> What is the point of maintainers-ship if any one and everyone can 
>> make changes? Any and all changes must go through the maintainer
>> if that is not the case the way even have them?
>>  
>> steved.
>>  
>>>
>>>
>>>
>>> ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 08, 2017 at 09:14:35AM -0500, Steve Dickson wrote:
> 
> 
> On 12/07/2017 06:13 PM, Sérgio Basto wrote:
> > On Thu, 2017-12-07 at 10:31 -0500, Steve Dickson wrote:
> >> Hello,
> >>
> >> What do I have to do to stop random people 
> >> from making random changes to packages I maintain? 
> >>
> >> How do people get this type of permission?
> >>
> >> Case in point;
> >>
> >> commit 358a8fff974f0e124527a3281c90fa04cb7c7a7f (HEAD -> master,
> >> origin/master, origin/HEAD)
> >> Author: Igor Gnatenko 
> >> Date:   Tue Nov 7 16:31:21 2017 +0100
> >>
> >> Remove old crufty coreutils requires
> >> 
> >> Signed-off-by: Igor Gnatenko 
> >>
> >> commit 66851ea12370a786844262620a40b0a2ac9632ce
> >> Author: Igor Gnatenko 
> >> Date:   Tue Nov 7 16:31:14 2017 +0100
> >>
> >> systemd-units -> systemd
> >> 
> >> Signed-off-by: Igor Gnatenko 
> >>
> >> Where committed to the master branch and not to any other
> >> branch make the maintenance of those branches a pain 
> >> because I can no longer cherry-pick between branches.
> >> I have to make multiple commits to multiple branches
> >> which sucks... Something random people do not understand!
> >>
> >> There is a pull mechanism... Why was that not used??
> >>
> >> Maintaining the stability of packages is hard enough
> >> esp packages everybody uses... but that stability
> >> goes out the window when random people allowed to
> >> make random changes...
> >>
> >> Who are these super humans, how do they become 
> >> super humans and why aren't they required to 
> >> use the pull mechanism?? 
> > 
> > I don't agree with you, you may contact the super human and ask him why
> > ? you may revert the commit . 
> Overhead that is simply not needed if the maintainer was consulted first.

How would the overhead be lower? Instead of a single clean commit that
does what needs to be done you want the person doing this cleanup on a
hundred packages to send you a special message and wait while you make
the decision whether to allow a three line change or not? Please explain.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 08, 2017 at 08:31:44AM -0500, Steve Dickson wrote:
> 
> 
> On 12/07/2017 02:18 PM, Yaakov Selkowitz wrote:
> > On 2017-12-07 09:31, Steve Dickson wrote:
> >> What do I have to do to stop random people 
> >> from making random changes to packages I maintain? 
> >>
> >> How do people get this type of permission?
> > 
> > https://fedoraproject.org/wiki/Provenpackager_policy
> > 
> >> Case in point;
> > [snip]
> > 
> > These were properly announced:
> > 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RJYQNLIWBAVQPGLIGUT77WGY5D4TK334/
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YKPCYY2JJOAQG67X4I6ZNYRHNYDCNQFL/
> > 
> > This is proper use of the provenpackager privileges.
> Which will lead to the instability... IMHO... Allowing people to
> to change technology that they are clueless of is just wrong.

I think that's exactly the point ;)
We are allowing people who have the knack and inclination to do "boring"
cleanups to do them so that _maintainers_ can actually concentrate on
_technology_.

From your message one could think that the changes are some massive
reworking, but both commits are completely trivial updates of
dependencies on package names that have been gone for _years_.

Unless you want to say that the change is somehow wrong, please
don't say that "poeple [...] are clueless", because that's disingenuous.

Zbyszek

> What is the point of maintainers-ship if any one and everyone can 
> make changes? Any and all changes must go through the maintainer
> if that is not the case the way even have them?
>  
> steved.
>  
> > 
> > 
> > 
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Steve Dickson]

On 12/07/2017 03:37 PM, R P Herrold wrote:
> On Thu, 7 Dec 2017, Yaakov Selkowitz wrote:
> 
>> https://fedoraproject.org/wiki/Provenpackager_policy
> 
>> These were properly announced:
>>
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RJYQNLIWBAVQPGLIGUT77WGY5D4TK334/
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YKPCYY2JJOAQG67X4I6ZNYRHNYDCNQFL/
> 
> That section provides in relevant part:
> 
>> Provenpackagers should try to communicate with owners of a 
> package in bugzilla, irc or email prior to making changes
> 
> IMHO, A general email to a high traffic mailing list is 
> insufficient
> 
> IRC is even worse for notification
> 
> Absent some pressing need (which was NOT present here -- this 
> was just 'distribution housecleaning'), this was insufficient 
> notice on a non-urgent matter, to my thinking
I've been using the the term "push mechanism" but I should
have should been using the term pull-requests

These pull-request are wonderful things! They should be *required*
any and all non-critical, cleanup, etc changes to packages
by non maintainers... It it is time critical... mark it time critical.

This process documents the need for a change, notifies the maintainer
and allow the maintainer a chance to respond... If now response 
the super human makes the change... 

We have tools and process to maintain stability Lets use them!

steved.  
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Steve Dickson]

On 12/08/2017 09:00 AM, Florian Weimer wrote:
> On 12/08/2017 02:40 PM, Steve Dickson wrote:
>> Hey,
>>
>> On 12/07/2017 02:31 PM, Florian Weimer wrote:
>>> On 12/07/2017 04:31 PM, Steve Dickson wrote:
 Where committed to the master branch and not to any other
 branch make the maintenance of those branches a pain
 because I can no longer cherry-pick between branches.
>>>
>>> Maybe you can elaborate on how this causes problems for your
>>> development process, and we can find a way to avoid that?
> 
>> I think the best way to avoid these problems is have any all changes
>> go through the maintainer...
> 
> That doesn't work if the maintainer doesn't react in a timely fashion to bug 
> reports, as it is the case for many maintainers unfortunately.  For 
> non-critical issues, this is quite understandable, too.
Yes and No... If there is a bug report and the maintainer is unresponsive... 
that is one thing 
because the maintainer has gotten bugzilla email about it

If the problem is that critical the maintainer usually gets
pinged... I know I have been in the past.

Define "non-critical issues" is changing dependencies on systemd non-critical? 
No!
non-critical is too broad of a term and should be determined by the maintainer
not somebody that has no or little knowledge... IMHO.

> 
> If cleanups have to go through the maintainer, it's pretty much like saying 
> that they should not happen, ever.
This is not true with in every case. But in the cases this is true, maybe there
should be a time limited? 48hrs?? 

> 
>> Now when something breaks from a change like this... Who are you going to 
>> call? :-)
>> Not the Ghostbusters... the maintainer and if the maintainer didn't even know
>> about the change... how fair that??
> 
> I don't understand the problem.  If the change came with an upstream import, 
> most maintainers would be surprised as well (because they are not upstream or 
> have not reviewed any single upstream change).
Upstream changes are not a problem... Its these random packaging changes that 
are not
document (aka no bz) no reason why... Just done... That is not good... again 
IMHO..

We have this "new" push/pull mechanism that works just great! Why can't these 
non-critical
fixed go through that?

> 
> Again, if there is a Git proces issue here, we can provide guidelines to 
> avoid that with bulk changes (and perhaps a minor Koji enhancement on top).  
> But if you don't say what the technical problems are that you are dealing 
> with, we can't make such improvements.
Its not that... I just me whining about having to do more "cleanup" work.. ;-) 

steved.

> 
> Thanks,
> Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Steve Dickson]

On 12/07/2017 06:13 PM, Sérgio Basto wrote:
> On Thu, 2017-12-07 at 10:31 -0500, Steve Dickson wrote:
>> Hello,
>>
>> What do I have to do to stop random people 
>> from making random changes to packages I maintain? 
>>
>> How do people get this type of permission?
>>
>> Case in point;
>>
>> commit 358a8fff974f0e124527a3281c90fa04cb7c7a7f (HEAD -> master,
>> origin/master, origin/HEAD)
>> Author: Igor Gnatenko 
>> Date:   Tue Nov 7 16:31:21 2017 +0100
>>
>> Remove old crufty coreutils requires
>> 
>> Signed-off-by: Igor Gnatenko 
>>
>> commit 66851ea12370a786844262620a40b0a2ac9632ce
>> Author: Igor Gnatenko 
>> Date:   Tue Nov 7 16:31:14 2017 +0100
>>
>> systemd-units -> systemd
>> 
>> Signed-off-by: Igor Gnatenko 
>>
>> Where committed to the master branch and not to any other
>> branch make the maintenance of those branches a pain 
>> because I can no longer cherry-pick between branches.
>> I have to make multiple commits to multiple branches
>> which sucks... Something random people do not understand!
>>
>> There is a pull mechanism... Why was that not used??
>>
>> Maintaining the stability of packages is hard enough
>> esp packages everybody uses... but that stability
>> goes out the window when random people allowed to
>> make random changes...
>>
>> Who are these super humans, how do they become 
>> super humans and why aren't they required to 
>> use the pull mechanism?? 
> 
> I don't agree with you, you may contact the super human and ask him why
> ? you may revert the commit . 
Overhead that is simply not needed if the maintainer was consulted first.

> 
> IMHO we shouldn't inhibit people do his best, we already have lots of
> work, is kernel updates , glibc updates , gcc updates , systemd , etc
> etc ... (hopefully) 
Ah so you can make a changes to Linus' kernel at anytime you what?? 
Wow I'm impressed 8-) (sarcasm... probably not necessary)

My point is this... People with the best intentions can easily
introduce stability issues by changes packages they don't fully
understand. All changes, other than time critical ones, should
go through the maintainer... I just don't understand why that
is too much to ask?
 
> 
> As wrote in coreuitls commit 
> " Remove very old Provides (mktemp, sh-utils, textwrap, fileutils,
> stat) Those are gone in fc9, more than decade ago."
> 
> Nobody takes care of opencv for example , despite a very long bug
> report, we got bugs like  822844 [1] opened in 2012-05-18  to update
> giflib, my problem here is I don't know if giflib is used anymore or if
> have a replacement etc, so just do a monkey update is not enough for
> me. 
> I got more and more SELinux bugs, people more and more enable SELinux ,
> but SE team doesn't have time to fix it or something like that . 
> 
> So I think you should write (offlist) to the people which made the
> commits , and understand the motivation , and organize with him the
> best way of committing in "your" packages. 
This is the second this happen and the first time I did go offlist. 

So I'm going onlist because I'm seeing a trend... People seems
to think they can make any changes they want w/out going 
through the maintainer. That is a very bad trend... IMHO.

steved.

> 
> Best regards,
> 
> [1]
> https://bugzilla.redhat.com/show_bug.cgi?id=822844
> 
>> steved.
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Florian Weimer]

On 12/08/2017 02:40 PM, Steve Dickson wrote:

Hey,

On 12/07/2017 02:31 PM, Florian Weimer wrote:

On 12/07/2017 04:31 PM, Steve Dickson wrote:

Where committed to the master branch and not to any other
branch make the maintenance of those branches a pain
because I can no longer cherry-pick between branches.


Maybe you can elaborate on how this causes problems for your
development process, and we can find a way to avoid that?



I think the best way to avoid these problems is have any all changes
go through the maintainer...


That doesn't work if the maintainer doesn't react in a timely fashion to 
bug reports, as it is the case for many maintainers unfortunately.  For 
non-critical issues, this is quite understandable, too.


If cleanups have to go through the maintainer, it's pretty much like 
saying that they should not happen, ever.



Now when something breaks from a change like this... Who are you going to call? 
:-)
Not the Ghostbusters... the maintainer and if the maintainer didn't even know
about the change... how fair that??


I don't understand the problem.  If the change came with an upstream 
import, most maintainers would be surprised as well (because they are 
not upstream or have not reviewed any single upstream change).


Again, if there is a Git proces issue here, we can provide guidelines to 
avoid that with bulk changes (and perhaps a minor Koji enhancement on 
top).  But if you don't say what the technical problems are that you are 
dealing with, we can't make such improvements.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Steve Dickson]

On 12/07/2017 05:38 PM, Kevin Kofler wrote:
> Steve Dickson wrote:
>> Where committed to the master branch and not to any other
>> branch make the maintenance of those branches a pain
>> because I can no longer cherry-pick between branches.
>> I have to make multiple commits to multiple branches
>> which sucks... Something random people do not understand!
> 
> Huh? Normally, just committing to the master branch is the right thing to do 
> for such cleanups. The other branches will either get the changes when I 
> fast-forward-merge master into them (remember that you should always work in 
> Rawhide first), or I don't merge and they don't get the changes, which is 
> typically fine too for this kind of cosmetic cleanups.
> 
> Committing the changes to all branches separately is exactly what I DON'T 
> want provenpackagers to do because that would break fast-forward 
> mergeability (and fixing that is painful and will pollute the history with 
> several merge commits: I have to merge master into the branch, and then 
> fast-forward-merge the branch back into master, which pollutes all branches 
> including the master with one merge commit per branch). I always curse at 
> rel-eng when they do a mass rebuild in a branch, bumping the branch directly 
> with their scripts instead of merging from master.
Good for you... you have a process of keeping your branches insync.. 
and it sounds very reasonable... 

Now when a random nobody make a change behind your back that disrupts
that process and you are ok with that??? Well.. I'm not. 

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Steve Dickson]

Hey,

On 12/07/2017 03:49 PM, Adam Williamson wrote:
> On Thu, 2017-12-07 at 10:31 -0500, Steve Dickson wrote:
> 
>> Where committed to the master branch and not to any other
>> branch make the maintenance of those branches a pain 
>> because I can no longer cherry-pick between branches.
>> I have to make multiple commits to multiple branches
>> which sucks... Something random people do not understand!
> 
> You can bring branches back into line with merge commits. Can require a
> bit of git juggling, but it's always doable in the end.
> 
Fair enough... I understand git and how to bring things back
into sync.. But the question is why does a maintainer have
jump through these hoops for change they didn't make.

All I'm trying to do is nip in the bud the notion that
anybody can make any change they want to any package
without going through the maintainer of that package.

I don't know what any of the polices say but we can
not let that happen if we hope to maintain stability.

steved.
 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Steve Dickson]

Hey,

On 12/07/2017 02:31 PM, Florian Weimer wrote:
> On 12/07/2017 04:31 PM, Steve Dickson wrote:
>> Where committed to the master branch and not to any other
>> branch make the maintenance of those branches a pain
>> because I can no longer cherry-pick between branches.
> 
> Maybe you can elaborate on how this causes problems for your 
> development process, and we can find a way to avoid that?
I think the best way to avoid these problems is have any all changes
go through the maintainer... Now I understand build issue where 
the flux capacitor breaks and the issue needs to be fix relatively
quickly... fine... but is was not the case... This was remove/changing
logic in the packaging... which easily gone through the maintainer 
via the push mechanism.

Now when something breaks from a change like this... Who are you going to call? 
:-)
Not the Ghostbusters... the maintainer and if the maintainer didn't even know
about the change... how fair that??

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Steve Dickson]

On 12/07/2017 02:18 PM, Yaakov Selkowitz wrote:
> On 2017-12-07 09:31, Steve Dickson wrote:
>> What do I have to do to stop random people 
>> from making random changes to packages I maintain? 
>>
>> How do people get this type of permission?
> 
> https://fedoraproject.org/wiki/Provenpackager_policy
> 
>> Case in point;
> [snip]
> 
> These were properly announced:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RJYQNLIWBAVQPGLIGUT77WGY5D4TK334/
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YKPCYY2JJOAQG67X4I6ZNYRHNYDCNQFL/
> 
> This is proper use of the provenpackager privileges.
Which will lead to the instability... IMHO... Allowing people to
to change technology that they are clueless of is just wrong.

What is the point of maintainers-ship if any one and everyone can 
make changes? Any and all changes must go through the maintainer
if that is not the case the way even have them?
 
steved.
 
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 08, 2017 at 02:07:51AM +, Michael Cullen wrote:
> > because I can no longer cherry-pick between branches.
> 
> Not true at all - you’d be surprised how well git deals with cherry
> picks across diverse branches. And even when it doesn’t there’s very
> rarely anything in a spec file that would be a difficult conflict to
> resolve. At work I often cherry pick across branches that have diverged
> sometimes by hundreds of commits without too many problems!
> Michael

Yeah, git is usually able to cherry-pick most of the commit between
different fedora branches. There's usually a conflict in the
%changelog section, but it's really trivial, usually a few keystrokes
to solve.

This was mentioned elsewhere in the thread: it's easiest to
fast-forward the other branches to master, if the changes done in
rawhide apply also to released Fedoras. Then there's even no need to
cherry-pick anything.

But even if copying the changes wasn't almost trivial, those changes
would still be OK. After all, that's exactly the way that
release-engineering does mass rebuilds and also how rebuilds for
so-bumps are done. So a maintainer will occasionally get an "external"
commit in rawhide. I really don't see why a cleanup done by a pp
would be any different.

... and, having said all that, I think that even if the cleanups
were not done exactly as the maintainer would want them to be done,
the maintainer should be OK with them: the net benefit of having
the cleanup done is higher then the surprise/need-of-adjustment/annoyance
of the maintainer. If somebody else does a change on our package we're
prone to seeing all the warts, more so then in our own work.

Zbyszek

> On Thu, 7 Dec 2017, at 11:13 PM, Sérgio Basto wrote:
> > On Thu, 2017-12-07 at 10:31 -0500, Steve Dickson wrote:
> > > Hello,
> > >
> > > What do I have to do to stop random people
> > > from making random changes to packages I maintain?
> > >
> > > How do people get this type of permission?
> > >
> > > Case in point;
> > >
> > > commit 358a8fff974f0e124527a3281c90fa04cb7c7a7f (HEAD -> master,
> > > origin/master, origin/HEAD)
> > > Author: Igor Gnatenko 
> > > Date:   Tue Nov 7 16:31:21 2017 +0100
> > >
> > > Remove old crufty coreutils requires
> > >
> > > Signed-off-by: Igor Gnatenko > >
> > > commit 66851ea12370a786844262620a40b0a2ac9632ce
> > > Author: Igor Gnatenko 
> > > Date:   Tue Nov 7 16:31:14 2017 +0100
> > >
> > > systemd-units -> systemd
> > >
> > > Signed-off-by: Igor Gnatenko > >
> > > Where committed to the master branch and not to any other
> > > branch make the maintenance of those branches a pain
> > > because I can no longer cherry-pick between branches.
> > > I have to make multiple commits to multiple branches
> > > which sucks... Something random people do not understand!
> > >
> > > There is a pull mechanism... Why was that not used??
> > >
> > > Maintaining the stability of packages is hard enough
> > > esp packages everybody uses... but that stability
> > > goes out the window when random people allowed to
> > > make random changes...
> > >
> > > Who are these super humans, how do they become
> > > super humans and why aren't they required to
> > > use the pull mechanism??
> >
> > I don't agree with you, you may contact the super human and ask him
> > why> ? you may revert the commit .
> >
> > IMHO we shouldn't inhibit people do his best, we already have lots of> 
> > work, is kernel updates , glibc updates , gcc updates , systemd , etc> etc 
> > ... (hopefully)
> >
> > As wrote in coreuitls commit
> > " Remove very old Provides (mktemp, sh-utils, textwrap, fileutils,
> > stat) Those are gone in fc9, more than decade ago."
> >
> > Nobody takes care of opencv for example , despite a very long bug
> > report, we got bugs like  822844 [1] opened in 2012-05-18  to update
> > giflib, my problem here is I don't know if giflib is used
> > anymore or if> have a replacement etc, so just do a monkey update is not 
> > enough for
> > me.
> > I got more and more SELinux bugs, people more and more enable
> > SELinux ,> but SE team doesn't have time to fix it or something like that .
> >
> > So I think you should write (offlist) to the people which made the
> > commits , and understand the motivation , and organize with him the
> > best way of committing in "your" packages.
> >
> > Best regards,
> >
> > [1]
> > https://bugzilla.redhat.com/show_bug.cgi?id=822844
> >
> > > steved.
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org> --
> > Sérgio M. B.
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 

> 

Re: What to I have to do....

[Michael Cullen]

> because I can no longer cherry-pick between branches.

Not true at all - you’d be surprised how well git deals with cherry
picks across diverse branches. And even when it doesn’t there’s very
rarely anything in a spec file that would be a difficult conflict to
resolve. At work I often cherry pick across branches that have diverged
sometimes by hundreds of commits without too many problems!
Michael


On Thu, 7 Dec 2017, at 11:13 PM, Sérgio Basto wrote:
> On Thu, 2017-12-07 at 10:31 -0500, Steve Dickson wrote:
> > Hello,
> >
> > What do I have to do to stop random people
> > from making random changes to packages I maintain?
> >
> > How do people get this type of permission?
> >
> > Case in point;
> >
> > commit 358a8fff974f0e124527a3281c90fa04cb7c7a7f (HEAD -> master,
> > origin/master, origin/HEAD)
> > Author: Igor Gnatenko 
> > Date:   Tue Nov 7 16:31:21 2017 +0100
> >
> > Remove old crufty coreutils requires
> >
> > Signed-off-by: Igor Gnatenko > >
> > commit 66851ea12370a786844262620a40b0a2ac9632ce
> > Author: Igor Gnatenko 
> > Date:   Tue Nov 7 16:31:14 2017 +0100
> >
> > systemd-units -> systemd
> >
> > Signed-off-by: Igor Gnatenko > >
> > Where committed to the master branch and not to any other
> > branch make the maintenance of those branches a pain
> > because I can no longer cherry-pick between branches.
> > I have to make multiple commits to multiple branches
> > which sucks... Something random people do not understand!
> >
> > There is a pull mechanism... Why was that not used??
> >
> > Maintaining the stability of packages is hard enough
> > esp packages everybody uses... but that stability
> > goes out the window when random people allowed to
> > make random changes...
> >
> > Who are these super humans, how do they become
> > super humans and why aren't they required to
> > use the pull mechanism??
>
> I don't agree with you, you may contact the super human and ask him
> why> ? you may revert the commit .
>
> IMHO we shouldn't inhibit people do his best, we already have lots of> work, 
> is kernel updates , glibc updates , gcc updates , systemd , etc> etc ... 
> (hopefully)
>
> As wrote in coreuitls commit
> " Remove very old Provides (mktemp, sh-utils, textwrap, fileutils,
> stat) Those are gone in fc9, more than decade ago."
>
> Nobody takes care of opencv for example , despite a very long bug
> report, we got bugs like  822844 [1] opened in 2012-05-18  to update
> giflib, my problem here is I don't know if giflib is used
> anymore or if> have a replacement etc, so just do a monkey update is not 
> enough for
> me.
> I got more and more SELinux bugs, people more and more enable
> SELinux ,> but SE team doesn't have time to fix it or something like that .
>
> So I think you should write (offlist) to the people which made the
> commits , and understand the motivation , and organize with him the
> best way of committing in "your" packages.
>
> Best regards,
>
> [1]
> https://bugzilla.redhat.com/show_bug.cgi?id=822844
>
> > steved.
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org> --
> Sérgio M. B.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Sérgio Basto]

On Thu, 2017-12-07 at 10:31 -0500, Steve Dickson wrote:
> Hello,
> 
> What do I have to do to stop random people 
> from making random changes to packages I maintain? 
> 
> How do people get this type of permission?
> 
> Case in point;
> 
> commit 358a8fff974f0e124527a3281c90fa04cb7c7a7f (HEAD -> master,
> origin/master, origin/HEAD)
> Author: Igor Gnatenko 
> Date:   Tue Nov 7 16:31:21 2017 +0100
> 
> Remove old crufty coreutils requires
> 
> Signed-off-by: Igor Gnatenko 
> 
> commit 66851ea12370a786844262620a40b0a2ac9632ce
> Author: Igor Gnatenko 
> Date:   Tue Nov 7 16:31:14 2017 +0100
> 
> systemd-units -> systemd
> 
> Signed-off-by: Igor Gnatenko 
> 
> Where committed to the master branch and not to any other
> branch make the maintenance of those branches a pain 
> because I can no longer cherry-pick between branches.
> I have to make multiple commits to multiple branches
> which sucks... Something random people do not understand!
> 
> There is a pull mechanism... Why was that not used??
> 
> Maintaining the stability of packages is hard enough
> esp packages everybody uses... but that stability
> goes out the window when random people allowed to
> make random changes...
> 
> Who are these super humans, how do they become 
> super humans and why aren't they required to 
> use the pull mechanism?? 

I don't agree with you, you may contact the super human and ask him why
? you may revert the commit . 

IMHO we shouldn't inhibit people do his best, we already have lots of
work, is kernel updates , glibc updates , gcc updates , systemd , etc
etc ... (hopefully) 

As wrote in coreuitls commit 
" Remove very old Provides (mktemp, sh-utils, textwrap, fileutils,
stat) Those are gone in fc9, more than decade ago."

Nobody takes care of opencv for example , despite a very long bug
report, we got bugs like  822844 [1] opened in 2012-05-18  to update
giflib, my problem here is I don't know if giflib is used anymore or if
have a replacement etc, so just do a monkey update is not enough for
me. 
I got more and more SELinux bugs, people more and more enable SELinux ,
but SE team doesn't have time to fix it or something like that . 

So I think you should write (offlist) to the people which made the
commits , and understand the motivation , and organize with him the
best way of committing in "your" packages. 

Best regards,

[1]
https://bugzilla.redhat.com/show_bug.cgi?id=822844

> steved.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Kevin Kofler]

Steve Dickson wrote:
> Where committed to the master branch and not to any other
> branch make the maintenance of those branches a pain
> because I can no longer cherry-pick between branches.
> I have to make multiple commits to multiple branches
> which sucks... Something random people do not understand!

Huh? Normally, just committing to the master branch is the right thing to do 
for such cleanups. The other branches will either get the changes when I 
fast-forward-merge master into them (remember that you should always work in 
Rawhide first), or I don't merge and they don't get the changes, which is 
typically fine too for this kind of cosmetic cleanups.

Committing the changes to all branches separately is exactly what I DON'T 
want provenpackagers to do because that would break fast-forward 
mergeability (and fixing that is painful and will pollute the history with 
several merge commits: I have to merge master into the branch, and then 
fast-forward-merge the branch back into master, which pollutes all branches 
including the master with one merge commit per branch). I always curse at 
rel-eng when they do a mass rebuild in a branch, bumping the branch directly 
with their scripts instead of merging from master.

I don't understand what kind of workflow you use that makes you want cleanup 
commits to be done on each and every branch.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Adam Williamson]

On Thu, 2017-12-07 at 10:31 -0500, Steve Dickson wrote:

> Where committed to the master branch and not to any other
> branch make the maintenance of those branches a pain 
> because I can no longer cherry-pick between branches.
> I have to make multiple commits to multiple branches
> which sucks... Something random people do not understand!

You can bring branches back into line with merge commits. Can require a
bit of git juggling, but it's always doable in the end.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[R P Herrold]

On Thu, 7 Dec 2017, Yaakov Selkowitz wrote:

> https://fedoraproject.org/wiki/Provenpackager_policy

> These were properly announced:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RJYQNLIWBAVQPGLIGUT77WGY5D4TK334/
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YKPCYY2JJOAQG67X4I6ZNYRHNYDCNQFL/

That section provides in relevant part:

> Provenpackagers should try to communicate with owners of a 
package in bugzilla, irc or email prior to making changes

IMHO, A general email to a high traffic mailing list is 
insufficient

IRC is even worse for notification

Absent some pressing need (which was NOT present here -- this 
was just 'distribution housecleaning'), this was insufficient 
notice on a non-urgent matter, to my thinking

I have filed a FESCO bug on the topic, with proposed revised 
language:

https://pagure.io/fesco/issue/1799

-- Russ herrold
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Florian Weimer]

On 12/07/2017 04:31 PM, Steve Dickson wrote:

Where committed to the master branch and not to any other
branch make the maintenance of those branches a pain
because I can no longer cherry-pick between branches.


Maybe you can elaborate on how this causes problems for your development 
process, and we can find a way to avoid that?


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Yaakov Selkowitz]

On 2017-12-07 09:31, Steve Dickson wrote:
> What do I have to do to stop random people 
> from making random changes to packages I maintain? 
> 
> How do people get this type of permission?

https://fedoraproject.org/wiki/Provenpackager_policy

> Case in point;
[snip]

These were properly announced:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RJYQNLIWBAVQPGLIGUT77WGY5D4TK334/
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YKPCYY2JJOAQG67X4I6ZNYRHNYDCNQFL/

This is proper use of the provenpackager privileges.

-- 
Yaakov Selkowitz
Software Engineer - Platform Enablement Group
Red Hat, Inc.



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org