[gentoo-dev] xchat-1.8.2 anomalies

[gentoo-dev] xchat-1.8.2 anomalies

[Karl Trygve Kalleberg]

The xchat-1.8.2 has a few 'issues' when compiled with python 2.0
support. The configure.in file should be patched along the lines:

307c307
<                               PY_LIBS="-lpython$PY_VERSION"
---
>                               PY_LIBS="`python-config` -lm"

(Sorry for not -u'ing this diff).

Also, xchat-1.8.2 will not compile properly with --disable-perl. I'm still
investigating this.

I would very much guess this to be the xchat developers' fault, not the
ebuild maintainer (achim in this case).


Regards,

Karl T

Re: [gentoo-dev] xchat-1.8.2 anomalies

[Daniel Robbins]

On Wed, Aug 01, 2001 at 09:53:15PM +0200, Karl Trygve Kalleberg wrote:
> The xchat-1.8.2 has a few 'issues' when compiled with python 2.0
> support. The configure.in file should be patched along the lines:
> 
> 307c307
> <                               PY_LIBS="-lpython$PY_VERSION"
> ---
> >                               PY_LIBS="`python-config` -lm"
> 
> (Sorry for not -u'ing this diff).
> 
> Also, xchat-1.8.2 will not compile properly with --disable-perl. I'm still
> investigating this.
> 
> I would very much guess this to be the xchat developers' fault, not the
> ebuild maintainer (achim in this case).

Well, python-config is a Gentoo Linux-specific program, but it definitely
a good thing :)  Please continue to work on the ebuild and post it here when
you have everything working.

Best Regards,

-- 
Daniel Robbins					<drobbins@gentoo.org>
Chief Architect/President			http://www.gentoo.org 
Gentoo Technologies, Inc.			

Re: [gentoo-dev] xchat-1.8.2 anomalies

[Karl Trygve Kalleberg]

On Wed, Aug 01, 2001 at 01:57:00PM -0600, Daniel Robbins wrote:

> Well, python-config is a Gentoo Linux-specific program, but it definitely
> a good thing :)  Please continue to work on the ebuild and post it here when
> you have everything working.

Then I've found a slight bug in python-config, actually. It forgets to
include -lm. When I added that to python-config, everything works nicely. 

Achim's xchat-1.8.2 ebuild already patches the Makefiles (I didn't
notice this until after I sent the mail) to use the library-list
python-config tells it to do, it's just that python-config doesn't include
-lm in this list.

I don't have CVS access, so somebody else should add -lm to
python-config; This is with dev-lang/python/python-2.0-r4.ebuild, might
apply to the other ebuilds as well.


Kind regards,

Karl T

Re: [gentoo-dev] xchat-1.8.2 anomalies

[Mikael Hallendal]

Karl Trygve Kalleberg <karltk@prosalg.no> writes:

> Achim's xchat-1.8.2 ebuild already patches the Makefiles (I didn't
> notice this until after I sent the mail) to use the library-list
> python-config tells it to do, it's just that python-config doesn't
> include -lm in this list.

A little policy question here since I upgraded to 1.8.2, not
Achim. Should the Author be left there? I think it's better to look at
the last commiter then on the AUTHOR since everyone commits to every
packages. 

Regards,
Mikael Hallendal

-- 
Mikael Hallendal                micke@codefactory.se
CodeFactory AB                  http://www.codefactory.se/
Office: +46 (0)8 587 583 05     Cell: +46 (0)709 718 918

Re: [gentoo-dev] xchat-1.8.2 anomalies

[Daniel Robbins]

On Thu, Aug 02, 2001 at 12:30:20AM +0200, Mikael Hallendal wrote:
> Karl Trygve Kalleberg <karltk@prosalg.no> writes:
> 
> > Achim's xchat-1.8.2 ebuild already patches the Makefiles (I didn't
> > notice this until after I sent the mail) to use the library-list
> > python-config tells it to do, it's just that python-config doesn't
> > include -lm in this list.
> 
> A little policy question here since I upgraded to 1.8.2, not
> Achim. Should the Author be left there? I think it's better to look at
> the last commiter then on the AUTHOR since everyone commits to every
> packages. 

I agree.  When we make a new version of an ebuild, we should update the
Author line.  Also, I think I'm going to start writing it as "Author:"
rather than "Author".  Exciting!

