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

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

 



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




[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