On Fri, Dec 08, 2017 at 02:07:51AM +0000, 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 <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 . > > > > 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@xxxxxxxxxxxxxxxxxxxxxxx > > > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx> -- > > Sérgio M. B. > > _______________________________________________ > > 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