:)

-- 
Daniel Robbins					<drobbins@gentoo.org>
Chief Architect/President			http://www.gentoo.org 
Gentoo Technologies, Inc.			

Re: [gentoo-dev] xchat-1.8.2 anomalies

[Chad M. Huneycutt]

Daniel Robbins wrote:

>On Thu, Aug 02, 2001 at 12:30:20AM +0200, Mikael Hallendal wrote:
>
>>Karl Trygve Kalleberg <karltk@prosalg.no> writes:
>>
>>>Achim's xchat-1.8.2 ebuild already patches the Makefiles (I didn't
>>>notice this until after I sent the mail) to use the library-list
>>>python-config tells it to do, it's just that python-config doesn't
>>>include -lm in this list.
>>>
>>A little policy question here since I upgraded to 1.8.2, not
>>Achim. Should the Author be left there? I think it's better to look at
>>the last commiter then on the AUTHOR since everyone commits to every
>>packages. 
>>
>
>I agree.  When we make a new version of an ebuild, we should update the
>Author line.  Also, I think I'm going to start writing it as "Author:"
>rather than "Author".  Exciting!
>
>:)
>
What do you mean by "update the Author line".  I agree that we should 
append our names to the author line, like so
#Author: Daniel Robbins <drobbins@gentoo.org>
#              Chad Huneycutt <chadh@gentoo.org>

or if we don't care about keeping a record of everyone who has worked on 
an ebuild, then how about "Maintainer:"?

Chad

Re: [gentoo-dev] xchat-1.8.2 anomalies

[Mikael Hallendal]

Hi!

> What do you mean by "update the Author line".  I agree that we should
> append our names to the author line, like so #Author: Daniel Robbins
> <drobbins@gentoo.org> # Chad Huneycutt <chadh@gentoo.org>

I mean what it sounds like. That if I take a version of a script and
bumps it to a new version and perhaps changing stuff in it change the
Author-line to my name instead of whatever stood that in the
beginning. Perhaps this is not needed but since people seem to look at
Author instead of last commit about who has made the changed I think
it's better to change Author.
 
> or if we don't care about keeping a record of everyone who has worked
> on an ebuild, then how about "Maintainer:"?

This is also an idea. But when should this be changed?

As it is now people change the files that they don't "maintain" which
breaks all sort of maintainership of an ebuild.

Regards,
Mikael Hallendal

-- 
Mikael Hallendal                micke@codefactory.se
CodeFactory AB                  http://www.codefactory.se/
Office: +46 (0)8 587 583 05     Cell: +46 (0)709 718 918

Re: [gentoo-dev] xchat-1.8.2 anomalies

[Karl Trygve Kalleberg]

On Fri, Aug 03, 2001 at 03:45:48AM +0200, Mikael Hallendal wrote:
> Hi!
> 
> > What do you mean by "update the Author line".  I agree that we should
> > append our names to the author line, like so #Author: Daniel Robbins
> > <drobbins@gentoo.org> # Chad Huneycutt <chadh@gentoo.org>
> 
> I mean what it sounds like. That if I take a version of a script and
> bumps it to a new version and perhaps changing stuff in it change the
> Author-line to my name instead of whatever stood that in the
> beginning. Perhaps this is not needed but since people seem to look at
> Author instead of last commit about who has made the changed I think
> it's better to change Author.
>  
> > or if we don't care about keeping a record of everyone who has worked
> > on an ebuild, then how about "Maintainer:"?
> 
> This is also an idea. But when should this be changed?
> 
> As it is now people change the files that they don't "maintain" which
> breaks all sort of maintainership of an ebuild.

Okay, my suggestion.

Maintainer: will be the maintaining team.
Author: will be the guy from the maintaining team that sanctioned the
script.

Each ebuild belongs to one team. If any one outside the team fixes
anything, it should go through 'incoming' in some fashion then be
sanctioned by one of the team members.

Alternatively, if we're picky about credits (we should be), then
Author: is the contributor who fixed it (who either came with a patch or
wrote the script in the first place) and we can add an
Sponsor: which is a team member who added it to CVS and puts his rep on
the line claiming this script is bugfree.

Might also allow multiple authors for some of the nasty scripts that have
been patched multiple times by multiple people.

.. Or we could just have a global CONTRIBUTORS file somewhere.

Regards,

