On Thursday 13 July 2006 18:53, Ciaran McCreesh wrote:
On Thu, 13 Jul 2006 14:55:57 +0200 Paul de Vrieze [EMAIL PROTECTED]
wrote:
| The dev manual is *wrong*.
No, the devmanual reflects what's actually being done, rather than an
impractical definition that was written years ago that no
On Thursday 15 June 2006 07:57, Harald van Dijk wrote:
So herdgames/herd implies managed by the games team sometimes but
not always? Meaning if the maintainer is games team + X, then games
team must be explicitly listed as a maintainer in metadata.xml ?
If so, sorry, misunderstood you, and
On Thursday 15 June 2006 02:54, Dan Meltzer wrote:
According to the devmanual [1]
A herd is a collection of developers who maintain a collection of
related packages
are you sure you are using the correct term?
[1]
http://devmanual.gentoo.org/general-concepts/herds-and-projects/index.html
On Thu, 13 Jul 2006 14:55:57 +0200 Paul de Vrieze [EMAIL PROTECTED]
wrote:
| The dev manual is *wrong*.
No, the devmanual reflects what's actually being done, rather than an
impractical definition that was written years ago that no longer
matches the development model.
--
Ciaran McCreesh
Mail
On Wed, Jun 14, 2006 at 05:13:48PM -0400, Chris Gianelloni wrote:
On Wed, 2006-06-14 at 15:54 +0200, Harald van Dijk wrote:
On Wed, Jun 14, 2006 at 09:13:34AM -0400, Chris Gianelloni wrote:
A great example of this are web-based applications. The web-apps
project
does not own all
On 6/14/06, Chris Gianelloni [EMAIL PROTECTED] wrote:
http://www.gentoo.org/proj/en/metastructure/herds/#doc_chap4
Specifically the listing for the herd tag.
Just because people are doing things *wrong* doesn't mean that there
isn't a defined manner in which things should be done.
From the
On Thu, 15 Jun 2006 15:07:36 +0100
Stuart Herbert [EMAIL PROTECTED] wrote:
On 6/14/06, Chris Gianelloni [EMAIL PROTECTED] wrote:
http://www.gentoo.org/proj/en/metastructure/herds/#doc_chap4
Specifically the listing for the herd tag.
Just because people are doing things *wrong* doesn't
Hi Kevin,
On 6/15/06, Kevin F. Quinn [EMAIL PROTECTED] wrote:
I read the should as
implying that all new packages must have it, and packages existing
before the introduction of metadata should get it as and when
maintainer gets around to it (i.e. at least on the next bump).
Chris's argument
On Thu, 2006-06-15 at 19:18 +0100, Stuart Herbert wrote:
Hi Kevin,
On 6/15/06, Kevin F. Quinn [EMAIL PROTECTED] wrote:
I read the should as
implying that all new packages must have it, and packages existing
before the introduction of metadata should get it as and when
maintainer gets
On Tue, 2006-06-13 at 23:52 +0100, Stuart Herbert wrote:
Packages are grouped into herds, which are managed by projects. If a
package doesn't belong to a herd, then it doesn't belong to the project, and
other developers are free to take ownership of the package and include it
into the tree.
On Wed, 2006-06-14 at 08:38 +0200, Kevin F. Quinn wrote:
On Tue, 13 Jun 2006 23:19:51 +0100
Stuart Herbert [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael Cummings wrote:
| Chris Gianelloni wrote:
| Using your example, if it will *never* make it into
On Wed, Jun 14, 2006 at 09:13:34AM -0400, Chris Gianelloni wrote:
A great example of this are web-based applications. The web-apps project
does not own all the web-based packages in the Portage tree. There are many
such packages in the tree that are managed by developers that are not part
On Wed, Jun 14, 2006 at 09:18:57AM -0400, Chris Gianelloni wrote:
I would have *no problem* with an opt-in system. Instead of using
InOverlay (which is a poor choice anyway... which overlay?) as some
sort of tag, instead, assign the package to the project which maintains
the herd the package
Henrik Brix Andersen wrote:
On Wed, Jun 14, 2006 at 09:18:57AM -0400, Chris Gianelloni wrote:
I would have *no problem* with an opt-in system. Instead of using
InOverlay (which is a poor choice anyway... which overlay?) as some
sort of tag, instead, assign the package to the project which
Chris Gianelloni wrote:
Again, you are confusing herds and projects.
Here's another example of it done correctly. If you add a game to the
tree, the herd should be listed as games. Period. Even if you are
going to be the sole maintainer of the package, games should be the
herd. Why?
On Wed, 14 Jun 2006 20:01:04 +0200
Jakub Moc [EMAIL PROTECTED] wrote:
This new terminology plain sucks. If you are sticking games into
herd in metadata.xml, you are just confusing me and other people
who are assigning bugs.
It's not new. If it confuses you, perhaps you should learn the
Stephen Bennett wrote:
On Wed, 14 Jun 2006 20:01:04 +0200
Jakub Moc [EMAIL PROTECTED] wrote:
This new terminology plain sucks. If you are sticking games into
herd in metadata.xml, you are just confusing me and other people
who are assigning bugs.
It's not new. If it confuses you,
On Wed, 14 Jun 2006 20:21:42 +0200
Jakub Moc [EMAIL PROTECTED] wrote:
Sure... so, perhaps you have some suggestion how I can read assign
bugs otherwise than using the metadata.xml; perhaps I could learn to
read minds of the developers who dump irrelevant stuff into
metadata.xml and expect
On Wed, 2006-06-14 at 09:13 -0400, Chris Gianelloni wrote:
Just because the maintaining *project* doesn't
want it doesn't mean it doesn't belong to that herd.
This is incorrect and you should not encourage people to add pkgs to
a herd unless they get permission from that herd. If a herd does
Chris Gianelloni wrote:
Here's another example of it done correctly. If you add a game to the
tree, the herd should be listed as games. Period. Even if you are
going to be the sole maintainer of the package, games should be the
herd. Why? Because it is a game, silly.
There _is_ no
Stephen Bennett wrote:
On Wed, 14 Jun 2006 20:21:42 +0200
Jakub Moc [EMAIL PROTECTED] wrote:
Sure... so, perhaps you have some suggestion how I can read assign
bugs otherwise than using the metadata.xml; perhaps I could learn to
read minds of the developers who dump irrelevant stuff into
On Wed, 14 Jun 2006 22:34:55 +0200
Jakub Moc [EMAIL PROTECTED] wrote:
Please, go through the tree and see at least so many metadata.xml
files as I have seen, before claiming something that simply doesn't
reflect current practice. There are many ebuilds with no maintainer
tag and herd only.
On Wed, 2006-06-14 at 15:54 +0200, Harald van Dijk wrote:
On Wed, Jun 14, 2006 at 09:13:34AM -0400, Chris Gianelloni wrote:
A great example of this are web-based applications. The web-apps project
does not own all the web-based packages in the Portage tree. There are
many
such
On Wed, 2006-06-14 at 15:56 +0200, Henrik Brix Andersen wrote:
On Wed, Jun 14, 2006 at 09:18:57AM -0400, Chris Gianelloni wrote:
I would have *no problem* with an opt-in system. Instead of using
InOverlay (which is a poor choice anyway... which overlay?) as some
sort of tag, instead,
On Wed, 2006-06-14 at 20:01 +0200, Jakub Moc wrote:
Chris Gianelloni wrote:
Again, you are confusing herds and projects.
Here's another example of it done correctly. If you add a game to the
tree, the herd should be listed as games. Period. Even if you are
going to be the sole
On Wed, 2006-06-14 at 20:21 +0200, Jakub Moc wrote:
Sure... so, perhaps you have some suggestion how I can read assign bugs
otherwise than using the metadata.xml; perhaps I could learn to read
minds of the developers who dump irrelevant stuff into metadata.xml and
expect someone to know what
On Wed, 2006-06-14 at 14:47 -0400, Ned Ludd wrote:
On Wed, 2006-06-14 at 09:13 -0400, Chris Gianelloni wrote:
Just because the maintaining *project* doesn't
want it doesn't mean it doesn't belong to that herd.
This is incorrect and you should not encourage people to add pkgs to
a herd
On Wed, 2006-06-14 at 20:15 +0100, Stuart Herbert wrote:
Chris Gianelloni wrote:
Here's another example of it done correctly. If you add a game to the
tree, the herd should be listed as games. Period. Even if you are
going to be the sole maintainer of the package, games should be the
On Wed, 2006-06-14 at 22:34 +0200, Jakub Moc wrote:
It's not irrelevant; you're just not reading it properly. You might
notice that metadata.xml contains tags other than herd, like, say,
maintainer. In the example that sparked this, herd is games and
maintainer the individual dev who
On Wed, 2006-06-14 at 17:25 -0400, Chris Gianelloni wrote:
On Wed, 2006-06-14 at 14:47 -0400, Ned Ludd wrote:
On Wed, 2006-06-14 at 09:13 -0400, Chris Gianelloni wrote:
Just because the maintaining *project* doesn't
want it doesn't mean it doesn't belong to that herd.
This is
On 6/14/06, Chris Gianelloni [EMAIL PROTECTED] wrote:
On Wed, 2006-06-14 at 22:34 +0200, Jakub Moc wrote:
It's not irrelevant; you're just not reading it properly. You might
notice that metadata.xml contains tags other than herd, like, say,
maintainer. In the example that sparked this,
Dan Meltzer wrote:
According to the devmanual [1]
A herd is a collection of developers who maintain a collection of
related packages
are you sure you are using the correct term?
[1]
http://devmanual.gentoo.org/general-concepts/herds-and-projects/index.html
I guess it needs to get fixed,
On Wed, 14 Jun 2006 20:54:21 -0400 Dan Meltzer
[EMAIL PROTECTED] wrote:
| According to the devmanual [1]
| A herd is a collection of developers who maintain a collection of
| related packages
|
| are you sure you are using the correct term?
Ah, yes, we're back to the old what is a herd? thing
On Tue, 13 Jun 2006 10:06:56 -0700, Donnie Berkholz wrote:
Henrik Brix Andersen wrote:
As I've said all along - I do not have any problems with Project
Sunrise. I have a problem with it being an official project hosted on
*.gentoo.org, as I fear most users will think hey, it's official, it's
On Tue, Jun 13, 2006 at 01:29:55PM -0400, Peter wrote:
[snip]
This kernel source will not cause Armageddon to arrive, cause smoke to
issue from your power supply, nor interfere with other ebuilds.
That's funny. Did you just claim that a sys-kernel/*-sources ebuild
with the patch-sets listed
On Tue, 2006-06-13 at 13:29 -0400, Peter wrote:
As an example, there is a kernel source build I've been playing with. I
know, from the kernel team, it will never, repeat NEVER, get onto the
portage tree. they want no part of it. However, the bug is widely
followed, and if Sunrise were to be a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Gianelloni wrote:
Using your example, if it will *never* make it into the tree, then what
is it doing on *.gentoo.org infrastructure?
OK, I'll speak up. I plan on using overlay.gentoo.org for the perl team
overlay repository. dev-perl alone
37 matches
Mail list logo
