Re: [gentoo-dev] Ebuilds not getting in :(

Re: [gentoo-dev] Ebuilds not getting in :(

[Stroller]

On Thursday, April 24, 2003, at 04:50  am, George Shapovalov wrote:

> On Wednesday 23 April 2003 17:32, Stroller wrote:
>> On Tuesday, April 22, 2003, at 02:17  pm, Peter Ruskin wrote:
>>> On Tuesday 22 Apr 2003 13:59, Frantz Dhin wrote:
>>>> ... maybe we could make a
>>>> new keyword? x86 for stable, ~x86 for unstable, and ^x86 for
>>>> lunatic?
>>> I couldn't agree more!
>> Me, either! I don't know that "lunatic" is the best word, but it
>> seems to me that an additional hierarchy [0] allows for a framework
>> more flexible & extensible for end lusers. As I understand it builds
>> with  the
> Unfortunately this is not that easy. Just accepting ebuild in and
> letting them
> rot is either a dead-end or a security breach (or both :).
....
> Please take a look at #1523 to see what's on the plate ;).
>> [1] Am I correctly abbreviating "^86, ^ppc or whatever" here?

Yeah, sorry. I'm clearly not qualified to comment. I decided to make my
reply before reading others about multiple rsync servers &c. My main
reason for posting was to object to the suggestion of naming a USE flag
after a hypothetical Honda.

I haven't had the chance to read your full proposal yet, but just the
title of "Distributed ebuild processing system" sounds inspiring - I
look forward to giving it my full attention, and eventually to seeing
the results.

Stroller.


-- 
Enjoyed this post? Thanks for reading - Give me a job!
Technical support / system administration
Linux / Unix / Windows / Mac OS X  - UK or anywhere considered



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Stroller]

On Tuesday, April 22, 2003, at 02:17  pm, Peter Ruskin wrote:

> On Tuesday 22 Apr 2003 13:59, Frantz Dhin wrote:
>> ... maybe we could make a
>> new keyword? x86 for stable, ~x86 for unstable, and ^x86 for lunatic?
>> :)
>
> I couldn't agree more!

Me, either! I don't know that "lunatic" is the best word, but it seems
to me that an additional hierarchy [0] allows for a framework more
flexible & extensible for end lusers. As I understand it builds with the
arch keyword are tested and Gentoo-approved, those with the ~arch are
those which Gentoo are actively or philosophically committed to seeing
become approved; consequently those in the ^arch would become
"contributed & unsupported", those for which no dev has the time or
interest for.

> Perhaps cx86 for contributors' ebuilds?

I think this is reserved for a Honda moped, a step-through with an
undersized & water-cooled transverse v-twin engine, shaft drive & a
cumbersome (if reliable) arrangement of cam-chain AND push-rods. The
previous suggestion of ^arch [1] is MUCH better, IMO, and provides no
obstacle to Honda migrating their systems to Gentoo Linux, should they
wish.

Stroller.



[0] Is that the right word?
[1] Am I correctly appreviating "^86, ^PPC or whatever" here? I'm not
doing too well tonight.


-- 
Enjoyed this post? Thanks for reading - Give me a job!
Technical support / system administration
Linux / Unix / Windows / Mac OS X.



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[George Shapovalov]

On Wednesday 23 April 2003 17:32, Stroller wrote:
> On Tuesday, April 22, 2003, at 02:17  pm, Peter Ruskin wrote:
> > On Tuesday 22 Apr 2003 13:59, Frantz Dhin wrote:
> >> ... maybe we could make a
> >> new keyword? x86 for stable, ~x86 for unstable, and ^x86 for lunatic?
> > I couldn't agree more!
> Me, either! I don't know that "lunatic" is the best word, but it seems
> to me that an additional hierarchy [0] allows for a framework more
> flexible & extensible for end lusers. As I understand it builds with the
Unfortunately this is not that easy. Just accepting ebuild in and letting them 
rot is either a dead-end or a security breach (or both :). Think about what 
to do with them as they get tested and about possible submisisons overlappig 
already existing *core* ebuilds, yek.. ).

Please take a look at #1523 to see what's on the plate ;). Only bear in mind, 
that almost everything in that proposal was written before even KEYWORDS came 
around, so terminology and, well, pretty much all implementation details are 
out of date by now.. However the general structure still applies and contains 
few more (relatively minor as compared to KEYWORDS and gentoo-stats/stable 
(AKA voting system in that text)) additions.

I am afraid it is still too early to talk about implementation details (except 
may be starategic things), as we need to complete the internal restructuring 
we are attempting right now (and convincing more devs, that we need this kind 
of thing implemented, as this was not universally accepted yet :)). But the 
logical structure can and IMHO should be discussed.

One thing I can already tell for sure, is that security of any such system 
will be an issue of paramount importance if this kind of thing to be 
accepted. Namely guarantying by implementation that some unassisted 
submission does not wreak a havoc on user system no mater what profile that 
user runs (possibly except "definitely-unstable-you've-been-warned" or 
whatever it's going to be called :)).
There are of course more issues of lesser but still major importance to be 
considered, such as efficiency on all levels...

> [1] Am I correctly appreviating "^86, ^PPC or whatever" here? I'm not
> doing too well tonight.
That'd work, especially if you spell appreviate as abbreviate and make ppc 
lowercase ;).

George

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Ebuilds not getting in :(

[Klavs Klavsen]

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

Hi guys,

I have written these ebuilds:

vserver-0.22
http://bugs.gentoo.org/show_bug.cgi?id=19230

Created because a costumer of mine wanted me to install Gentoo with
vserver. I've also talked to a guy named Georges Tooth about making an
ebuild that installs a base vserver (aka. skel vserver) that mangles the
init-system as needed (it needs to be pretty mangled - to work perfectly
and not do anything that requires capabilities as these are removed
under vserver :)

USAGI-ipv6 tools (the ipv6 impl. in linux-2.5 and in gentoo-sources)
http://bugs.gentoo.org/show_bug.cgi?id=17681

I use IPv6 - so I needed the tools.

drip-0.9.0cvs3 (the one in portage was hopelessly outdated)
http://bugs.gentoo.org/show_bug.cgi?id=19690

I wanted to try it out :)

And also an ipv6calc one - but that got in after Guy Martin fixed a
small problem :)

But I haven't gotten any feedback on the rest of the ebuilds :(

Is there no interest in these? 

-- 
Regards,
Klavs Klavsen, GSEC - kl@vsen.dk - http://www.vsen.dk