Karl T

Re: [gentoo-dev] xchat-1.8.2 anomalies

[Mikael Hallendal]

> Each ebuild belongs to one team. If any one outside the team fixes
> anything, it should go through 'incoming' in some fashion then be
> sanctioned by one of the team members.

I think this is the way to do it in the long run. We can't keep on
doing as we do now as the number of ebuilds grow and we get a broader
userbase which will demand working ebuilds. And it's impossible to
keep up with everything if your ebuilds gets updated by a lot of other
guys.
 
> Alternatively, if we're picky about credits (we should be), then
> Author: is the contributor who fixed it (who either came with a patch
> or wrote the script in the first place) and we can add an Sponsor:
> which is a team member who added it to CVS and puts his rep on the
> line claiming this script is bugfree.

This sounds like a hard way which really doesn't solve
anything. Becuase if you write an ebuild, I change it a little, sends
it in. Then AUTHOR will be set to me and whoever commited my changes
would be in Sponsor: and you will be left out. 

Regards,
Mikael Hallendal

-- 
Mikael Hallendal                micke@codefactory.se
CodeFactory AB                  http://www.codefactory.se/
Office: +46 (0)8 587 583 05     Cell: +46 (0)709 718 918

Re: [gentoo-dev] xchat-1.8.2 anomalies

[Morten Liebach]

On  3, Aug, 2001 at 05:35:26AM +0200, Mikael Hallendal wrote:
> > Each ebuild belongs to one team. If any one outside the team fixes
> > anything, it should go through 'incoming' in some fashion then be
> > sanctioned by one of the team members.
> 
> I think this is the way to do it in the long run. We can't keep on
> doing as we do now as the number of ebuilds grow and we get a broader
> userbase which will demand working ebuilds. And it's impossible to
> keep up with everything if your ebuilds gets updated by a lot of other
> guys.

I've run OpenBSD for the last year, and in the ports there it works like
this:

In the port Makefile there's a MAINTAINER value, who's the person who
made the port, or has taken maintainership of it, if the original
maintainer has lost interest.

The MAINTAINER doesn't necessarily have cvs commit access.

MAINTAINER can be set to ports@openbsd.org.

When a port is updated it's OK'ed by the maintainer or the maintainer
does it him-/her-self and if necessary it's committed by someone else,
either by some sponsor wih commit access, or by sending it to
ports@openbsd.org where someone picks it up and commits it.

This system works very well.

Just my .02euro

HAND
	Morten (who needs to install Gentoo over OpenBSD this week-end :-)

-- 
×·.¸¸.·´¨)    ¸.·´  ¸.·´¨)     O    Morten Liebach <morten@hotpost.dk>
        (_¸.·´ (¸.·´  ¸.·×     0    http://home1.stofanet.dk/liebach/
                     (_¸.·´    o    http://pc89225.stofanet.dk/
                               .

Re: [gentoo-dev] xchat-1.8.2 anomalies

[Chad M. Huneycutt]

Mikael Hallendal wrote:

>>Each ebuild belongs to one team. If any one outside the team fixes
>>anything, it should go through 'incoming' in some fashion then be
>>sanctioned by one of the team members.
>>
>
>I think this is the way to do it in the long run. We can't keep on
>doing as we do now as the number of ebuilds grow and we get a broader
>userbase which will demand working ebuilds. And it's impossible to
>keep up with everything if your ebuilds gets updated by a lot of other
>guys.
>
I think if we choose to do this, then we had better rethink the incoming 
directory right now.  While it may be okay for a few outstanding 
user-submitted ebuilds, this scheme has the potential to cause a lot 
problems.  What we really need is an unstable cvs tree; then 
user-submitted ebuilds and non-team developer-hacked ebuilds can go 
there until they are verified by team members.

>
>>Alternatively, if we're picky about credits (we should be), then
>>Author: is the contributor who fixed it (who either came with a patch
>>or wrote the script in the first place) and we can add an Sponsor:
>>which is a team member who added it to CVS and puts his rep on the
>>line claiming this script is bugfree.
>>
>
>This sounds like a hard way which really doesn't solve
>anything. Becuase if you write an ebuild, I change it a little, sends
>it in. Then AUTHOR will be set to me and whoever commited my changes
>would be in Sponsor: and you will be left out.
>
I think all we need is maintainer.  This is the guy who "puts his rep on 
the line."  cvs log keeps all the other information.  The person you 
really want to complain to about a bad ebuild is the maintainer anyway. 
 Then he can do a cvs log to see who the culprit is and get in touch.

Chad

[gentoo-dev] Maintainership and commit policy

[Mikael Hallendal]

Hi!

I renamed the thread since it's not about xchat 1.8.2 anymore.

> I think if we choose to do this, then we had better rethink the
> incoming directory right now.  While it may be okay for a few
> outstanding user-submitted ebuilds, this scheme has the potential to
> cause a lot problems.  What we really need is an unstable cvs tree;
> then user-submitted ebuilds and non-team developer-hacked ebuilds can
> go there until they are verified by team members.

If we have maintainer of ebuilds (which I think we shall have) I don't
think that other people should commit into the CVS tree without his
aproval (neither unstable nor stable). It will be very hard for a
maintainer of many packages to keep track of what's happening if
people just commit at will.

> I think all we need is maintainer.  This is the guy who "puts his rep
> on the line."  cvs log keeps all the other information.  The person
> you really want to complain to about a bad ebuild is the maintainer
> anyway. Then he can do a cvs log to see who the culprit is and get in
> touch.

This will not be a problem if only the maintainer are allowed to
commit (or aprove commits). I think this is the best way to do it.

If you want to make a commit to an ebuild that you are not maintainer
of:

If you are a developer:
1) Send the patch to the maintainer asking if you may commit.
2) The maintainer might commit or aprove of you commiting or tell you
   why it won't go in (and perhaps what you need to fix first).

Otherwise:
1) Send the patch to the maintainer which will either commit or tell
   you to change the patch in some way.

