[gentoo-dev] bugstest.gentoo.org - public beta for the new Gentoo BugZilla - please test!

2006-11-16 Thread Robin H. Johnson
Hi everybody,

Over in infra, some of us have been working hard (see also the recent
anonymous CVS and SVN services), and we're now ready for public testing
on another milestone...

The shiny new bugstest.gentoo.org! We're opening it up for all testers
as of this email. It is current up the 14th of November, so I would also
like to encourage everybody searching for existing bugs to use it. It
should scale much better than the existing BugZilla setup.

This testing period will last for 2-4 weeks, depending on how stable the
setup of bugstest turns out to be. Then we can hopefully roll out the
new Bugzilla for production use in time for Christmas!

Usage:
1. Point your browser at http://bugstest.gentoo.org
2. Continue as normal
3. When you find a problem, file a bug in the real bugzilla
http://bugs.gentoo.org/, directed to infra, with 'bugstest' in the
summary!

Notable elements:
- Newer version of Bugzilla from upstream.
- Much more database horse-power.
- Automatic failover between database machines.
- A much better backup system - that shouldn't cause a major hiccup at
  night - 5 seconds of non-availability, and then 5-8 minutes of a
  slightly delay on one of the database machines.

Misc Notes:
- email is disabled, so nobody gets spammed by any attempted mass changes.
- I suspect there might be one or two UTF8 problems lurking. Look on the
  main bugzilla for entries that use UTF8 in the summary and the
  comments, and compare them to the entries in bugstest.

Thanks to kingtaco, myself, ramereth, solar, jforman and cshields for
all playing a part of getting this together so far!

-- 
Robin Hugh Johnson
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpe9hflqEjWj.pgp
Description: PGP signature


[gentoo-dev] Re: [gentoo-core] bugstest.gentoo.org - public beta for the new Gentoo BugZilla - please test!

2006-11-16 Thread Alon Bar-Lev

On 11/16/06, Robin H. Johnson [EMAIL PROTECTED] wrote:

The shiny new bugstest.gentoo.org! We're opening it up for all testers
as of this email. It is current up the 14th of November, so I would also
like to encourage everybody searching for existing bugs to use it. It
should scale much better than the existing BugZilla setup.


Just a stupid question...
Can bugzilla be configured so that when you open a new bug you are
able to modify the reporter?
This is useful when s developer wishes to open a new bug on behalf to
a user who reported multiple issues, and allow him to manage it as if
it was his.

Best Regards,
Alon Bar-Lev.
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] bugstest.gentoo.org - public beta for the new Gentoo BugZilla - please test!

2006-11-16 Thread Mike Doty

Robin H. Johnson wrote:
[snip]

Thanks to kingtaco, myself, ramereth, solar, jforman and cshields for
all playing a part of getting this together so far!

don't forget to thank GNi(http://www.gni.com) who provided the hardware 
and colo for the new setup.

--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] last rites for net-proxy/dansguardian-dgav

2006-11-16 Thread Alin Nastac

I've masked dgav and I will remove it from the tree in about a month.

The new version of dansguardian (net-proxy/dansguardian-2.9) has a 
better anti-virus support hence making dgav hack obsolete.

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] [PATCH] --config-root command-line option

2006-11-16 Thread Simon Stelling

Daniel Barkalow wrote:
Allow PORTAGE_CONFIGROOT to be set as a command-line option. It can be 
annoying to get environment variables to emerge, particularly when you 
need sudo and you only want the environment variable some of the time.


I think it would be better to solve the problem with sudo at its root:

/etc/sudoers has the following:

# Reset environment by default
Defaultsenv_reset

Commenting that out reverts this annoying behaviour and fixes all 
kinds of bugs.


--
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
--
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] [PATCH] --config-root command-line option

2006-11-16 Thread Marius Mauch
On Thu, 16 Nov 2006 09:33:05 -0800
Zac Medico [EMAIL PROTECTED] wrote:

 Sure, that's one way to solve that particular problem.  However, I feel
 that command line options are more aesthetically appealing than environment
 variables (maybe it's just me).
 
 Zac

It's just you ;)

Marius
-- 
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] [PATCH] --config-root command-line option

2006-11-16 Thread Marius Mauch
On Thu, 16 Nov 2006 15:43:48 -0800
Zac Medico [EMAIL PROTECTED] wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Marius Mauch wrote:
  On Thu, 16 Nov 2006 09:33:05 -0800
  Zac Medico [EMAIL PROTECTED] wrote:
  
  Sure, that's one way to solve that particular problem.  However, I feel
  that command line options are more aesthetically appealing than environment
  variables (maybe it's just me).
 
  Zac
  
  It's just you ;)
  
  Marius
 
 Do you honestly prefer environment variables over command line options?  I
 prefer command line options because they are part of a clearly defined
 interface.  With environment variables, the interface may not be clearly
 defined and it's easy for variables to accidentally leak in, affecting
 internals in unexpected ways.
 
 Zac

I prefer to have one way to do things, and the system for variables worked 
quite well so far. Adding CLI overrides on top of that seems not only redundant 
to me but also potentially confusing (which vars have CLI overrides? where in 
the incremental stack does the override fit in?). Add that to the already 
overloaded option system.
Besides, if you need this feature on a somewhat regular base it seems easier to 
me to just export the var once instead of specifying the option on the command 
line all the time (ok, using DEFAULT_OPTS avoids that, but then you have the 
same issues you listed above).
And last but not least a CLI option is bound to emerge, but this feature can 
also be useful for other tools. Checking an env var in the config class would 
enable it implicitly for all users of portage.py, without it everyone would 
have to basically duplicate the relevant code from emerge.
I'm not generally against using CLI options for passing in arguments, but in 
this case I think it's wrong.

Marius
-- 
gentoo-portage-dev@gentoo.org mailing list