Working with Unix is like wrestling a worthy opponent. 
Working with windows is like attacking a small whining child 
who is carrying a .38.				

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Ebuilds not getting in :(

[Frantz Dhin]

I feel your pain. Usually it takes several weeks before the ebuild
updates I submit get accepted, and if at all, they usually they get
accepted unaltered, which makes those weeks a waste of time.

I wish stuff could get into the unstable branch of Gentoo much easier. I
would like to see some people with freedom to roam the tree accept
things into unstable, and not have everything depend on if a branch
maintainer has time or interest currently or not. Gentoo is supposed to
be bleeding edge, but fact is that 30-35% of the packages in portage
tree are at least one version behind. A too large share of developer
resources external to the official gentoo developer team remains largely
unused. 

A distribution that prides itself by being flexible and bleeding edge
should also have smooth and flexible policies. For insight into where
bureaucratic policies brings a distribution refer to Debian.

A few people are undoubtedly going to take offence at this, but my main
point is that gentoo needs to accept contributions from outside easier.
There is nothing that is more likely to scare a contributor away than
this frustration and feeling that you actually have to fight for
acceptance of even trivial contributions. I feel that this is one of the
reasons that we have an unstable branch, or maybe we could make a new
keyword? x86 for stable, ~x86 for unstable, and ^x86 for lunatic? :) 

The tree maintainers finest and most important task, as I see it, is
making an educated decision about when to change keywording of ebuilds.
This is the major responsibility since servers are likely to be running
Stable and must not get hosed, and users running Unstable on their
desktop pretty much know that things will break from time to time.

Regards
Frantz Dhin


On Tue, 2003-04-22 at 09:38, Klavs Klavsen wrote:
> Hi guys,
> 
> I have written these ebuilds:
> 
> vserver-0.22
> http://bugs.gentoo.org/show_bug.cgi?id=19230
> 
> Created because a costumer of mine wanted me to install Gentoo with
> vserver. I've also talked to a guy named Georges Tooth about making an
> ebuild that installs a base vserver (aka. skel vserver) that mangles the
> init-system as needed (it needs to be pretty mangled - to work perfectly
> and not do anything that requires capabilities as these are removed
> under vserver :)
> 
> USAGI-ipv6 tools (the ipv6 impl. in linux-2.5 and in gentoo-sources)
> http://bugs.gentoo.org/show_bug.cgi?id=17681
> 
> I use IPv6 - so I needed the tools.
> 
> drip-0.9.0cvs3 (the one in portage was hopelessly outdated)
> http://bugs.gentoo.org/show_bug.cgi?id=19690
> 
> I wanted to try it out :)
> 
> And also an ipv6calc one - but that got in after Guy Martin fixed a
> small problem :)
> 
> But I haven't gotten any feedback on the rest of the ebuilds :(
> 
> Is there no interest in these? 


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Ragnar Hojland Espinosa]

On Tue, Apr 22, 2003 at 02:59:30PM +0200, Frantz Dhin wrote:
> I feel your pain. Usually it takes several weeks before the ebuild
> updates I submit get accepted, and if at all, they usually they get
> accepted unaltered, which makes those weeks a waste of time.
> 
> I wish stuff could get into the unstable branch of Gentoo much easier. I
> would like to see some people with freedom to roam the tree accept
> things into unstable, and not have everything depend on if a branch
> maintainer has time or interest currently or not. Gentoo is supposed to
> be bleeding edge, but fact is that 30-35% of the packages in portage
> tree are at least one version behind. A too large share of developer
> resources external to the official gentoo developer team remains largely
> unused. 

I'll add a "me too", it feels like getting a patch inside the kernel and
I've given up on submitting new things until the (at least precieved)
situation improves.

It cant be testing what takes so long.. you just have to see the masked -
unmasked - ooops masked again dances or things that just dont compile
avi-xmms or broken sandbox ebuilds like metakit.

I'm not blaming anyone, it's just that I would had never expected would have
to use stow to keep up to date with gentoo. :/

-- 
Ragnar Hojland - Project Manager
Linalco "Especialistas Linux y en Software Libre"
http://www.linalco.com Tel: +34-91-5970074 Fax: +34-91-5970083

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Peter Ruskin]

On Tuesday 22 Apr 2003 13:59, Frantz Dhin wrote:
> A few people are undoubtedly going to take offence at this, but my main
> point is that gentoo needs to accept contributions from outside easier.
> There is nothing that is more likely to scare a contributor away than
> this frustration and feeling that you actually have to fight for
> acceptance of even trivial contributions. I feel that this is one of
> the reasons that we have an unstable branch, or maybe we could make a
> new keyword? x86 for stable, ~x86 for unstable, and ^x86 for lunatic?
> :)

I couldn't agree more!

Perhaps cx86 for contributors' ebuilds?

My ebuilds (#13452 and #14205) were submitted in January.

Peter
-- 
Gentoo-1.4.2.8 Stable. KDE: 3.1.1a Qt: 3.1.2
AMD Athlon(tm) XP 2200+ 768MB.	Kernel: 2.4.20-xfs-r2.	GCC 3.2.2


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[FRLinux]

Adding my 2 cents, i submitted a couple of ebuilds and most of them didn't 
make it through.

Steph

On Tuesday 22 April 2003 14:17, Peter Ruskin wrote:
> On Tuesday 22 Apr 2003 13:59, Frantz Dhin wrote:
> I couldn't agree more!
>
> Perhaps cx86 for contributors' ebuilds?
>
> My ebuilds (#13452 and #14205) were submitted in January.
>
> Peter

-- 

frlinux@frlinux.net - http://frlinux.net
"Piece by piece, the penguins are taking my sanity apart ..."
http://gentoofr.org - Portail de news Francophone sur Gentoo
Email sent on Debian sid k2420

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Klavs Klavsen]

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

On Tue, 2003-04-22 at 15:24, FRLinux wrote:
> Adding my 2 cents, i submitted a couple of ebuilds and most of them didn't 
> make it through.
> 

Why? I can't see why ebuilds should not get in. afterall if people don't
want it - don't emerge it. But if just one person wants the ebuild it
should be added IMHO. It's a Community Distribution, right?

Perhaps a dev (existing or new) should be assigned the right to add
ebuilds to the tree? so he or she's only task should be to accept/create
new ebuilds for programs that aren't there already - and updates for
existing ones which doesn't have a maintainer?

-- 
Regards,
Klavs Klavsen, GSEC - kl@vsen.dk - http://www.vsen.dk

Working with Unix is like wrestling a worthy opponent. 
Working with windows is like attacking a small whining child 
who is carrying a .38.				

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Ebuilds not getting in :(

[Ragnar Hojland Espinosa]

On Tue, Apr 22, 2003 at 02:17:46PM +0100, Peter Ruskin wrote:
> I couldn't agree more!
> 
> Perhaps cx86 for contributors' ebuilds?

That sounds like a good idea.  contributor / community ebuilds.   We can
wait and see if we can get some input from official devs on the situation
and then determine our course of action.

> My ebuilds (#13452 and #14205) were submitted in January.

My last ones are already obsoleted by another stable release ;)

-- 
Ragnar Hojland - Project Manager
Linalco "Especialistas Linux y en Software Libre"
http://www.linalco.com Tel: +34-91-5970074 Fax: +34-91-5970083

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Jon Portnoy]

On Tue, Apr 22, 2003 at 03:50:07PM +0200, Ragnar Hojland Espinosa wrote:
> On Tue, Apr 22, 2003 at 02:17:46PM +0100, Peter Ruskin wrote:
> > I couldn't agree more!
> > 
> > Perhaps cx86 for contributors' ebuilds?
> 
> That sounds like a good idea.  contributor / community ebuilds.   We can
> wait and see if we can get some input from official devs on the situation
> and then determine our course of action.
> 
> > My ebuilds (#13452 and #14205) were submitted in January.
> 
> My last ones are already obsoleted by another stable release ;)
> 
> -- 
> Ragnar Hojland - Project Manager
> Linalco "Especialistas Linux y en Software Libre"
> http://www.linalco.com Tel: +34-91-5970074 Fax: +34-91-5970083
> 
> --
> gentoo-dev@gentoo.org mailing list

The problem is that in order to make intelligent commit decisions, you 
need to understand the ebuild and (likely) the program.

There are some proposals being discussed internally to help deal with 
the ebuild update situation. Let's see where those take us before we try 
other approaches.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Brad Laue]