This will make it harder for people to commit to all kinds of ebuilds
but I think that this is the way we have to do it in the future.

Of course a maintainer might give a certain person commit rights if he
trusts the other developer to do it right.

Regards,
Mikael Hallendal

-- 
Mikael Hallendal                micke@codefactory.se
CodeFactory AB                  http://www.codefactory.se/
Office: +46 (0)8 587 583 05     Cell: +46 (0)709 718 918

Re: [gentoo-dev] Maintainership and commit policy

[Dan Armak]

AFAIK, we could manage the entire thing via cvs - no incoming dir, no 
commit-request emails.

We would have several 'trees' in cvs: stable, unstable (=devel), external 
(any better names?), incoming (=user-submitted), trees for past releases 
which could get bugfixes, etc.

A developer who wanted to change another developer's ebuild would have to 
commit a new revision of that ebuild to the 'external' tree. (That's what 
he'd have permissions to do.) The maintaining developer could then look over 
his changes (and the commit log message), and if he accepted them, merge the 
changes into his main devel tree. Once in there, the changes needed to be 
proven stable and good (like the maintainer's own work) and would then be 
merged into the stable tree. Non-developers who did 'emere rsync' could only 
get things from the stable tree.

A similar procedure wuold be used for 'incoming' user ebuilds, with another 
cvs tree.

What do you think?


On Friday 03 August 2001 18:08, you wrote:
> Hi!
>
> I renamed the thread since it's not about xchat 1.8.2 anymore.
>
> > I think if we choose to do this, then we had better rethink the
> > incoming directory right now.  While it may be okay for a few
> > outstanding user-submitted ebuilds, this scheme has the potential to
> > cause a lot problems.  What we really need is an unstable cvs tree;
> > then user-submitted ebuilds and non-team developer-hacked ebuilds can
> > go there until they are verified by team members.
>
> If we have maintainer of ebuilds (which I think we shall have) I don't
> think that other people should commit into the CVS tree without his
> aproval (neither unstable nor stable). It will be very hard for a
> maintainer of many packages to keep track of what's happening if
> people just commit at will.
>
> > I think all we need is maintainer.  This is the guy who "puts his rep
> > on the line."  cvs log keeps all the other information.  The person
> > you really want to complain to about a bad ebuild is the maintainer
> > anyway. Then he can do a cvs log to see who the culprit is and get in
> > touch.
>
> This will not be a problem if only the maintainer are allowed to
> commit (or aprove commits). I think this is the best way to do it.
>
> If you want to make a commit to an ebuild that you are not maintainer
> of:
>
> If you are a developer:
> 1) Send the patch to the maintainer asking if you may commit.
> 2) The maintainer might commit or aprove of you commiting or tell you
>    why it won't go in (and perhaps what you need to fix first).
>
> Otherwise:
> 1) Send the patch to the maintainer which will either commit or tell
>    you to change the patch in some way.
>
> This will make it harder for people to commit to all kinds of ebuilds
> but I think that this is the way we have to do it in the future.
>
> Of course a maintainer might give a certain person commit rights if he
> trusts the other developer to do it right.
>
> Regards,
> Mikael Hallendal

