Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask
Jeroen Roovers wrote: Er, you can't be seriously suggesting we will drop repoman checks with the migration to git? I don't see how that would benefit anyone. I would argue that repoman and/or corresponding checks should be run by a CI system hooked up to the Gerrit instance that developers push to. Anything else is IMO waste of developers' time and minds. //Peter
Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask
On Wed, Apr 24, 2013 at 7:47 AM, Michael Mol mike...@gmail.com wrote: 13. Gerrit's push to tree fails, since tree with changeset A isn't in changeset B's ancestry. Honestly, this is a problem with any use of repoman with git unless you let the server auto-merge trivial changes. Cvs tracks commits at the file level, and git does it at the repository level. The chances of somebody modifying the same files in the time it takes you to stage, test, and commit a change in cvs are fairly low. The chances of somebody making any commit to the repository in the time it takes you to rebase, do a repoman check, and push are much higher. We might have to live with repoman being a manual process - then you'd just pull/rebase-or-merge/push to get it to the tree and use your brain to determine if it causes any problems (which does require responsibility). However, your specific example could be modified a bit to make it more robust: 1. Dev A pulls from tree 2. Dev A merges those changes with his local copy of tree 3. Dev A pushes to Gerrit 4. Gerrit begins tests on changeset A 5. Dev B pulls from tree (or perhaps he pulled earlier) 6. Gerrit is still testing changeset A 7. Dev B merges those changes with his local copy of tree 8. Gerrit finishes testing, pushes to tree 9. Dev B's push to Gerrit fails, since Gerrit's head isn't in B's ancestry. 10. Dev B pulls, rebases, and re-pushes - possibly pulling directly from Gerrit to reduce latency. It still fails when you get high volumes, because the fundamental issue is that it can only handle as many commits as Gerrit can test in a given period of time, plus various latencies. Rich
Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask
On Tue, Apr 23, 2013 at 11:20 AM, Rich Freeman ri...@gentoo.org wrote: On Tue, Apr 23, 2013 at 2:00 PM, Jeroen Roovers j...@gentoo.org wrote: Er, you can't be seriously suggesting we will drop repoman checks with the migration to git? I don't see how that would benefit anyone. Interesting point. One thing to keep in mind with git is that commits don't affect the central repository. Pushes are what impacts the repository. If I spend six months working on a bunch of coordinated package changes, nobody will see a thing until I push those commits and 500 ebuilds all change atomically (not that I'm suggesting that lack of communication is to be encouraged). A repoman check on a commit may not reflect its impact six months later when it actually hits the main tree. ... if you're squashing 6 months of work into a single commit before pushing. I don't think we want to do that, do we? Maybe bisecting isn't particularly interesting for the portage tree.
Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask
On Tue, 23 Apr 2013 21:31:10 +0200 Michał Górny mgo...@gentoo.org wrote: Just to make it clear -- there are four CVS commits. Ebuild commit followed by GPG-signed Manifest commit. Hopefully the developer has persistent SSH connections set up. AFAIK setting these up still isn't properly documented. I once read about it in a post somewhere by robbat2 and have been using this ever since, and I also recall suggesting using persistent SSH connections without finding a trace of evidence of their use in developer documentation. jer
Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask
On 04/23/2013 01:27 PM, Tom Wijsman wrote: Maybe the question is rather why `repoman` takes 15 seconds on a quite fast system in a package folder that contains 2 ebuilds and 1 metadata. See the call graph for repoman at http://i.imgur.com/OQTUBdR.png. A third of the time, ~5 seconds, are spent on 60,000 - 70,000 calls to the function that is listed in the bottom; but the ebuilds barely list any dependencies. Why are there so much calls to this? There's lots of redundant repetition involved in repoman's iteration over the profiles listed in profiles.desc. It may be possible to optimize away the redundancy by taking advantage of all the things that each of the profiles have in common. -- Thanks, Zac