Peter Ruskin wrote:
> 
> I couldn't agree more!
> 
> Perhaps cx86 for contributors' ebuilds?

Good lord. It's bad enough x86 and ~x86 exist to bog down the works :P

Brad

-- 
// -- http://www.BRAD-X.com/ -- //


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Peter Ruskin]

On Tuesday 22 Apr 2003 14:17, Peter Ruskin wrote:
> My ebuilds (#13452 and #14205) were submitted in January.

Yippee!!   #13452 is committed.  Thanks Gentoo.

Peter
-- 
Gentoo-1.4.2.8 Stable. KDE: 3.1.1a Qt: 3.1.2
AMD Athlon(tm) XP 2200+ 768MB.	Kernel: 2.4.20-xfs-r2.	GCC 3.2.2


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 348 bytes --]

On Wednesday 23 April 2003 17:25, Peter Ruskin wrote:
> On Tuesday 22 Apr 2003 14:17, Peter Ruskin wrote:
> > My ebuilds (#13452 and #14205) were submitted in January.
>
> Yippee!!   #13452 is committed.  Thanks Gentoo.
>

You're welcome

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Ebuilds not getting in :(

[Dan Armak]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2313 bytes --]

On Tuesday 22 April 2003 15:59, Frantz Dhin wrote:
> I feel that this is one of the
> reasons that we have an unstable branch, or maybe we could make a new
> keyword? x86 for stable, ~x86 for unstable, and ^x86 for lunatic? :) 

Just a quick note (without addressing your main point). ~arch is _not_ 
"unstable". It is not supposed to be unstable in the literal meaning of the 
word. It is 'testing', or 'works for me'. Developers can _not_ commit things, 
or leave things, unmasked in ~x86 that have known issues, or that are 
alpha-quality releases from upstream. (This doesn't apply directly to what 
you were saying, I just don't like to see it called unstable...)

----

Now to the main issue. The main reason why submitted ebuilds aren't getting 
into portage easily and quckly is not the need for testing before committing. 
It is that the person committing that ebuild, or _some_ other developer, will 
have to maintain it later on. That means being responsible for problems with 
it (and there are always some problems eventually), and processing future 
updates/bureports/feature requests etc.

These require that developer to be well acquianted with the ebuild. If the app 
is nontrivial, and there are several such under this developer's care, it can 
get quite troublesome. And remember this developer generally does not use 
these apps himself - or he would have added an ebuild without waiting for a 
user submission.

The points you and other people make in this thread are known and acknowledged 
by us. We are busily working towards a setup that solves these problems. The 
first step is the upcoming (I hope) reorganization of the gentoo internal 
development model so that every ebuild has explicit maintainer(s). The second 
will facilitate quick acceptance of user-submitted ebuilds in some way - 
probably drawing upon the submitters in one way or another.

The implementation of this second step depends (imo) on the first, which is 
being busily discussed for the past week. Please give us time to put it into 
place before we move into the second phase, which is when user opinions/ideas 
will be heard properly.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://cvs.gentoo.org/~danarmak/danarmak-gpg-public.key

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

Re: [gentoo-dev] Ebuilds not getting in :(

[Peter Ruskin]

On Tuesday 22 Apr 2003 15:26, Dan Armak wrote:
>  The second will facilitate quick acceptance of user-submitted ebuilds
> in some way - probably drawing upon the submitters in one way or
> another.

I'm more than willing to maintain ebuilds I submit.

Peter
-- 
Gentoo-1.4.2.8 Stable. KDE: 3.1.1a Qt: 3.1.2
AMD Athlon(tm) XP 2200+ 768MB.	Kernel: 2.4.20-xfs-r2.	GCC 3.2.2


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Tony Clark]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 22 April 2003 16.57, Peter Ruskin wrote:
> On Tuesday 22 Apr 2003 15:26, Dan Armak wrote:
> >  The second will facilitate quick acceptance of user-submitted ebuilds
> > in some way - probably drawing upon the submitters in one way or
> > another.
>
> I'm more than willing to maintain ebuilds I submit.

ditto
- -- 
Contract ASIC and FPGA design.
Telephone +46 702 894 667
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x633E2623

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iQCVAwUBPqViaWkjRGZD9pCjAQK31AP7BGHAbIUwNV9Edqe4griyPbzrnSfqsbAh
M/UBbrLhP1pSDWyyDEY88H4AxdtOZrwy4kCHwbFdnXlVYX8zjMrCT5Y3jptAtd0K
aM4id+k+4uhrnEaXULyUsQzf2KhK1DvCo7wIYfulSKmqXWJ4P/sz+zF745hrLO4H
+tX8Agbgn0Q=
=i8Rx
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Ragnar Hojland Espinosa]

On Tue, Apr 22, 2003 at 05:40:19PM +0200, Tony Clark wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Tuesday 22 April 2003 16.57, Peter Ruskin wrote:
> > On Tuesday 22 Apr 2003 15:26, Dan Armak wrote:
> > >  The second will facilitate quick acceptance of user-submitted ebuilds
> > > in some way - probably drawing upon the submitters in one way or
> > > another.
> >
> > I'm more than willing to maintain ebuilds I submit.
> 
> ditto

And so am I, and I'm sure a good number of people who submit ebuilds would
be willing to too.

-- 
Ragnar Hojland - Project Manager
Linalco "Especialistas Linux y en Software Libre"
http://www.linalco.com Tel: +34-91-5970074 Fax: +34-91-5970083

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Klavs Klavsen]

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

On Tue, 2003-04-22 at 16:57, Peter Ruskin wrote:
> On Tuesday 22 Apr 2003 15:26, Dan Armak wrote:
> >  The second will facilitate quick acceptance of user-submitted ebuilds
> > in some way - probably drawing upon the submitters in one way or
> > another.
> 
> I'm more than willing to maintain ebuilds I submit.
> 