-- 

Dan Armak
Gentoo Linux Developer, Desktop Team
Matan, Israel

Re: [gentoo-dev] Maintainership and commit policy

[Thomas M. Beaudry]

Sounds like the Mandrake system and it seems to work for them.

On Fri, Aug 03, 2001 at 07:16:40PM +0300, Dan Armak wrote:
> AFAIK, we could manage the entire thing via cvs - no incoming dir, no 
> commit-request emails.
> 
> We would have several 'trees' in cvs: stable, unstable (=devel), external 
> (any better names?), incoming (=user-submitted), trees for past releases 
> which could get bugfixes, etc.
> 
> A developer who wanted to change another developer's ebuild would have to 
> commit a new revision of that ebuild to the 'external' tree. (That's what 
> he'd have permissions to do.) The maintaining developer could then look over 
> his changes (and the commit log message), and if he accepted them, merge the 
> changes into his main devel tree. Once in there, the changes needed to be 
> proven stable and good (like the maintainer's own work) and would then be 
> merged into the stable tree. Non-developers who did 'emere rsync' could only 
> get things from the stable tree.
> 
> A similar procedure wuold be used for 'incoming' user ebuilds, with another 
> cvs tree.
> 
> What do you think?
> 
> 
> On Friday 03 August 2001 18:08, you wrote:
> > Hi!
> >
> > I renamed the thread since it's not about xchat 1.8.2 anymore.
> >
> > > I think if we choose to do this, then we had better rethink the
> > > incoming directory right now.  While it may be okay for a few
> > > outstanding user-submitted ebuilds, this scheme has the potential to
> > > cause a lot problems.  What we really need is an unstable cvs tree;
> > > then user-submitted ebuilds and non-team developer-hacked ebuilds can
> > > go there until they are verified by team members.
> >
> > If we have maintainer of ebuilds (which I think we shall have) I don't
> > think that other people should commit into the CVS tree without his
> > aproval (neither unstable nor stable). It will be very hard for a
> > maintainer of many packages to keep track of what's happening if
> > people just commit at will.
> >
> > > I think all we need is maintainer.  This is the guy who "puts his rep
> > > on the line."  cvs log keeps all the other information.  The person
> > > you really want to complain to about a bad ebuild is the maintainer
> > > anyway. Then he can do a cvs log to see who the culprit is and get in
> > > touch.
> >
> > This will not be a problem if only the maintainer are allowed to
> > commit (or aprove commits). I think this is the best way to do it.
> >
> > If you want to make a commit to an ebuild that you are not maintainer
> > of:
> >
> > If you are a developer:
> > 1) Send the patch to the maintainer asking if you may commit.
> > 2) The maintainer might commit or aprove of you commiting or tell you
> >    why it won't go in (and perhaps what you need to fix first).
> >
> > Otherwise:
> > 1) Send the patch to the maintainer which will either commit or tell
> >    you to change the patch in some way.
> >
> > This will make it harder for people to commit to all kinds of ebuilds
> > but I think that this is the way we have to do it in the future.
> >
> > Of course a maintainer might give a certain person commit rights if he
> > trusts the other developer to do it right.
> >
> > Regards,
> > Mikael Hallendal
> 
> -- 
> 
> Dan Armak
> Gentoo Linux Developer, Desktop Team
> Matan, Israel
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@cvs.gentoo.org
> http://cvs.gentoo.org/mailman/listinfo/gentoo-dev
> 

-- 
Thomas M. Beaudry K8LA / YS1ZTM
k8la@arrl.net

Re: [gentoo-dev] Maintainership and commit policy

[Mikael Hallendal]

Hi!

