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,
On Mon, 22 Apr 2013 22:46:14 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> Alexis Ballier posted on Mon, 22 Apr 2013 15:40:33 +0200 as excerpted:
>
> > "Having functional changes mixed with whitespace/cosmetics in a
> > single commit makes it hard to read and understand."
> >
> >> Also, in
On Tue, 23 Apr 2013 21:31:10 +0200
Michał Górny 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 re
On Tue, Apr 23, 2013 at 3:25 PM, Ian Stakenvicius wrote:
> Alternatively, we could enforce repoman checks on any commit or push
> operation in master, and leave branches to their own devices. Of
> course, I haven't seen (or looked for, tbh) how tree development will
> be implemented/suggested to
On Mon, 22 Apr 2013 22:46:14 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> Alexis Ballier posted on Mon, 22 Apr 2013 15:40:33 +0200 as excerpted:
>
> > "Having functional changes mixed with whitespace/cosmetics in a single
> > commit makes it hard to read and understand."
> >
> >> Also, in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 23/04/13 03:11 PM, Rich Freeman wrote:
> On Tue, Apr 23, 2013 at 2:37 PM, Matt Turner
> wrote:
>> On Tue, Apr 23, 2013 at 11:20 AM, Rich Freeman
>> wrote:
>>> On Tue, Apr 23, 2013 at 2:00 PM, Jeroen Roovers
>>> wrote:
Er, you can't be seri
On Tue, Apr 23, 2013 at 12:11 PM, Rich Freeman wrote:
> Any repoman checks done at the time of each commit are essentially
> worthless. Consider this example:
Unless you're bisecting a change that was in those 6 months of
commits. You could introduce a problem in one commit and fix it in the
nex
On Tue, Apr 23, 2013 at 2:37 PM, Matt Turner wrote:
> On Tue, Apr 23, 2013 at 11:20 AM, Rich Freeman wrote:
>> On Tue, Apr 23, 2013 at 2:00 PM, 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 be
On Tue, Apr 23, 2013 at 11:00 AM, Jeroen Roovers wrote:
> On Mon, 22 Apr 2013 22:46:14 + (UTC)
> Duncan <1i5t5.dun...@cox.net> wrote:
>
>> Alexis Ballier posted on Mon, 22 Apr 2013 15:40:33 +0200 as excerpted:
>> > I don't see how git helps. You'll have to commit twice then push, vs
>> > commi
On Tue, Apr 23, 2013 at 11:20 AM, Rich Freeman wrote:
> On Tue, Apr 23, 2013 at 2:00 PM, 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.
>>
>
> Interesting point. One thing to keep
On Tue, Apr 23, 2013 at 2:00 PM, 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.
>
Interesting point. One thing to keep in mind with git is that commits
don't affect the "central rep
On Tue, Apr 23, 2013 at 01:19:05PM +0200, Tobias Klausmann wrote
> The second problem, however, is trickier. We can rely on people
> noticing the error messages/broken packages and hope they file
> bugs. The other option is to have a QA-like check for it, again
> using the simplest possible binary
On Mon, 22 Apr 2013 22:46:14 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> Alexis Ballier posted on Mon, 22 Apr 2013 15:40:33 +0200 as excerpted:
> > I don't see how git helps. You'll have to commit twice then push, vs
> > commit twice with cvs.
>
> But git commits are quite lightweight, whi
On 23 April 2013 11:58, Ryan Hill wrote:
> On Mon, 22 Apr 2013 19:56:49 +0800
> Ben de Groot wrote:
>
> > > I suppose you talked with Michal about this and couldn't reach an
> > > agreement, like him joining the fonts herd, or at least the mail alias
> > > to monitor ft/fc bugs.
> > >
> > > If y
On 23 April 2013 01:13, Michał Górny wrote:
> On Mon, 22 Apr 2013 19:43:22 +0800
> Ben de Groot wrote:
>
> > On 21 April 2013 22:38, Chí-Thanh Christopher Nguyễn <
> chith...@gentoo.org>wrote:
> >
> > > Denis Dupeyron schrieb:
> > > > I'm hoping this kind of immature and abrasive behaviours will
On 23/04/13 14:19, Tobias Klausmann wrote:
bugs. The other option is to have a QA-like check for it, again
using the simplest possible binary to do so.
Now that you said it... "QA"
Have your script (the one you generated the current list with) to
generate it to http://qa-reports.gentoo.org/
Hi!
On Tue, 23 Apr 2013, Ulrich Mueller wrote:
> > I appericiate the work done by Tobias utmost too but I have to agree
> > this is not something I want to see running automatically, or even
> > from within ebuilds.
>
> +1
>
> In Tobias's list, I count some 80 packages that need fixing. That's
> On Tue, 23 Apr 2013, Samuli Suominen wrote:
> I appericiate the work done by Tobias utmost too but I have to agree
> this is not something I want to see running automatically, or even
> from within ebuilds.
+1
In Tobias's list, I count some 80 packages that need fixing. That's
way too few
On 23/04/13 13:24, viv...@gmail.com wrote:
On 04/22/13 13:03, Tobias Klausmann wrote:
Hi!
Since we probably will have to fix the files coming out of
tarballs until the various upstreams have fixed them, I propose
running a PNG fixer during or after the install phase. Since
having pngcrush as de
On 04/22/13 13:03, Tobias Klausmann wrote:
> Hi!
>
> Since we probably will have to fix the files coming out of
> tarballs until the various upstreams have fixed them, I propose
> running a PNG fixer during or after the install phase. Since
> having pngcrush as dep for everything is not exactly li
20 matches
Mail list logo