Same here. What are the requirements for being a maintainer?
I don't think one has to make the newest version available ASAP.
This f.ex. didn't happen with drip - which was why I created a new
version myself.

I think people who submit ebuilds should automacally be added as
maintainer of the ebuild. If they contribute with a newer version of a
given ebuild - then they should be added as maintainer - keeping the old
maintainer too. 

It's a Community distro and I don't think anyone will mind - as long as
it's all build on volutarity - ie. make a newer version if you like -
don't if you don't.
-- 
Regards,
Klavs Klavsen, GSEC - kl@vsen.dk - http://www.vsen.dk

Working with Unix is like wrestling a worthy opponent. 
Working with windows is like attacking a small whining child 
who is carrying a .38.				

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Ebuilds not getting in :(

[Tony Clark]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 22 April 2003 18.00, Klavs Klavsen wrote:
> On Tue, 2003-04-22 at 16:57, Peter Ruskin wrote:
> > On Tuesday 22 Apr 2003 15:26, Dan Armak wrote:
> > >  The second will facilitate quick acceptance of user-submitted ebuilds
> > > in some way - probably drawing upon the submitters in one way or
> > > another.
> >
> > I'm more than willing to maintain ebuilds I submit.
>
> Same here. What are the requirements for being a maintainer?
> I don't think one has to make the newest version available ASAP.
> This f.ex. didn't happen with drip - which was why I created a new
> version myself.
>
> I think people who submit ebuilds should automacally be added as
> maintainer of the ebuild. If they contribute with a newer version of a
> given ebuild - then they should be added as maintainer - keeping the old
> maintainer too.

Not too sure I agree with this.  You need people to take some sort of 
ownership of the problem.  If things don't get done then you can look at 
replacing them.

>
> It's a Community distro and I don't think anyone will mind - as long as
> it's all build on volutarity - ie. make a newer version if you like -
> don't if you don't.
You would be surprised.  I lot of ppl take a lot of pride in what they do and 
would feel very walked over if someone was just added to maintain a package 
because they where on, say holidays for a week and a new release came out.

tony
- -- 
Contract ASIC and FPGA design.
Telephone +46 702 894 667
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x633E2623

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iQCVAwUBPqVqZ2kjRGZD9pCjAQK7EQQAnOEVIBrKSZm2HiXMgb6xsev/VnUY7X3o
/eWQO0KIiqmtvpQCH9bmd1LEu+UjFpC93rGTmrM/tK4LA4QoKHNC/gV/uhh7yNGf
MCvRqJ30cMK/qJgjBhe7C7NE59eWJ2MF4OQsQK6G3YvtjIZq9SJt1z3mBw6VS/zz
IEzSXymeOl8=
=6XyB
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[William Hubbs]

Hi all,

I agree here.  If there is a maintainer for an ebuild, anyone who wants another version of the ebuild in the system should be able to send it to the maintainer for the ebuild or file a bug that should be assigned to the maintainer.  Otherwise things would get really confusing.

William

On Tue, Apr 22, 2003 at 06:14:31PM +0200, Tony Clark wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Tuesday 22 April 2003 18.00, Klavs Klavsen wrote:
> > On Tue, 2003-04-22 at 16:57, Peter Ruskin wrote:
> > > On Tuesday 22 Apr 2003 15:26, Dan Armak wrote:
> > > >  The second will facilitate quick acceptance of user-submitted ebuilds
> > > > in some way - probably drawing upon the submitters in one way or
> > > > another.
> > >
> > > I'm more than willing to maintain ebuilds I submit.
> >
> > Same here. What are the requirements for being a maintainer?
> > I don't think one has to make the newest version available ASAP.
> > This f.ex. didn't happen with drip - which was why I created a new
> > version myself.
> >
> > I think people who submit ebuilds should automacally be added as
> > maintainer of the ebuild. If they contribute with a newer version of a
> > given ebuild - then they should be added as maintainer - keeping the old
> > maintainer too.
> 
> Not too sure I agree with this.  You need people to take some sort of 
> ownership of the problem.  If things don't get done then you can look at 
> replacing them.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Jon Portnoy]

On Tue, Apr 22, 2003 at 06:00:09PM +0200, Klavs Klavsen wrote:
> On Tue, 2003-04-22 at 16:57, Peter Ruskin wrote:
> > On Tuesday 22 Apr 2003 15:26, Dan Armak wrote:
> > >  The second will facilitate quick acceptance of user-submitted ebuilds
> > > in some way - probably drawing upon the submitters in one way or
> > > another.
> > 
> > I'm more than willing to maintain ebuilds I submit.
> > 
> 
> Same here. What are the requirements for being a maintainer?
> I don't think one has to make the newest version available ASAP.
> This f.ex. didn't happen with drip - which was why I created a new
> version myself.
> 
> I think people who submit ebuilds should automacally be added as
> maintainer of the ebuild. If they contribute with a newer version of a
> given ebuild - then they should be added as maintainer - keeping the old
> maintainer too. 
> 
> It's a Community distro and I don't think anyone will mind - as long as
> it's all build on volutarity - ie. make a newer version if you like -
> don't if you don't.

The problem is that we can't just give everyone who submits an ebuild or 
two commit access.

We are, however, stepping up recruiting somewhat with a recruiting email 
address. There are also ideas floating around for ways to make it easier 
for users to get ebuilds into the tree quicker.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Mark Bainter]

Jon Portnoy [avenj@gentoo.org] wrote:
> The problem is that we can't just give everyone who submits an ebuild or 
> two commit access.
> 
> We are, however, stepping up recruiting somewhat with a recruiting email 
> address. There are also ideas floating around for ways to make it easier 
> for users to get ebuilds into the tree quicker.

I don't disagree with this.  You might consider letting them still be a
maintainer though, and just have people who are new maintainers pass 
their changes through a more seasoned member of the community until they
have a few releases under their belt, or whatever criteria the devs think
demonstrates the level of trust necessary to give them commit access to
their ebuilds.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Klavs Klavsen]

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

On Tue, 2003-04-22 at 19:55, Mark Bainter wrote:
> Jon Portnoy [avenj@gentoo.org] wrote:
> > The problem is that we can't just give everyone who submits an ebuild or 
> > two commit access.
> > 
> > We are, however, stepping up recruiting somewhat with a recruiting email 
> > address. There are also ideas floating around for ways to make it easier 
> > for users to get ebuilds into the tree quicker.
> 
> I don't disagree with this.  You might consider letting them still be a
> maintainer though, and just have people who are new maintainers pass 
> their changes through a more seasoned member of the community until they
> have a few releases under their belt, or whatever criteria the devs think
> demonstrates the level of trust necessary to give them commit access to
> their ebuilds.

See this sounds like a good idea. I ofcourse don't want the current
maintainer to feel dumped because someone else makes an ebuild for the
newest version of a program.