> AFAIK, we could manage the entire thing via cvs - no incoming dir, no
> commit-request emails.
> 
> We would have several 'trees' in cvs: stable, unstable (=devel),
> external (any better names?), incoming (=user-submitted), trees for
> past releases which could get bugfixes, etc.
> 
> A developer who wanted to change another developer's ebuild would have
> to commit a new revision of that ebuild to the 'external'
> tree. (That's what he'd have permissions to do.) The maintaining
> developer could then look over his changes (and the commit log
> message), and if he accepted them, merge the changes into his main
> devel tree. Once in there, the changes needed to be proven stable and
> good (like the maintainer's own work) and would then be merged into
> the stable tree. Non-developers who did 'emere rsync' could only get
> things from the stable tree.
> 
> A similar procedure wuold be used for 'incoming' user ebuilds, with
> another cvs tree.
> 
> What do you think?

Hmm, would this mean that I would have to have four different cvs
trees checked out from CVS? stable, unstable, external and incoming?

I think an incoming is unnescessary, an incoming directory is much
better. Perhaps is it my lack of cvs knowledge but would I then have
to update my incoming/external tree and look if any of my files have
been added/updated and then copy the file into my unstable tree and
commit it there, remove it from the external/incoming tree and 'cvs
rm' them in those trees? This doesn't sound like a good solution and
indeed creates more work then mailing the maintainer.

Regards,
Mikael Hallendal

-- 
Mikael Hallendal                micke@codefactory.se
CodeFactory AB                  http://www.codefactory.se/
Office: +46 (0)8 587 583 05     Cell: +46 (0)709 718 918

Re: [gentoo-dev] Maintainership and commit policy

[Parag Mehta]

Hi,

With due respects to all developers, and the thread that has been going on, following is my 2 cents for the same :

Since we hae the new team system in place, i think the following should be the tree structure :
under incoming directory there should be team directories and under that the new incoming ebuilds from the list or from developers who do not maintain the ebuilds they wish to commit.
after committing to the corresponding team.

and before that i assume the developers shouldbe aware which directories from the portage tree belong to which team ?!
once committed to the incoming tree for an ebuild which a developer doesn't maintain , he should mail the current developer for either committing that ebuild or wait for this comments. if the new maintainer doesn't recieve any response from the old maintainer in let's say 3-4 days then the new maintainer can reqeust the commit access from the curent group leader.

this way i think it will be more easier to maintain the tree structure.

regards,

pm
--
Developer		 <pm@gentoo.org>
Gentoo Linux		http://gentoo.org

Re: [gentoo-dev] Maintainership and commit policy

[Mikael Hallendal]

Hi!

> Since we hae the new team system in place, i think the following
> should be the tree structure : under incoming directory there should
> be team directories and under that the new incoming ebuilds from the
> list or from developers who do not maintain the ebuilds they wish to
> commit.  after committing to the corresponding team.
> 
> and before that i assume the developers shouldbe aware which
> directories from the portage tree belong to which team ?!  once
> committed to the incoming tree for an ebuild which a developer doesn't
> maintain , he should mail the current developer for either committing
> that ebuild or wait for this comments. if the new maintainer doesn't
> recieve any response from the old maintainer in let's say 3-4 days
> then the new maintainer can reqeust the commit access from the curent
> group leader.

This sounds very good to me, with a little modification :) 
If it's a change in an existing ebuild it's better to submit a patch
against the current becuase with a patch it's much easier to se what
changes has been made. I think this goes when changing the version
number too. 

Regards,
Mikael Hallendal

-- 
Mikael Hallendal                micke@codefactory.se
CodeFactory AB                  http://www.codefactory.se/
Office: +46 (0)8 587 583 05     Cell: +46 (0)709 718 918

Re: [gentoo-dev] Maintainership and commit policy

[Ben Lutgens]

[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]

On Fri, Aug 03, 2001 at 10:30:05PM -0600, Parag Mehta wrote:
>Hi,
>
>With due respects to all developers, and the thread that has been going on, following is my 2 cents for the same :
>

I fear that this is quickly going to turn into the same issues seen with
debian's overly "democratic" mentality. They vote and bicker about
everything. While I agree that input is good. Ultimately this is not
exactly a community project. We are almost all volunteers and should keep
that in mind when putting forth our input. 

IMHO put forth your .02 and leave it at that. I think we should have the
ability to share our input then let Daniel and Achim and the others make
all the decisions (or delegate as they see fit)

I'd really hate to see us denigrate into the bickering that goes on on
debian-devel....

