On Friday 08 July 2005 11:46 pm, Nathan L. Adams wrote:
> Mike Frysinger wrote:
> >>>This brings up a point that really irks me. In the bug, I believe the
> >>> dev implies that the reported bug has merit /yet he closes the bug
> >>> before actually doing something about it/. And I don't mean to pi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jory A. Pratt wrote:
> Nathan you have this misconception that just cause a bug apears on
> one system it is gonna apear on multiple systems.
What are you talking about? This whole discussion was framed with the
situation where the *developer* det
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nathan L. Adams wrote:
> Jon Portnoy wrote:
>
>> I didn't say that.
>
>> I'm saying that (a) team leads do not want to waste their time in
>>
> such a
>> way just to give you warm fuzzies (b) devs do not particularly
>> want their team lead reviewing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jon Portnoy wrote:
> I didn't say that.
>
> I'm saying that (a) team leads do not want to waste their time in such a
> way just to give you warm fuzzies (b) devs do not particularly want
> their team lead reviewing every single action they take, it
On Sat, Jul 09, 2005 at 12:00:50PM -0400, Nathan L. Adams wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jon Portnoy wrote:
> > On Sat, Jul 09, 2005 at 10:54:46AM -0400, Nathan L. Adams wrote:
> >
> > So when can we discuss the salaries you're going to pay the team leads
> > to was
Nathan L. Adams wrote:
Gregorio Guidi wrote:
Any proposal that implies an enourmous increase of our human resources is
really useless for us.
Please accept the fact that we cannot change our resources at will, and adapt
any suggestion to this simple principle.
Now *that* is a reasonable argum
Nathan L. Adams wrote:
> Also, in the case were the 'fix' doesn't actually fix the bug, you waste
> alot more development time by letting it slip through and having to
> 'fix' it again later. So you can justify the time cost now, with time
> saved later.
Just think of it as branch prediction.
If t
On Sat, 09 Jul 2005 15:56:32 -0400 "Nathan L. Adams" <[EMAIL PROTECTED]>
wrote:
| I don't think any of the devs would suggest that *any* fix should be
| accepted without first testing it (under the current process). If you
| don't believe me, submit it an ebuild and keyword it as stable on a
| plat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marco Matthies wrote:
> Nathan L. Adams wrote:
>
>>Jory, I take issue with that. I am not ranting. I am proposing a way to
>>*improve* QA.
>
>
> Some thoughts from a humble user:
>
> Any improvement must neither excessively waste developer nor user
Nathan L. Adams wrote:
> Jory, I take issue with that. I am not ranting. I am proposing a way to
> *improve* QA.
Some thoughts from a humble user:
Any improvement must neither excessively waste developer nor user time,
it is the most scarce resource. To optimize this, the common case must
be made
I'll even top post this one :P Take it back to the thread flameeyes
started about this originally pretty please, with sugar on top.
On Jul 9, 2005, at 9:10 AM, Martin Schlemmer wrote:
On Sat, 2005-07-09 at 15:11 +0200, Diego 'Flameeyes' Pettenò wrote:
On Saturday 09 July 2005 15:05, Martin
Richard Fish wrote:
I.o.w. is it still necessary to have RC_DEVICE_TARBALL="yes" as a
default or can we move to a pure udev system and change the default to
"no".
>>>I've been running my boxes successfully with "no" since the option
>>>showed up just fine :)
>>
>>I think people i
>>>I.o.w. is it still necessary to have RC_DEVICE_TARBALL="yes" as a
>>>default or can we move to a pure udev system and change the default to
>>>"no".
>>>
>>>
>>I've been running my boxes successfully with "no" since the option
>>showed up just fine :)
>>
>>
>>
>
>I think people is unde
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephen P. Becker wrote:
> Clearly, you either chose to blatantly ignore, or completely
> misunderstood what avenj was saying. What he *meant* was we don't have
> the time or manpower to have developers take significant portions of
> their valuable ti
Nathan L. Adams wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jon Portnoy wrote:
>
>>On Sat, Jul 09, 2005 at 10:54:46AM -0400, Nathan L. Adams wrote:
>>
>>So when can we discuss the salaries you're going to pay the team leads
>>to waste fairly significant quantities of time starin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> On Sat, 09 Jul 2005 11:11:17 -0400 "Nathan L. Adams" <[EMAIL PROTECTED]>
> wrote:
> | I do software development, systems integration, and bug squashing for
> | a living.
>
> Gentoo's 'moving target' development model is not th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> On Sat, 09 Jul 2005 11:11:17 -0400 "Nathan L. Adams" <[EMAIL PROTECTED]>
> wrote:
> | I do software development, systems integration, and bug squashing for
> | a living.
>
> Gentoo's 'moving target' development model is not th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gregorio Guidi wrote:
>
> Any proposal that implies an enourmous increase of our human resources is
> really useless for us.
> Please accept the fact that we cannot change our resources at will, and adapt
> any suggestion to this simple principle.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jon Portnoy wrote:
> On Sat, Jul 09, 2005 at 10:54:46AM -0400, Nathan L. Adams wrote:
>
> So when can we discuss the salaries you're going to pay the team leads
> to waste fairly significant quantities of time staring over everybody's
> shoulder? 8)
On Saturday 09 July 2005 16:54, Nathan L. Adams wrote:
> Martin Schlemmer wrote:
> > Problem is many of us have sometimes already too many bugs to care about
> > users reporting something, and then never coming back, not even talking
> > about keeping to poke the reporter to come back and say the f
On Sat, 09 Jul 2005 11:11:17 -0400 "Nathan L. Adams" <[EMAIL PROTECTED]>
wrote:
| I do software development, systems integration, and bug squashing for
| a living.
Gentoo's 'moving target' development model is not the development model
used by your typical 'stable release once or twice per year' l
On Sat, Jul 09, 2005 at 10:54:46AM -0400, Nathan L. Adams wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Martin Schlemmer wrote:
> > Problem is many of us have sometimes already too many bugs to care about
> > users reporting something, and then never coming back, not even talking
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jory A. Pratt wrote:
> I have sat here and read you all rant on and on about these
> issues,
Jory, I take issue with that. I am not ranting. I am proposing a way to
*improve* QA.
> but you still are not taking into account that when a bug is
> ma
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Schlemmer wrote:
> Problem is many of us have sometimes already too many bugs to care about
> users reporting something, and then never coming back, not even talking
> about keeping to poke the reporter to come back and say the fix works
> fine,
On Sat, 2005-07-09 at 15:11 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Saturday 09 July 2005 15:05, Martin Schlemmer wrote:
> > Ditto - point being, is that if you want the agony of per-ebuild hacks,
> > be my guest, but do not expect the rest to hold your hand.
> It's not a matter of per-ebuild
On Saturday 09 July 2005 15:05, Martin Schlemmer wrote:
> Ditto - point being, is that if you want the agony of per-ebuild hacks,
> be my guest, but do not expect the rest to hold your hand.
It's not a matter of per-ebuild hack.
Let me explain for example:
for a bit of time we had make -> gmake al
On Sat, 2005-07-09 at 14:46 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Saturday 09 July 2005 14:41, Martin Schlemmer wrote:
> > Sure thing - YOU then go through the tree and change all instances of
> > 'make' ...
> Seems like the point is not taken.. I'm not saying to replace all of them
> *now*
On Saturday 09 July 2005 14:41, Martin Schlemmer wrote:
> Sure thing - YOU then go through the tree and change all instances of
> 'make' ...
Seems like the point is not taken.. I'm not saying to replace all of them
*now* but just when we'll keyword stuff.
--
Diego "Flameeyes" Pettenò
Gentoo Deve
On Sat, 2005-07-09 at 14:08 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Saturday 09 July 2005 14:01, Martin Schlemmer wrote:
> > And this is exactly what one of the issue for me is. Now devs on the
> > linux sides, need to learn bsd make peculiarities as well (to start
> > with, but it will expan
On Sat, 9 Jul 2005 14:08:24 +0200
"Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote:
> On Saturday 09 July 2005 14:01, Martin Schlemmer wrote:
> > And this is exactly what one of the issue for me is. Now devs on
> > the linux sides, need to learn bsd make peculiarities as well (to
> > start w
On Saturday 09 July 2005 14:01, Martin Schlemmer wrote:
> And this is exactly what one of the issue for me is. Now devs on the
> linux sides, need to learn bsd make peculiarities as well (to start
> with, but it will expand if this gets in as 'policy' or whatever), and
> hope to guess right when t
On Sat, 2005-07-09 at 13:45 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Saturday 09 July 2005 12:20, Martin Schlemmer wrote:
> > I still this this is a bsd issue, so some or other solution which do not
> > include having gmake (and then later lots of other symlinks/whatever)
> > should be installe
On Saturday 09 July 2005 12:20, Martin Schlemmer wrote:
> I still this this is a bsd issue, so some or other solution which do not
> include having gmake (and then later lots of other symlinks/whatever)
> should be installed system wide for only a very small portion of our
> user segment on all sys
On Sat, 2005-07-09 at 11:47 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Saturday 09 July 2005 11:28, Jason Stubbs wrote:
> > However, if an ebuild chooses to run make directly for some unknown reason
> > or use some specific tool to unpack an unsupported file format, the package
> > should really
On Sat, 2005-07-09 at 18:28 +0900, Jason Stubbs wrote:
> On Tuesday 05 July 2005 19:48, Martin Schlemmer wrote:
> > This is all well and dandy, but try to add coreutils as a dependency of
> > itself, or gcc of itself, or sed ... or grep ... etc, and then try to do
> > a stage1 install (probably sta
On Fri, 2005-07-08 at 23:46 -0400, Nathan L. Adams wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Mike Frysinger wrote:
> >>>This brings up a point that really irks me. In the bug, I believe the dev
> >>>implies that the reported bug has merit /yet he closes the bug before
> >>>actua
On Saturday 09 July 2005 11:28, Jason Stubbs wrote:
> However, if an ebuild chooses to run make directly for some unknown reason
> or use some specific tool to unpack an unsupported file format, the package
> should really be explicit about its dependency.
And this let me think: we'll be able soone
On Saturday 09 July 2005 11:28, Jason Stubbs wrote:
> I didn't read this in the thread. How does this work?
ncurses needs to run a given binary (that I don't remember now, sorry), during
the compilation stage. The build system try to build it bug if $CC !=
$BUILD_CC (literally) it considers it cr
On Tuesday 05 July 2005 19:48, Martin Schlemmer wrote:
> This is all well and dandy, but try to add coreutils as a dependency of
> itself, or gcc of itself, or sed ... or grep ... etc, and then try to do
> a stage1 install (probably stage2/3 as well, but I never do those, so
> rather wont comment).
On Monday 04 July 2005 09:18, Brian D. Harring wrote:
> On Fri, Jul 01, 2005 at 08:16:46PM -0500, Kito wrote:
> > Accurate deps should be a goal for the tree, a long term one
> > obviously...
>
> Picking at the words (not you), but "long term" == it gets ignored
> till someone starts screaming/foam
On Thursday 07 July 2005 02:08, Brian D. Harring wrote:
> Basically, I was attempting to get feedback on issues where this
> wouldn't be quiet enough, an example of which is ncurses.
> (my understanding of this, thanks to flameeyes for clueing me in)
> ncurses built/installed in chost==ctarget, BDE
On Saturday 02 July 2005 02:49, Mike Frysinger wrote:
> On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote:
> > Currently, we pretty much leave out the big dogs of build depends from
> > ebuilds- basically we rely on the profile to require a suitable
> > toolchain. Couple of issues with this
On Tuesday 05 July 2005 18:39, Martin Schlemmer wrote:
> On another note .. how do you guys plan to handle this BDEPEND .. just
> for x-compile, or global? If global, any ideas how to solve the
> circular issues ???
Global. There's no real difference between building a package for the local
mach
43 matches
Mail list logo