Perhaps something like a Primary - and secondary ebuild maintainers
could be established?

-- 
Regards,
Klavs Klavsen, GSEC - kl@vsen.dk - http://www.vsen.dk

Working with Unix is like wrestling a worthy opponent. 
Working with windows is like attacking a small whining child 
who is carrying a .38.				

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Ebuilds not getting in :(

[Jon Portnoy]

On Tue, Apr 22, 2003 at 08:00:12PM +0200, Klavs Klavsen wrote:
> On Tue, 2003-04-22 at 19:55, Mark Bainter wrote:
> > Jon Portnoy [avenj@gentoo.org] wrote:
> > > The problem is that we can't just give everyone who submits an ebuild or 
> > > two commit access.
> > > 
> > > We are, however, stepping up recruiting somewhat with a recruiting email 
> > > address. There are also ideas floating around for ways to make it easier 
> > > for users to get ebuilds into the tree quicker.
> > 
> > I don't disagree with this.  You might consider letting them still be a
> > maintainer though, and just have people who are new maintainers pass 
> > their changes through a more seasoned member of the community until they
> > have a few releases under their belt, or whatever criteria the devs think
> > demonstrates the level of trust necessary to give them commit access to
> > their ebuilds.
> 
> See this sounds like a good idea. I ofcourse don't want the current
> maintainer to feel dumped because someone else makes an ebuild for the
> newest version of a program.
> 
> Perhaps something like a Primary - and secondary ebuild maintainers
> could be established?
> 


Something similar is in the works as part of the maintainers for ebuilds 
thing. Nothing has been absolutely decided on yet, so it's premature to 
offer details and get people's hopes up, but hopefully the new system 
will provide for a better way to keep track of ebuild updates and figure 
out what ebuilds need new maintainers, allowing us to recruit new 
developers to maintain ebuilds in an intelligent and systematic fashion. 

In short: good things are coming (hopefully) :-)

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Brad Laue]

Dan Armak wrote:
> Just a quick note (without addressing your main point). ~arch is _not_ 
> "unstable". It is not supposed to be unstable in the literal meaning of the 
> word. It is 'testing', or 'works for me'. Developers can _not_ commit things, 
> or leave things, unmasked in ~x86 that have known issues, or that are 
> alpha-quality releases from upstream. (This doesn't apply directly to what 
> you were saying, I just don't like to see it called unstable...)

Okay, it seems to me that squid 2.5 and apache 2.0 don't belong in the 
~x86 keyword then; I had considered this okay under the mistaken 
impression that this was an 'unstable' rather than a testing branch.

Apache and squid's devel versions should be slotted, masked or placed in 
their own ebuilds, by the sounds of what you're saying. Agreed?

Brad

-- 
// -- http://www.BRAD-X.com/ -- //


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[foser]

Brad Laue wrote:
> 
> Okay, it seems to me that squid 2.5 and apache 2.0 don't belong in the 
> ~x86 keyword then; I had considered this okay under the mistaken 
> impression that this was an 'unstable' rather than a testing branch.
> 
> Apache and squid's devel versions should be slotted, masked or placed in 
> their own ebuilds, by the sounds of what you're saying. Agreed?

Apache-2.* is slotted and afaik stable enough to be used, so it doesn't
need to be masked (it can be ~ ofcourse). Squid 2.5 is considered the
current stable version. By the sound of what Dan is saying, they are 
correct in the tree.

- foser



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Brad Laue]

foser wrote:
> Apache-2.* is slotted and afaik stable enough to be used, so it doesn't
> need to be masked (it can be ~ ofcourse). Squid 2.5 is considered the
> current stable version. By the sound of what Dan is saying, they are 
> correct in the tree.

Oops, you're right about squid.

About apache though, 2.0.45 is presented as the latest available version 
in portage when using the ~x86 keyword, whereas 1.3.27 is present when 
one uses the x86 keyword.

Is this a coincidence, in that 2.x will be marked stable at some point 
and all keywords will report it as the latest available version, in the 
same way apache.org recommends?

Brad

-- 
// -- http://www.BRAD-X.com/ -- //


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[foser]

Brad Laue wrote:
> About apache though, 2.0.45 is presented as the latest available version 
> in portage when using the ~x86 keyword, whereas 1.3.27 is present when 
> one uses the x86 keyword.
> 
> Is this a coincidence, in that 2.x will be marked stable at some point 
> and all keywords will report it as the latest available version, in the 
> same way apache.org recommends?

Well yeah sorta, it's just the way portage works : get the latest stable 
version available (that also means the highest slot most likely). If you 
want the latest 1.x version just do 'emerge =apache-1* -p' or something 
similar. In time it would probably be a nice feature to give a slot 
number with the emerge command or something.

But this isn't really -dev worthy traffic ;)

- foser


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Fredrik Jagenheim]

On Tue, Apr 22, 2003 at 02:59:30PM +0200, Frantz Dhin wrote:
> A distribution that prides itself by being flexible and bleeding edge
> should also have smooth and flexible policies. For insight into where
> bureaucratic policies brings a distribution refer to Debian.

While I understand the frustration in not getting feedback on work
put down, there's always PORTDIR_OVERLAY. If someone, apart from you,
have a need for the latest, greatest version of the package they can
always download the ebuild from bugs.gentoo.org and put it locally.

I guess some enterprising person with some time on their hands always
can do a hack which will keep your PORTDIR_OVERLAY synced to
bugs.gentoo.org.

Anyways, I don't think the problem stems from ebuilds not being
commited to CVS fast enough, but the complete lack of feedback from
developers what happens to bugs/ebuilds/fixes that is entered to
bugs.gentoo.org. I know developers are busy, but a simple acknowledge
from the assigned developer of the status would help calm down the
commiters. As of now, many times all what happens to the bug-entry is
that you see it gets assigned and then silence...

I have personally spent a couple of evenings tracking down long
standing bugs and belived that I have reached some sort of solution on
them. But since I haven't heard any feedback I'm not sure if someone
cares, my fixes were so wrong they didn't even deserve a mention or
there is a better fix...

Yeah, I know. I spent the first half of this letter telling you that
your problem was non-existant, and then spending the other half
ranting on my problems as if they were the end of the world. Have
mercy on me, I've had a rough day. ;)

//H

-- 
To segfault is human; to bluescreen moronic. 

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Fernand Albarracin]

Hi,

On Tue 22 Apr 2003 at 21:11:00 +0200, Fredrik Jagenheim wrote:

> I have personally spent a couple of evenings tracking down long
> standing bugs and belived that I have reached some sort of solution on
> them. But since I haven't heard any feedback I'm not sure if someone
> cares, my fixes were so wrong they didn't even deserve a mention or
> there is a better fix...
> 
> Yeah, I know. I spent the first half of this letter telling you that
> your problem was non-existant, and then spending the other half
> ranting on my problems as if they were the end of the world. Have
> mercy on me, I've had a rough day. ;)