Oh and by the by I am not in favor of several trees. Too many moving
pieces. That's what cvs tags are for.

-- 
Ben Lutgens		
Sistina Software Inc.	

What's the difference between root and God ?
God doesn't think that he is root. 

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] Maintainership and commit policy

[Dan Armak]

On Sunday 05 August 2001 18:58, you wrote:
> On Fri, Aug 03, 2001 at 10:30:05PM -0600, Parag Mehta wrote:
> >Hi,
> >
> >With due respects to all developers, and the thread that has been going
> > on, following is my 2 cents for the same :
>
> I fear that this is quickly going to turn into the same issues seen with
> debian's overly "democratic" mentality. They vote and bicker about
> everything. While I agree that input is good. Ultimately this is not
> exactly a community project. We are almost all volunteers and should keep
> that in mind when putting forth our input.
>
> IMHO put forth your .02 and leave it at that. I think we should have the
> ability to share our input then let Daniel and Achim and the others make
> all the decisions (or delegate as they see fit)
>
> I'd really hate to see us denigrate into the bickering that goes on on
> debian-devel....
>
> Oh and by the by I am not in favor of several trees. Too many moving
> pieces. That's what cvs tags are for.

That's probably what I meant. I'm not sure about cvs terminology, thanks for 
the correction.


-- 

Dan Armak
Gentoo Linux Developer, Desktop Team
Matan, Israel

Re: [gentoo-dev] Maintainership and commit policy

[Daniel Robbins]

On Sun, Aug 05, 2001 at 10:58:43AM -0500, Ben Lutgens wrote:

> I fear that this is quickly going to turn into the same issues seen with
> debian's overly "democratic" mentality. They vote and bicker about
> everything. While I agree that input is good. Ultimately this is not exactly
> a community project. We are almost all volunteers and should keep that in
> mind when putting forth our input. 

I totally agree with you, Ben.  Frankly, this discussion (of ebuild Author
comments) is not worthy of the time that people have been putting into it.  I
would much rather have developers focus on Gentoo Linux proper and getting
ebuilds tested and fixed.  We always have #gentoo if you just want to chat
about new ideas or new ways of doing things.  But frankly, we already have lots
of good ideas; the main problem we have is a lack of manpower to implement
them.  If people will help with the tough stuff, these little things will
take care of themselves.

Best Regards,

-- 
Daniel Robbins					<drobbins@gentoo.org>
Chief Architect/President			http://www.gentoo.org 
Gentoo Technologies, Inc.			

Re: [gentoo-dev] Maintainership and commit policy

[Mikael Hallendal]

Hi!

> I totally agree with you, Ben.  Frankly, this discussion (of ebuild
> Author comments) is not worthy of the time that people have been
> putting into it.  I would much rather have developers focus on Gentoo
> Linux proper and getting ebuilds tested and fixed.  We always have
> #gentoo if you just want to chat about new ideas or new ways of doing
> things.  But frankly, we already have lots of good ideas; the main
> problem we have is a lack of manpower to implement them.  If people
> will help with the tough stuff, these little things will take care of
> themselves.

Hmm, I fail to see why a discussion about the policy of maintainership
is not worth the time. I think most people do agree generally, the
thing that's left is that someone writes a document on what we'll do
in the future. (or will we just continue as it's now?)

Regards,
  Mikael Hallendal

-- 
Mikael Hallendal                micke@codefactory.se
CodeFactory AB                  http://www.codefactory.se/
Office: +46 (0)8 587 583 05     Cell: +46 (0)709 718 918

Re: [gentoo-dev] Maintainership and commit policy

[Daniel Robbins]

On Sun, Aug 05, 2001 at 09:12:46PM +0200, Mikael Hallendal wrote:

> Hmm, I fail to see why a discussion about the policy of maintainership
> is not worth the time. I think most people do agree generally, the
> thing that's left is that someone writes a document on what we'll do
> in the future. (or will we just continue as it's now?)

Already posted something to the list about this; pretty sure.  We'll be
changing the line to appear as:

# Maintainer: system@gentoo.org

However, we can't start doing this yet because I don't have the new mailing
lists set up.

Best Regards,

-- 
Daniel Robbins					<drobbins@gentoo.org>
Chief Architect/President			http://www.gentoo.org 
Gentoo Technologies, Inc.