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

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

 




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 <ignatenkobrain@xxxxxxxxxxxxxxxxx>
>> Date:   Tue Nov 7 16:31:21 2017 +0100
>>
>>     Remove old crufty coreutils requires
>>     
>>     Signed-off-by: Igor Gnatenko <ignatenkobrain@xxxxxxxxxxxxxxxxx>
>>
>> commit 66851ea12370a786844262620a40b0a2ac9632ce
>> Author: Igor Gnatenko <ignatenkobrain@xxxxxxxxxxxxxxxxx>
>> Date:   Tue Nov 7 16:31:14 2017 +0100
>>
>>     systemd-units -> systemd
>>     
>>     Signed-off-by: Igor Gnatenko <ignatenkobrain@xxxxxxxxxxxxxxxxx>
>>
>> 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@xxxxxxxxxxxxxxxxxxxxxxx
>> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




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