Well, I think you provided a pretty good sumary of the situation. Many
contributors (or potential ones) may have hit this very same problem.
One can easilly feel on the frustration on these ML and on the BTS. It's
all about communication. Hopefully things are getting better as Dan's
mail suggests.

I have a lot of respect for the Debian people. They addressed these
infrastructure issues a long time ago. There developpement process
really scales well. Few organisations have so much manpower focused on
the same goals. And it is still quite easy to reach them. Impressive.

In Gentoo land, I have the impression that things have dramatically
improved since the beginning of the year quality wise. Now,
developpement getting more open ? Good !

	"If there is anything that a man can do well, I say let him do
	it. Give him a chance." -- Abraham Lincoln

	"Responsibility is the thing people dread most of all. Yet it
	is the one thing the world that develops us." -- Crane, Frank

Soon, you'll get hundreds of people this way. Go Gentoo, go! :-)

Fernand

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Brian Jackson]

I having been saying I was going to do this for a while, but I guess this will 
actually get me started. I am going to start trying to keep a tarball of 
experimental ebuilds maintained so people can frequently download it and 
extract. I have a pretty good collection here locally anyways. If anybody has 
any ebuilds they want me to add to it send them to me, or send links to the 
bug reports where I can find them(just send them to me the list doesn't need 
the traffic), I am going to try to get everything put together today. This 
might evolve into something else, but for now I am just going to keep it up 
to date locally. I will post here again later with a link to the download.

--Brian Jackson


On Tuesday 22 April 2003 02:38 am, Klavs Klavsen wrote:
> Hi guys,
>
> I have written these ebuilds:
>
> vserver-0.22
> http://bugs.gentoo.org/show_bug.cgi?id=19230
>
> Created because a costumer of mine wanted me to install Gentoo with
> vserver. I've also talked to a guy named Georges Tooth about making an
> ebuild that installs a base vserver (aka. skel vserver) that mangles the
> init-system as needed (it needs to be pretty mangled - to work perfectly
> and not do anything that requires capabilities as these are removed
> under vserver :)
>
> USAGI-ipv6 tools (the ipv6 impl. in linux-2.5 and in gentoo-sources)
> http://bugs.gentoo.org/show_bug.cgi?id=17681
>
> I use IPv6 - so I needed the tools.
>
> drip-0.9.0cvs3 (the one in portage was hopelessly outdated)
> http://bugs.gentoo.org/show_bug.cgi?id=19690
>
> I wanted to try it out :)
>
> And also an ipv6calc one - but that got in after Guy Martin fixed a
> small problem :)
>
> But I haven't gotten any feedback on the rest of the ebuilds :(
>
> Is there no interest in these?

-- 
OpenGFS -- http://opengfs.sourceforge.net
Home -- http://www.brianandsara.net/brian

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Brian Jackson]

Nobody showed an interest, but here it is anyway:

http://www.mdrx.com/brian/portage-local.tar.bz2

There could be a lot more stuff there, and if anybody shows any interest, I 
will probably try to setup an rsync server for people to pull from instead of 
having to download and extract.

--Brian

On Tuesday 22 April 2003 10:57 am, Brian Jackson wrote:
> I having been saying I was going to do this for a while, but I guess this
> will actually get me started. I am going to start trying to keep a tarball
> of experimental ebuilds maintained so people can frequently download it and
> extract. I have a pretty good collection here locally anyways. If anybody
> has any ebuilds they want me to add to it send them to me, or send links to
> the bug reports where I can find them(just send them to me the list doesn't
> need the traffic), I am going to try to get everything put together today.
> This might evolve into something else, but for now I am just going to keep
> it up to date locally. I will post here again later with a link to the
> download.
>
> --Brian Jackson
>
<snip>

-- 
OpenGFS -- http://opengfs.sourceforge.net
Home -- http://www.brianandsara.net/brian

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Robin H.Johnson]

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

On Tue, Apr 22, 2003 at 05:07:22PM -0500, Brian Jackson wrote:
> Nobody showed an interest, but here it is anyway:
> http://www.mdrx.com/brian/portage-local.tar.bz2
> There could be a lot more stuff there, and if anybody shows any interest, I 
> will probably try to setup an rsync server for people to pull from instead of 
> having to download and extract.
I think this is actually a great idea for now, as an extra testing
ground for some of the ebuilds.

As a developer, I do occasionally merge a number of minor ebuilds that I
need myself and are just sitting in the bugzilla tree, and then I keep
an eye on them.

The since most discougaging thing in any submitted ebuild is the lack of
an included ChangeLog. To anybody submitting an ebuild, use
skel.ChangeLog, and fill it out with the correct information.
Additionally, for many of your ebuilds, in your posting about the bug
specify what you did and why. It saves us a lot of trouble in 
testing the ebuild. Also make sure that your ebuild installs ALL of the
documentation that is distributed with the source package. Take a look
at /usr/share/doc and see how comprehensive some packages are in this
regard. Don't forget the manpages either (a fairly common mistake).

If you have a question about how to do something in an ebuild, look at
other ebuilds or ask on this mailing list.

If there is an ebuild that is totally ready to go out (eg I _could_ just
dump the files into a new directory and check them in. I don't for
security and QA reasons) of the box, it
greatly increases the chance that it will get into the tree quickly.
Very few submitted ebuilds come up to this level. I will admit that it
is a lot to ask for, but it really makes life as a developer much
easier.

Personally, for any ebuild I am willing to pick up, I generally do the
following:
0. read the submitted ebuild AND changelog
1. grab the source tarball
2. read the included documentation
3. read the documentation on the web and other information I can find
about it
4. re-read the included documentation
5a. attempt to compile it only inside a sandbox enviroment
5b. if problems from 5a, look at some of the source code/ebuild to
figure out why
6. see what 'make install' or the other standard methods of install
WOULD install and compare that to the ebuild install instructions.
7. install it on a testbed system and do some simplistic functionality
and security (trojaning) checks
8. install it on 3-5 other systems with widely varying configurations to
see if it installs cleanly in most cases.
9. commit to CVS

Generally this process is spread anywhere between 6 hours and a week
long, depending on package complexity and how busy I am with
work/school and my other open source work (I'm a developer on
phpMyAdmin).

19 times of of 20, if a submitted ebuild is more complex than
emake/einstall and doesn't include a changelog or some detailed comments
inside the ebuild as to what is being done, then I don't touch it.

Definetly having more developers/maintainers would help, but there are
many issues around this (as people have pointed out in the thread).
Debian's "solution" to many of the problems was a dedicated maintainer
for each package, and only a few packages per maintainer to keep things
managable, but that requires a LOT of maintiners/developers. There are
some changes under discussion for Gentoo on this presently, but I won't
say more now, as not to get people's hopes up for the outcome as it
could change a lot.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

