Tach Matti, 0x2B859DE3 (PGP-PK-ID)
Matti Bickel schrieb:
Once there was the idea of putting AT testing system specs somewhere, so
arch devs could actually see what we're running. Is this still needed or
is the number of ATs small enough to keep that in
Tach Jeroen, 0x2B859DE3 (PGP-PK-ID)
Jeroen Roovers schrieb:
I propose the `emerge --info` included in arch testers' comments on
stabilisation bugs should rather be posted as attachments. The AT
comments clog up the bugs and are usually not interesting at all to
Tach Jeroen, 0x2B859DE3 (PGP-PK-ID)
Jeroen Roovers schrieb:
Inlining emerge info in comments bloats the e-mail message to roughly
2.5 times the normal size. I could have spoken out to get AT comments
banned altogether or to urge arches with AT teams to find a
On Fri, 11 Aug 2006 04:56:18 + (UTC)
Duncan [EMAIL PROTECTED] wrote:
Even back before it became the in thing, I was posting emerge
--info as attachments, because it simply fit the bill -- bugzy /says/
to put long stuff as attachments. I never did quite understand why
all that admittedly
On Fri, 11 Aug 2006 00:51:56 +0200
Jeroen Roovers [EMAIL PROTECTED] wrote:
On Thu, 10 Aug 2006 23:58:46 +0200
Kevin F. Quinn [EMAIL PROTECTED] wrote:
The problem with attachments is that processing the report takes
longer
- you have to go to the web to read the attachment to find out
On Fri, 11 Aug 2006 12:52:30 +0200
Kevin F. Quinn [EMAIL PROTECTED] wrote:
In general it depends what you're doing. Personally I find inline
emerge --info quicker to process, as I tend to do that by scrolling up
and down a bug when trying to determine what triggers a bug. However
that's for
Tach Jeroen, 0x2B859DE3 (PGP-PK-ID)
Jeroen Roovers schrieb:
One solution might be to open your own AT bug, make the stabilisation
bug depend on it, and use the AT bug to have ATs post their `emerge
info`. Then, when testing and stabilisation is finished for
On Fri, 11 Aug 2006 13:40:23 +0200
Jeroen Roovers [EMAIL PROTECTED] wrote:
On Fri, 11 Aug 2006 12:52:30 +0200
Kevin F. Quinn [EMAIL PROTECTED] wrote:
In general it depends what you're doing. Personally I find inline
emerge --info quicker to process, as I tend to do that by scrolling
up
On 11 Aug 2006 00:00:00 +
[EMAIL PROTECTED] (Christian 'Opfer' Faulhammer) wrote:
Tach Jeroen, 0x2B859DE3 (PGP-PK-ID)
Jeroen Roovers schrieb:
One solution might be to open your own AT bug, make the stabilisation
bug depend on it, and use the AT bug to
Jeroen Roovers [EMAIL PROTECTED] wrote:
ATs can inform you whether something works in the comment to an
attachment, which, unlike the attachment, will end up in my mailbox.
Ok, so i sample my emerge --info myconfig.txt and attach that. This is ok
with me. However, i propose that this
On Fri, 11 Aug 2006 15:25:11 +0200
Kevin F. Quinn [EMAIL PROTECTED] wrote:
In order to decide to change how things are currently done, you need
to show that it is better for a majority of the people affected.
(N minus 1 of N arches) times (the number of arch devs minus the number
of $ARCH
On Fri, 2006-08-11 at 16:46 +0200, Jeroen Roovers wrote:
N -1 arch dev's comfort against N arch devs' annoyance[1].
big snip
[1] Note that I am aware that not all other-arch devs might experience
inline `emerge info` for other arches as annoying.
I am on the alpha, amd64, and x86 arch teams.
On Fri, 11 Aug 2006 11:27:29 -0400
Chris Gianelloni [EMAIL PROTECTED] wrote:
I am on the alpha, amd64, and x86 arch teams. I have found that even
emails from architectures I'm not currently looking at tend to have a
great significance. It seems to me that most of the failures are
USE-flag
On Fri, 2006-08-11 at 18:00 +0200, Jeroen Roovers wrote:
And do you propose ATs still attach `emerge info` in this solution?
No. It really should be inline. I'm sorry if you think that 5K seems
like a lot of spam but having to open a browser just to look at
emerge --info is a complete waste of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
ex.
gcc 4.1.1 works on x86 with the following:
USE=gtk nls -bootstrap -build -doc -fortran -gcj -hardened -ip28
-ip32r10k -mudflap -multislot -nocxx -objc -objc++ -objc-gc -test
-vanilla
Looks OK to me. But hey, aren't arch devs and testers
See http://bugs.gentoo.org/show_bug.cgi?id=141806
Provides caching and release tag support for SVN.
--
gentoo-dev@gentoo.org mailing list
Mark Stier wrote:
See http://bugs.gentoo.org/show_bug.cgi?id=141806
Provides caching and release tag support for SVN.
sorry - I do not see the need for a new eclass here. Can you please instead
modify the subversion eclass and add support for what you want to do?
Best regards,
Stefan
--
sorry - I do not see the need for a new eclass here. Can you please instead
modify the subversion eclass and add support for what you want to do?
I could if I'd see any reason for that.
Best regards,
Mark
--
gentoo-dev@gentoo.org mailing list
Mark Stier wrote:
sorry - I do not see the need for a new eclass here. Can you please
instead
modify the subversion eclass and add support for what you want to do?
I could if I'd see any reason for that.
Going the opposite way, you duplicate much of svn.eclass for one piece
of
Kevin F. Quinn [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on Fri,
11 Aug 2006 12:36:35 +0200:
On Fri, 11 Aug 2006 04:56:18 + (UTC)
Duncan [EMAIL PROTECTED] wrote:
[re. posting AT configs somewhere]
I like the idea above, tho. For ATs especially, having some place
On Tue, 8 Aug 2006 23:04:19 +0200 Enrico Weigelt [EMAIL PROTECTED]
wrote:
| I'm interested in arguments whether patches should sit directly
| within the portage tree or downloaded when needed.
|
| My feeling: downloading on demand is better.
|
| + makes the tree smaller, saves space, saves
Chris Gianelloni wrote:
No. It really should be inline. I'm sorry if you think that 5K seems
like a lot of spam but having to open a browser just to look at
emerge --info is a complete waste of time.
*ding*
it's also nice to have that information actually _in_ my mailbox and not
of at the
22 matches
Mail list logo