Re: [gentoo-dev] Ebuilds not getting in :(

[Mark Gordon]

On Tue, 22 Apr 2003 15:36:55 -0700
Robin H.Johnson <robbat2@gentoo.org> wrote:

> On Tue, Apr 22, 2003 at 05:07:22PM -0500, Brian Jackson wrote:
> > Nobody showed an interest, but here it is anyway:
> > http://www.mdrx.com/brian/portage-local.tar.bz2
> > There could be a lot more stuff there, and if anybody shows any
> > interest, I will probably try to setup an rsync server for people to
> > pull from instead of having to download and extract.
> I think this is actually a great idea for now, as an extra testing
> ground for some of the ebuilds.

If it stays reasonably up to date with bugzilla this could be very
useful. Personally I would not trust any ebuilds in it without manually
checking them since, no offence to Brian, but I don't know him. However,
checking a local synced copy of it would be much faster than checking
bugzilla.

> As a developer, I do occasionally merge a number of minor ebuilds that
> I need myself and are just sitting in the bugzilla tree, and then I
> keep an eye on them.
> 
> The since most discougaging thing in any submitted ebuild is the lack
> of an included ChangeLog. To anybody submitting an ebuild, use
> skel.ChangeLog, and fill it out with the correct information.
> Additionally, for many of your ebuilds, in your posting about the bug
> specify what you did and why. It saves us a lot of trouble in 
> testing the ebuild. Also make sure that your ebuild installs ALL of
> the documentation that is distributed with the source package. Take a
> look at /usr/share/doc and see how comprehensive some packages are in
> this regard. Don't forget the manpages either (a fairly common
> mistake).

Also, I would think that if you are submitting an ebuild for a new
package including a summary of what it is and why it is useful (keep it
short) since then a developer is more likely on seeing it to say, "Wow,
I want that," and get it in to the tree.

If an update to an existing ebuild for a new package version fixes a
major problem, mention that briefly rather than just submitting it to
bugzilla as a version bump.

> If you have a question about how to do something in an ebuild, look at
> other ebuilds or ask on this mailing list.
> 
> If there is an ebuild that is totally ready to go out (eg I _could_
> just dump the files into a new directory and check them in. I don't
> for security and QA reasons) of the box, it
> greatly increases the chance that it will get into the tree quickly.
> Very few submitted ebuilds come up to this level. I will admit that it
> is a lot to ask for, but it really makes life as a developer much
> easier.
> 
> Personally, for any ebuild I am willing to pick up, I generally do the
> following:
> 0. read the submitted ebuild AND changelog
> 1. grab the source tarball
> 2. read the included documentation
> 3. read the documentation on the web and other information I can find
> about it
> 4. re-read the included documentation
> 5a. attempt to compile it only inside a sandbox enviroment
> 5b. if problems from 5a, look at some of the source code/ebuild to
> figure out why
> 6. see what 'make install' or the other standard methods of install
> WOULD install and compare that to the ebuild install instructions.
> 7. install it on a testbed system and do some simplistic functionality
> and security (trojaning) checks

Check dependencies are correct? :-)

> 8. install it on 3-5 other systems with widely varying configurations
> to see if it installs cleanly in most cases.
> 9. commit to CVS
> 
> Generally this process is spread anywhere between 6 hours and a week
> long, depending on package complexity and how busy I am with
> work/school and my other open source work (I'm a developer on
> phpMyAdmin).

A lot of work is involved in properly checking changes submitted by a
third party, something a lot of people who have not been involved in
full change control systems often don't appreciate. The problem being
that the person authorising the change has to understand it and be able
to verify its correctness. I know because I've been the main person
responsible for this on some large closed source projects where I
personally knew all the other developers.

> 19 times of of 20, if a submitted ebuild is more complex than
> emake/einstall and doesn't include a changelog or some detailed
> comments inside the ebuild as to what is being done, then I don't
> touch it.

Don't blame you.

I've been reasonably happy because the few things I've submitted have
gone through in a reasonable time frame when the work involved is
considered.

> Definetly having more developers/maintainers would help, but there are
> many issues around this (as people have pointed out in the thread).
> Debian's "solution" to many of the problems was a dedicated maintainer
> for each package, and only a few packages per maintainer to keep
> things managable, but that requires a LOT of maintiners/developers.
> There are some changes under discussion for Gentoo on this presently,
> but I won't say more now, as not to get people's hopes up for the
> outcome as it could change a lot.

Nice to hear it, although to be fair to the other developers there have
been a few posts recently where the developers have said this so us
users really should have got the point that this is being worked on.

Once it is up and running I will probably try to spend more time
watching the packages critical to me which I expect to be less commonly
used. For now, time prohibits me from doing too much.
-- 
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Currently looking for a new job commutable from Slough, Berks, U.K.
Although my email address says spamtrap, it is real and I read it.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Jon Portnoy]

On Wed, Apr 23, 2003 at 08:43:41AM +0100, Mark Gordon wrote:
> On Tue, 22 Apr 2003 15:36:55 -0700
> Robin H.Johnson <robbat2@gentoo.org> wrote:
> 
[snip]
> 
> Also, I would think that if you are submitting an ebuild for a new
> package including a summary of what it is and why it is useful (keep it
> short) since then a developer is more likely on seeing it to say, "Wow,
> I want that," and get it in to the tree.
> 
> If an update to an existing ebuild for a new package version fixes a
> major problem, mention that briefly rather than just submitting it to
> bugzilla as a version bump.

Yes, this is probably the most helpful way for me to determine which 
ebuilds I want to touch when I look at the bug-wranglers list. Because I 
don't want to get stuck with the bugs later for something I don't use or 
don't have an interest in, I go through and pick up ebuilds that have a 
description that interests me. I'm sure other developers do the same. 
Additionally, it helps the bug-wranglers people decide where to assign 
those bugs.

[snip]

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Robin H.Johnson]

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

On Fri, Apr 25, 2003 at 01:46:59PM -0400, Anthony de Boer wrote:
> You wrote:
> > The since most discougaging thing in any submitted ebuild is the lack of
> > an included ChangeLog. To anybody submitting an ebuild, use
> > skel.ChangeLog, and fill it out with the correct information.
> The skel file says:
> 
>   DD MMM YYYY; YOUR_NAME <YOUR_EMAIL> changed_file1, changed_file2 :
>   Initial import.  Ebuild submitted by submitter_name <submitter_email>.
> 
> which to me implied that the developer doing the CVS commit puts his/her
> name and address in the first spot.  As the submitter who would be named
> on the second line, how would I phrase the initial ChangeLog?
The submitted changelogs that are nice just have 'INSERT_NAME' for the
developers name+address. But most developers aren't too fussed about the
name+address in the first line.

So if you were submitted it
it might be:

  25 Apr 2003; INSERT_NAME foo-0.0.1.ebuild, files/somepatch:
  Initial import. Ebuild submitted by Anthony de Boer <adb@leftmind.net>
  Other comments go here if needed about the build.

That way I just copy the ChangeLog in, change my name and I'm done.
This may make me seem very lazy, but by including a good changelog like
this in your submission, your package is more likely to get in even just
because it looks complete and you seem to have done your homework ;-).

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

Re: [gentoo-dev] Ebuilds not getting in :(

[Brian Jackson]

I know talking to myself this much in one day is bad, but I setup an rsync 
server. It is at:
rsync://www.mdrx.com/portage-local

you can run the following to check it out:
rsync -rz rsync://www.mdrx.com/portage-local .

--Brian Jackson

P.S. I will be adding more ebuilds to it as the the next few days pass, and 
remember if you have something you want me to add, just let me know where to 
get it (I will be looking through bugs.gentoo.org so if you have something 
recent there, you might want to give me a few days before letting me know)

On Tuesday 22 April 2003 05:07 pm, Brian Jackson wrote:
> Nobody showed an interest, but here it is anyway:
>
> http://www.mdrx.com/brian/portage-local.tar.bz2
>
> There could be a lot more stuff there, and if anybody shows any interest, I
> will probably try to setup an rsync server for people to pull from instead
> of having to download and extract.
>
> --Brian
>
> On Tuesday 22 April 2003 10:57 am, Brian Jackson wrote:
> > I having been saying I was going to do this for a while, but I guess this
> > will actually get me started. I am going to start trying to keep a
> > tarball of experimental ebuilds maintained so people can frequently
> > download it and extract. I have a pretty good collection here locally
> > anyways. If anybody has any ebuilds they want me to add to it send them
> > to me, or send links to the bug reports where I can find them(just send
> > them to me the list doesn't need the traffic), I am going to try to get
> > everything put together today. This might evolve into something else, but
> > for now I am just going to keep it up to date locally. I will post here
> > again later with a link to the download.
> >
> > --Brian Jackson
>
> <snip>

-- 
OpenGFS -- http://opengfs.sourceforge.net
Home -- http://www.brianandsara.net/brian

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Peter Fein]

On Tue, 22 Apr 2003 21:56:16 -0500
Brian Jackson <brian@mdrx.com> wrote:

> I know talking to myself this much in one day is bad, but I setup an rsync 
> server. It is at:
> rsync://www.mdrx.com/portage-local
> 
> you can run the following to check it out:
> rsync -rz rsync://www.mdrx.com/portage-local .

Actually, more formal support for multiple sync sources would be *highly*
cool & would really make portage a "meta-distribution".  I could also see this
being useful for officially supported builds, as this readily solves the "I
never want to even sync anything X11" problem.

On a (barely) related extensibility note, I've found it really hard to work on
even short patches to portage/emerge.  portage.py is almost 4600 lines, emerge
is almost 1900. My point being that's a pretty good size for a single code unit
in any language, but enormous for python.  Try

find /usr/lib/python2.2/ -iname "*.py" |xargs wc -l |sort -n -r

and keep in mind that the standard modules have a lot more documentation.  And
to cut off the inevitable criticism of this metric, these modules do import each
other & use C libs.  That's my point.  The lack of modularity & the presence of
top-level code makes reuse really tough- I'd love to work on a GTK'd or web'd
emerge or 30 other scripts, but everything's so intertwined that it's not
feasible to reuse code.

More user whining, I know.  I don't quite know what I'm suggesting as a
solution, short of offering to help.

--Pete

-- 
Peter Fein
pfein@pobox.com
773-575-0694

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Grant Goodyear]

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

On Wed, 2003-04-23 at 11:27, Peter Fein wrote:
> More user whining, I know.  I don't quite know what I'm suggesting as a
> solution, short of offering to help.

In that case, you might want to e-mail carpaski@gentoo.org.  

Best,
g2boojum
-- 
Grant Goodyear <g2boojum@gentoo.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Ebuilds not getting in :(

[Brian Jackson]

Sorry if anybody tried to access this, my firewall was blocking the rsync 
port, it should be fixed now. Give it a whirl if you'd like.

--Brian

On Tuesday 22 April 2003 09:56 pm, Brian Jackson wrote:
> I know talking to myself this much in one day is bad, but I setup an rsync
> server. It is at:
> rsync://www.mdrx.com/portage-local
>
> you can run the following to check it out:
> rsync -rz rsync://www.mdrx.com/portage-local .
>
> --Brian Jackson
<snip>

-- 
OpenGFS -- http://opengfs.sourceforge.net
Home -- http://www.brianandsara.net/brian

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds not getting in :(

[Thomas Arnhold]

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

Hi Brian,

I created a different dir on my webserver, look at
http://slysoft.de/gentoo, there are some updates and some new ebuilds, I
already filled them in to bugs.gentoo.org but nothing more happens...

cu
 slyzer

On Tue, Apr 22, 2003 at 10:57:25AM -0500, Brian Jackson wrote:
> I having been saying I was going to do this for a while, but I guess this will 
> actually get me started. I am going to start trying to keep a tarball of 
> experimental ebuilds maintained so people can frequently download it and 
> extract. I have a pretty good collection here locally anyways. If anybody has 
> any ebuilds they want me to add to it send them to me, or send links to the 
> bug reports where I can find them(just send them to me the list doesn't need 
> the traffic), I am going to try to get everything put together today. This 
> might evolve into something else, but for now I am just going to keep it up 
> to date locally. I will post here again later with a link to the download.
> 
> --Brian Jackson
> 
> 
> On Tuesday 22 April 2003 02:38 am, Klavs Klavsen wrote:
> > Hi guys,
> >
> > I have written these ebuilds:
> >
> > vserver-0.22
> > http://bugs.gentoo.org/show_bug.cgi?id=19230
> >
> > Created because a costumer of mine wanted me to install Gentoo with
> > vserver. I've also talked to a guy named Georges Tooth about making an
> > ebuild that installs a base vserver (aka. skel vserver) that mangles the
> > init-system as needed (it needs to be pretty mangled - to work perfectly
> > and not do anything that requires capabilities as these are removed
> > under vserver :)
> >
> > USAGI-ipv6 tools (the ipv6 impl. in linux-2.5 and in gentoo-sources)
> > http://bugs.gentoo.org/show_bug.cgi?id=17681
> >
> > I use IPv6 - so I needed the tools.
> >
> > drip-0.9.0cvs3 (the one in portage was hopelessly outdated)
> > http://bugs.gentoo.org/show_bug.cgi?id=19690
> >
> > I wanted to try it out :)
> >
> > And also an ipv6calc one - but that got in after Guy Martin fixed a
> > small problem :)
> >
> > But I haven't gotten any feedback on the rest of the ebuilds :(
> >
> > Is there no interest in these?
> 
> -- 
> OpenGFS -- http://opengfs.sourceforge.net
> Home -- http://www.brianandsara.net/brian
> 
> --
> gentoo-dev@gentoo.org mailing list
> 

-- 
www: http://slysoft.de
mail:  mail@slysoft.de
pgp-id:     0xD92FA6E7


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