[gentoo-dev] proxy-dev (an alternative to sunrise?)

[gentoo-dev] proxy-dev (an alternative to sunrise?)

[Luis Francisco Araujo]

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

Hello everyone,

Here, with this email, i propose (after a brief discussion on irc with
gensteaf)an alternative or at least a new model to address a few issues
with our maintainers needs and the inclusion of new packages into the
tree. Probably an alternative (temporary?) as well to the sunrise
project as the subject of this email suggest.

The idea is very simple, i will generally describe it here.

In my opinion, most of the developers are usually afraid of taking care
of maintainer-{needed-wanted} packages because of the following reasons:

1 - To fix bugs of the package: this might be a very easy task, or a
whole nightmare. Many of these packages got bunch of open bugs, so, a
developer think twice before going after a package that probably he even
doesn't know what it is for, besides that, this task might become very
time-consuming , the developer might prefer to invest this time with the
packages/herd he already maintains instead.

2 - To keep track of upstream: Though it sounds as an easy task, it
might become tedious sometimes, mainly if the developer isn't interested
at all on the project, and, this is definitely, another important point
when maintaining a package.

3 - Interesting packages: Which packages should we pick? , There exist
interested users/developers to maintain/use such a package?. We don't
have an easy way to keep track of this either.

These are the main points i have personally faced when picking
maintainer-{needed,wanted} ebuilds from bugzilla. So, i am pretty much
assuming from a personal point-of-view that others developers might be
also finding these problems (sorry if it is not the case). I don't
believe we all are happy with the current status of packages in need of
maintainers, something must be happening, and i think these three points
are part of the problem.

Ok, after detecting the problem, we need to solve it right? , the idea
is to create a proxy developer structure/mechanism/model/project , where
 the developers could let all these three points at the hands of the
user wanting to get the ebuild included into the tree.

The 'modus-operandi' would go like this:

1 - We setup a mailing list (yes, yet another one, but this one is gonna
be useful!) , call it , proxy-dev@g.o , or proxy-review@g.o.

2 - Developers interested to serve as a proxy , subscribe to the list.

3 - Users ask on this mailing list if there exist any developer
interested to include X, or Y ebuild into the tree. (Probably we could
create a template for this?)

4 - An interested developer says 'yes' on the list (so the rest of devel
can see him too) , and from there on, the developer and the user work
off-list.
   Or a developer can say 'no'. Explaining the reason (if any) of why
this ebuild shouldn't be included into the tree.
   I think this would be solving some bugzilla communication annoyances,
and opening the doors of another 'feedback' way between developers and
users.

This is pretty much the general behaviour , simple right?

Now .. most of you must already be thinking, "well .. isn't this the
same that going and picking maintainer-wanted ebuilds after all?"

Here it comes the trick or 'trap' ;-)

The user _has_ to compromise to take care of those previous commented
three points that some of us might be afraid of, besides of giving us a
centralized way of keeping informed about new ebuilds.

The users explicitly compromise to (just to make it clear):

1 - To fix *all* bugs and problems of the package: The user will need to
take care of all the bugs and problems of the specific package.
Including all dependencies if needed, in the case that the package need
dependencies that are not in the tree yet. (All these requirements
should of course be explicitly stated in the user request email)

2 - To keep track of upstream: The user needs to know the package's
project, and all the communication with upstream should be
responsibility of the user. we also sometimes find developers of a
specific project who would like to cooperate with gentoo , in my opinion
this model would give them an easy and organized opportunity to do so
either.

3 - This will give us a nice way to officially include into the tree
those packages that are more interesting for our users community. After
all they are the ones maintaining them.

4 - These users will need to keep constant and fluent communication with
the developers , you can even call it a 'team' , where the gentoo
developer is the official representation of the project. This also would
give a nice 'isolated' environment , where Gentoo as a project only
would see one developer , so we don't need any internal changes to our
current way of working. /me knock infra doors :-)

This evidently brings some developers responsibilities too, we will need
to review, and test the ebuilds. we sometimes will have to check with
upstream, and comment on the ebuild, or fixing some details. But it
should be a far minimimal effort than the developer taking care of the
package(s) by his own, in the better of the cases, he even shouldn't do
anything but to test, review and commit, from there on, the ebuild will
be under the standard procedures of maintenance (arch testing to
stabilize, bug reports to notify problems, etc). The developer should
also take care of any internal developer communication if needed.

You also can see, how we would be growing the seeds for future
developers right?

I know there already exist some developers working as proxy, well, i
appreciate if they got any comment or observation about this idea. This
is just a way of giving some organization to this kind of cooperative
mechanism at some degree. And an 'official' representation inside Gentoo
if we agree with it.

I think the project offers many advantages , i still don't figure out
too much about its implementation details (i hope you guys can help me
there too), we for sure would need a nice documentation paper , and
probably some bash scripts to automate things as genstef suggested me,
would this require a new project too?. I guess the implementation would
be something very easy though. /me knock knock infra

Ok, this is pretty much all i had in my mind for now, please send
suggestions , and criticism. Also, i hope this email helps to bring out
any problems i am not considering at the moment, if there exist any, i
am more than glad to hear them, as long as we keep the discussion in a
friendly and constructive manner. Sure we'll do!

Thanks and Gentoo for everyone!


- --


Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux


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

iD8DBQFEyXMKdZ42PGEF17URAs9JAJ9CWRH8MaUMTIYVnlaRiuMFfqAIuACghtKF
+QMKfUKkjQlbWw0INaA4/bI=
=6GTl
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)

[Thomas Cort]

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

On Thu, 27 Jul 2006 22:19:14 -0400
Luis Francisco Araujo <araujo@gentoo.org> wrote:

> The users explicitly compromise to (just to make it clear): [1,2,3,4]

People who participate in open projects like Gentoo come and go. What
happens if/when the proxy maintainer decides to leave? Who will take
care of the package? Maybe the mailing list could also be used to find
users to proxy maintain abandoned packages?

> I know there already exist some developers working as proxy, well, i
> appreciate if they got any comment or observation about this idea. This
> is just a way of giving some organization to this kind of cooperative
> mechanism at some degree. And an 'official' representation inside Gentoo
> if we agree with it.

I work with a user (Kai Huuhko) to maintain media-sound/quodlibet,
media-libs/mutagen, and media-plugins/quodlibet-*. I have a dev overlay
on overlays.gentoo.org where Kai and I both have commit access. We both
work on the ebuilds in the overylay and exchange ideas over e-mail.
After the ebuilds are complete and tested, I commit them to the official
tree. Kia helps with bugs too. So far it has worked very well for us
and we haven't had any problems with the arrangement. Having a helper
saves me time and energy, which allows me do other Gentoo related tasks.

-Thomas

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

Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)

[Luis Francisco Araujo]

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

Thomas Cort wrote:
> On Thu, 27 Jul 2006 22:19:14 -0400
> Luis Francisco Araujo <araujo@gentoo.org> wrote:
> 
>> The users explicitly compromise to (just to make it clear): [1,2,3,4]
> 
> People who participate in open projects like Gentoo come and go. What
> happens if/when the proxy maintainer decides to leave? Who will take
> care of the package? Maybe the mailing list could also be used to find
> users to proxy maintain abandoned packages?
> 
Good point.

Definitely, the mailing list could be used to address this case too.

I see two possible situations in the best case:

1 - The developer sends the request to the mailing list asking for
somebody interested to continue proxy-maintaining the packages. Any
interested developer could step in.

2 - The proxy-user *could* be interested to become official developer to
maintain this package too.

As long as there exist an interested user to maintain the package i
think it's a matter of time to find a proxy-developer. (Any mechanism to
inform us which packages are in this state would be useful too, probably
a monthly message to the list?)

Now if the user isn't interested anymore , and i think this would be the
'worst' of the case, could be addressed in the following manner:

1- He could notify to the mailing list for any user interested to
continue maintaining the package(s).

2- If no user steps in, the developer would still represent officially
the package inside the tree. Now, this package _ideally_ shouldn't have
any bug (the user should have taken care of all of them right?), so
practically, this package shouldn't be any serious menace to the tree,
and therefore, the developer doesn't need to update the package if he
doesn't want to. If a bug appears , the developer can: a) Fix it , b)
mask the package , c) After b, remove the package. This being the
*worse* of the case as i said.

Now, i also see an interesting problem here.

I can notice we (as developers) make sort of an agreement when we become
a developer, but not when we leave the project. This is the main cause
we keep having so many packages unmaintained. I think that whatever we
do, if we don't find a solution to this situation, gentoo will continue
to suffer of this problem. And this idea is just an attempt to alleviate
some of it.

>> I know there already exist some developers working as proxy, well, i
>> appreciate if they got any comment or observation about this idea. This
>> is just a way of giving some organization to this kind of cooperative
>> mechanism at some degree. And an 'official' representation inside Gentoo
>> if we agree with it.
> 
> I work with a user (Kai Huuhko) to maintain media-sound/quodlibet,
> media-libs/mutagen, and media-plugins/quodlibet-*. I have a dev overlay
> on overlays.gentoo.org where Kai and I both have commit access. We both
> work on the ebuilds in the overylay and exchange ideas over e-mail.
> After the ebuilds are complete and tested, I commit them to the official
> tree. Kia helps with bugs too. So far it has worked very well for us
> and we haven't had any problems with the arrangement. Having a helper
> saves me time and energy, which allows me do other Gentoo related tasks.
> 
> -Thomas

Nice, we have something similar inside the Haskell herd. It looks like
we are not the only ones doing good then.

Probably making this mechanism more 'organized' and 'official', would
encourage more developers to work with it.

- --


Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQFEyYr4dZ42PGEF17URAovbAKCwSlJ8657WQpLPhRamAZ4SRrUdSgCgvMS2
ZS8ybMME+hXrByoct5BQh8Y=
=31YO
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: proxy-dev (an alternative to sunrise?)

[Stefan Schweizer]

Luis Francisco Araujo wrote:
> 3 - Users ask on this mailing list if there exist any developer
> interested to include X, or Y ebuild into the tree. (Probably we could
> create a template for this?)

The user should send the ebuild changes together with the mail. Make it look
like on LKML including diffstat and the actual diff. This way you can quote
and give review comments on the mailing list - visible for everyone.

Of course diffing needs a good script so that the user does not have to
generate the diff and the stat manually

> The user _has_ to compromise to take care of those previous commented
> three points that some of us might be afraid of, besides of giving us a
> centralized way of keeping informed about new ebuilds.
> 
> The users explicitly compromise to (just to make it clear)[1,2,3,4]:

How are we going to reach this? Currently the bugs for ebuilds which have
both developer and user in metadata get assigned to the developer and then
the developer puts the user on CC.

The proposed solution is to put in metadata: maintainer-needed as herd and
the user as maintainer. Thus the user can take care of the package but when
he leaves or is unavailable it is still considered maintainer-neeeded which
means that every developer can take it over or fix bugs.

In my opinion it does not matter which developer reviews a specific version
bug for a package - so the developer should not be noted in metadata.xml.
Of course developers can personally commit themselves to take care of the
package and add themselves to metadata too.

> This evidently brings some developers responsibilities too, we will need
> to review, and test the ebuilds. we sometimes will have to check with
> upstream, and comment on the ebuild, or fixing some details. But it
> should be a far minimimal effort than the developer taking care of the
> package(s) by his own, in the better of the cases, he even shouldn't do
> anything but to test, review and commit, from there on, the ebuild will
> be under the standard procedures of maintenance (arch testing to
> stabilize, bug reports to notify problems, etc). The developer should
> also take care of any internal developer communication if needed.

"internal developer communication" turns out to be CCing arches on stable
bugs. Giving ok to stabilize some new version. This should be done by the
maintaining user since he knows the package best.

What exactly do you mean with internal developer communication?

- Stefan

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: proxy-dev (an alternative to sunrise?)

[Luis Francisco Araujo]

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

Stefan Schweizer wrote:
> Luis Francisco Araujo wrote:
>> 3 - Users ask on this mailing list if there exist any developer
>> interested to include X, or Y ebuild into the tree. (Probably we could
>> create a template for this?)
> 
> The user should send the ebuild changes together with the mail. Make it look
> like on LKML including diffstat and the actual diff. This way you can quote
> and give review comments on the mailing list - visible for everyone.
> 
> Of course diffing needs a good script so that the user does not have to
> generate the diff and the stat manually
> 
You mean, when the user initially submit the request to the mailing
list? , or this one should always be used for the maintenance of the
package?

>> The user _has_ to compromise to take care of those previous commented
>> three points that some of us might be afraid of, besides of giving us a
>> centralized way of keeping informed about new ebuilds.
>>
>> The users explicitly compromise to (just to make it clear)[1,2,3,4]:
> 
> How are we going to reach this? Currently the bugs for ebuilds which have
> both developer and user in metadata get assigned to the developer and then
> the developer puts the user on CC.
> 
> The proposed solution is to put in metadata: maintainer-needed as herd and
> the user as maintainer. Thus the user can take care of the package but when
> he leaves or is unavailable it is still considered maintainer-neeeded which
> means that every developer can take it over or fix bugs.
> 
> In my opinion it does not matter which developer reviews a specific version
> bug for a package - so the developer should not be noted in metadata.xml.
> Of course developers can personally commit themselves to take care of the
> package and add themselves to metadata too.
>

Well, my idea is more focused on getting closer the developer with the
user, in the sense that they would be like a team (as i already said) ,
where the developer is the official figure in the group. So, at some
degree, it does matter who is the proxy-developer in this case. The main
idea is that he _indeed_ would be maintaining the package from a Gentoo
perspective, and that is where the user will need to compromise with the
developer.

We could even create a new herd (proxy), so we can differentiate between
these ebuilds inside maintainer-needed and those under the control of a
specific proxy developer.

This idea is heavily based on 'trust' and 'constant' communication
between the user and the developer. And that is the way we can get the
'isolation' effect i commented earlier on.

>> This evidently brings some developers responsibilities too, we will need
>> to review, and test the ebuilds. we sometimes will have to check with
>> upstream, and comment on the ebuild, or fixing some details. But it
>> should be a far minimimal effort than the developer taking care of the
>> package(s) by his own, in the better of the cases, he even shouldn't do
>> anything but to test, review and commit, from there on, the ebuild will
>> be under the standard procedures of maintenance (arch testing to
>> stabilize, bug reports to notify problems, etc). The developer should
>> also take care of any internal developer communication if needed.
> 
> "internal developer communication" turns out to be CCing arches on stable
> bugs. Giving ok to stabilize some new version. This should be done by the
> maintaining user since he knows the package best.
> 
> What exactly do you mean with internal developer communication?
> 
> - Stefan
> 

Many things, for example, if one of the package affects other(s) herd(s)
(for example, some package dependency), i think that the right person to
coordinate this work with the rest of the developers would be the
proxy-developer.

And yes, the proxy-devel also would file stabilization bugs , CCing the
user too, so he can keep track of the process.

- --


Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux


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

iD8DBQFEydx/dZ42PGEF17URAtQXAKDTfcHhXthFw7cRS4Ko9p00mTYCkgCg2omJ
JaoyxDew0HETTJxZ8ZrLrvk=
=lfn9
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: proxy-dev (an alternative to sunrise?)

[Luca Longinotti]

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

Uhh just my two cents on this whoule proxy-dev stuff... I concede it
_is_ a good idea and can have it's benefits, but I can't see it as an
"alternative" to Sunrise... as an addition, that both exist and the user
can use both channels, ok, but not as a 1:1 sobstitute to Sunrise. I'm
not really sure the proxy-dev thing would even have success, cause it's
already done now by many herds and people, both using overlay and/or
privately (e-mail etc.), but they do it _only_ for stuff they are really
intersted in, how many would just do this direct dev-to-user
maintainershop for stuff they absolutely don't care for? Anyway I'm not
against this, with the proxy herd, ml et all, it could imo be organized
well and who's intersted can for sure communicate and work like he wants
etc., I just cannot see this as a 1:1 alternative to Sunrise, and here I
could have just misunderstood the first mail, maybe this wants to only
be an additional project, another channel, not the only one?
-- 
Best regards,
Luca Longinotti aka CHTEKK

LongiTEKK Networks Admin: chtekk@longitekk.com
Gentoo Dev: chtekk@gentoo.org
SysCP Dev: chtekk@syscp.org
TILUG Supporter: chtekk@tilug.ch


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

Re: [gentoo-dev] Re: proxy-dev (an alternative to sunrise?)

[Enrico Weigelt]

* Luis Francisco Araujo <araujo@gentoo.org> schrieb:

Hi,

> Well, my idea is more focused on getting closer the developer with the
> user, in the sense that they would be like a team (as i already said) ,
> where the developer is the official figure in the group. So, at some

so far okay, but we probably suffer an different problem: 

The gentoo devs currently do much of the upstream's work.
Fixing bugs or even adding new stuff which does not directly have to
do w/ gentoo should be done exlusively by the upstream.

The problem is: many projects have quite long release cycles and don't
do separate bugfix releases. For example expat: it took very long to
get some little makefile fixes into the release - the upstream team
collected quite much until they did the next release (and then they
released an direct, just bugfixing, sucessor of 1.98.x as 2.0.x ...).
Some projects are quite strange about such things and its like fighting
against windmills trying to change their minds.

So I founded an project which maintains such bugfixes and releases
hotfix patches against many versions of many patches and also stays
in contact w/ upstream to get them in the tree:

    http://wiki.metux.de/public/OpenSource_QM_Taskforce 

This project is meant to concentrate QM efforts more generally (instead 
of each distro for its own) and prevent double works, so many distros 
(and also self-compiling people) can benefit from it.

I'd like to invite you all to join this project and use it for your
dev works @ gentoo.

For an oss-qm + gentoo connection I imagine the following workflow:
(should also work w/ other distros this way) 

* gentoo user files an bug -> gets assigned to the devs.
* dev inspects the bug whether its gentoo-specific or general
  @ general:
     * dev pushes the bug to oss-qm (files a bug there), 
     * oss-qm tries to solve this bug and releases a new hotfix
     * the gentoo dev then takes in the hotfix and gives the 
       patched package into the QM cycle.
       
  @ gentoo:
     * works as currently

As for the suggested user contribution:

The users willing to contribute simply join the oss-qm team and do
their works there. This at least would cope evrything that's not
gentoo specific. What remains to gentoo would be just the contents
of the ebuild file (ie. useflags and dependencies okay, etc).

At the moment some ebuilds contain much logic for doing the actual 
build, ie. generating makefiles, etc. This should go completely to
oss-qm - the (hotfixed) packages should all supply one of the semi-
standard interfaces like autoconf-style ./configure, package imports
should be done entirely via pkg-config, etc.


In the last few days I did much of such fixing works, ie. on mpd and 
libao, mainly fixing configure.in + makefiles. Some of those works 
are currently hanging on the devs feet, but shouldn't. The gentoo devs 
should only have to take some (maybe hotfixed) package, pull it through 
the QM cycle and look if its good enough to get it into the tree.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: proxy-dev (an alternative to sunrise?)

[Luis Francisco Araujo]

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

Enrico Weigelt wrote:
> The gentoo devs currently do much of the upstream's work.
> Fixing bugs or even adding new stuff which does not directly have to
> do w/ gentoo should be done exlusively by the upstream.
> 

Not true at all.

We (as developers) won't be able to avoid helping upstream (it is
actually in our social contract). For example, we have dealt with
packages inside our herd where we are able to reproduce and detect a bug
before upstream does; or even found a "better" way of doing something,
and upstream (lucky for us) has always been happy of receiving our
suggestions/fixes , included even patches.

I personally think there is nothing wrong with this, i see it actually
as one of the goal of gentoo.

> 
> For an oss-qm + gentoo connection I imagine the following workflow:
> (should also work w/ other distros this way) 
> 
> * gentoo user files an bug -> gets assigned to the devs.
> * dev inspects the bug whether its gentoo-specific or general
>   @ general:
>      * dev pushes the bug to oss-qm (files a bug there), 
>      * oss-qm tries to solve this bug and releases a new hotfix
>      * the gentoo dev then takes in the hotfix and gives the 
>        patched package into the QM cycle.
>        
>   @ gentoo:
>      * works as currently
> 
> As for the suggested user contribution:
> 
> The users willing to contribute simply join the oss-qm team and do
> their works there. This at least would cope evrything that's not
> gentoo specific. What remains to gentoo would be just the contents
> of the ebuild file (ie. useflags and dependencies okay, etc).
> 

I fail to see a border line between what you call 'gentoo specific'
problems, and upstream problems. Really, it is not _that_ simple.

Also, i don't see how this might be an alternative to my current proposal.


- --


Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux


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

iD8DBQFEykgrdZ42PGEF17URAhleAKDgRx+zMNomW+UUUbg3dCvJmHdtggCbB25s
hGHkKFzMQmA6q9tMIaz3IhU=
=y4MH
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)

[Robert Cernansky]

On Thu, 27 Jul 2006 22:19:14 -0400 Luis Francisco Araujo <araujo@gentoo.org> wrote:
> 
> the developers could let all these three points at the hands of the
> user wanting to get the ebuild included into the tree.
[...]
> The user has to compromise to take care of those previous commented
> three points that some of us might be afraid of, besides of giving

Oh, if I can speak for me as a user I'll not like it. One of the major
advantage of Gentoo is easy maintenace (not mindless, but easy if you
know what you are doing) thanks to portage system. Another is
availability of large number of software in distribution. These two
together gives easily maintanable operating system - because of
portage and because I do not need to maintain lot of packages by
myself.

If I have some application that is not included in portage why
I decide to make an ebuild? Because I hope that then it will be
accepted and included to portage, so maintained by developers (big
thanks for this). If I have to take care of package + ebuild +
dependencies, I'll rather choose not to make an ebulid but compile
package right from .tar.gz archive.

Sorry for being such a bad user. But I'm pretty busy mostly so I'm
glad If I find time to make an initial ebuild and submit. In that
case, I see no problem to submit right to bugzilla and dicuss/fix/test
the ebuild there.

I would agree with your points of user responsibilty to solve bugs,
dependencies and so on, but only until package is accepted and
included to portage.

Robert


-- 
Robert Cernansky
E-mail: hslists2@zoznam.sk
Jabber: HS@jabber.sk

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)

[Luis Francisco Araujo]

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

Robert Cernansky wrote:
> Oh, if I can speak for me as a user I'll not like it. One of the major
> advantage of Gentoo is easy maintenace (not mindless, but easy if you
> know what you are doing) thanks to portage system. Another is
> availability of large number of software in distribution. These two
> together gives easily maintanable operating system - because of
> portage and because I do not need to maintain lot of packages by
> myself.
> 

I don't know what it is your point here. But i guess, yes, as an user
you shouldn't be worried about it. This is just another way for
cooperating with the project for those interested in doing so.

> If I have some application that is not included in portage why
> I decide to make an ebuild? Because I hope that then it will be
> accepted and included to portage, so maintained by developers (big
> thanks for this). If I have to take care of package + ebuild +
> dependencies, I'll rather choose not to make an ebulid but compile
> package right from .tar.gz archive.
>

Dependencies are not 'magically' solved. Somebody needs to initially
takes care of them.

> Sorry for being such a bad user. But I'm pretty busy mostly so I'm
> glad If I find time to make an initial ebuild and submit. In that
> case, I see no problem to submit right to bugzilla and dicuss/fix/test
> the ebuild there.
>

That is a different way to cooperate with us.

> I would agree with your points of user responsibilty to solve bugs,
> dependencies and so on, but only until package is accepted and
> included to portage.
> 

We need to know before committing this stuff to the tree that the user
will compromise at some degree. And this kind of work is a good sign of
it. We already have too many unmaintained stuff.


- --


Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux


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

iD8DBQFEylbXdZ42PGEF17URAiJ8AJ4hhP8DN5W6eRa9MTBA5md+qaLyRQCfW2Oe
jhsfuMDxntw7okoD4qI1Zrg=
=4ms8
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)

[Donnie Berkholz]

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

Robert Cernansky wrote:
> If I have some application that is not included in portage why
> I decide to make an ebuild? Because I hope that then it will be
> accepted and included to portage, so maintained by developers (big
> thanks for this). If I have to take care of package + ebuild +
> dependencies, I'll rather choose not to make an ebulid but compile
> package right from .tar.gz archive.

Many people disagree with you here, that's why overlays exist. Somebody
wants to use Portage to manage ebuilds that aren't yet in the actual tree.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)

[Robert Cernansky]

On Fri, 28 Jul 2006 14:26:31 -0400 Luis Francisco Araujo <araujo@gentoo.org> wrote:

> Robert Cernansky wrote:
> > Oh, if I can speak for me as a user I'll not like it. One of the
> > major advantage of Gentoo is easy maintenace (not mindless, but
> > easy if you know what you are doing) thanks to portage
> > system. Another is availability of large number of software in
> > distribution. These two together gives easily maintanable
> > operating system - because of portage and because I do not need to
> > maintain lot of packages by myself.
> 
> I don't know what it is your point here. But i guess, yes, as an
> user you shouldn't be worried about it. This is just another way for
> cooperating with the project for those interested in doing so.

I just understand it so, that if a user submits a new ebuild he has to
in fact maintain it. So overall maintenance time required by his
operating system will be pretty high. Because besides the
'emerge --sync' and 'emerge -u world', he needs take care of "his"
ebuilds.

In that paragraph I'm saying that Gentoo have lot of packages so there
is a little chance that users have to maintain some packages by
themselves (outside the portage tree). But this will break if users
have to maintain ebuilds which they submit.

> > thanks for this). If I have to take care of package + ebuild +
> > dependencies, I'll rather choose not to make an ebulid but compile
> > package right from .tar.gz archive.
> 
> Dependencies are not 'magically' solved. Somebody needs to initially
> takes care of them.

Yes, _initially_. This is what I agree with. That the points that you
propose will be applied only for initial import of ebuild. Until the
ebuild gets to portage tree. Then the developers take care of it. Of
course the note/recommendation can exist that user who submitted an
ebuild will help to maintain it also in future. But if not, (if the
user is mostly only a _user_ for whatever reason) the package will be
still maintained by developers.

Robert


-- 
Robert Cernansky
E-mail: hslists2@zoznam.sk
Jabber: HS@jabber.sk

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)

[Robert Cernansky]

On Fri, 28 Jul 2006 11:51:46 -0700 Donnie Berkholz <dberkholz@gentoo.org> wrote:

> Robert Cernansky wrote:
> > If I have some application that is not included in portage why
> > I decide to make an ebuild? Because I hope that then it will be
> > accepted and included to portage, so maintained by developers (big
> > thanks for this). If I have to take care of package + ebuild +
> > dependencies, I'll rather choose not to make an ebulid but compile
> > package right from .tar.gz archive.
> 
> Many people disagree with you here, that's why overlays
> exist. Somebody wants to use Portage to manage ebuilds that aren't
> yet in the actual tree.

Yes, it have sense for a larger set of packages (maybe) with
complicated depenencies. But I'm talking about few single packages.

OK, maybe I'd do some dirty ebuild but it will certainly not be ready
for any publication.

Robert


-- 
Robert Cernansky
E-mail: hslists2@zoznam.sk
Jabber: HS@jabber.sk

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)

[Luis Francisco Araujo]

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

Robert Cernansky wrote:
> On Fri, 28 Jul 2006 11:51:46 -0700 Donnie Berkholz <dberkholz@gentoo.org> wrote:
> 
>> Robert Cernansky wrote:
>>> If I have some application that is not included in portage why
>>> I decide to make an ebuild? Because I hope that then it will be
>>> accepted and included to portage, so maintained by developers (big
>>> thanks for this). If I have to take care of package + ebuild +
>>> dependencies, I'll rather choose not to make an ebulid but compile
>>> package right from .tar.gz archive.
>> Many people disagree with you here, that's why overlays
>> exist. Somebody wants to use Portage to manage ebuilds that aren't
>> yet in the actual tree.
> 
> Yes, it have sense for a larger set of packages (maybe) with
> complicated depenencies. But I'm talking about few single packages.
> 

An ebuild offer several advantages even for tiny packages.

- --


Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux


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

iD8DBQFEymTtdZ42PGEF17URAnCRAJ0VD++qAN6/ivZAsaMFvdbuibelJwCfSus1
H9CeyZgw3G36Mfedej1hOrU=
=rPeN
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)

[Alexandre Buisse]

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

On Fri, Jul 28, 2006 at 21:27:31 +0200, Robert Cernansky wrote:

> On Fri, 28 Jul 2006 14:26:31 -0400 Luis Francisco Araujo <araujo@gentoo.org> wrote:
> 
> > Robert Cernansky wrote:
> > > Oh, if I can speak for me as a user I'll not like it. One of the
> > > major advantage of Gentoo is easy maintenace (not mindless, but
> > > easy if you know what you are doing) thanks to portage
> > > system. Another is availability of large number of software in
> > > distribution. These two together gives easily maintanable
> > > operating system - because of portage and because I do not need to
> > > maintain lot of packages by myself.
> > 
> > I don't know what it is your point here. But i guess, yes, as an
> > user you shouldn't be worried about it. This is just another way for
> > cooperating with the project for those interested in doing so.
> 
> I just understand it so, that if a user submits a new ebuild he has to
> in fact maintain it. So overall maintenance time required by his
> operating system will be pretty high. Because besides the
> 'emerge --sync' and 'emerge -u world', he needs take care of "his"
> ebuilds.

I think you misunderstood luis' proposition. Everything would go on as
now, including users submitting ebuilds on bugzilla and not
"maintainaing" them anymore, but there would also be the solution of
asking to do more and being a
user_maintaining_an_ebuild_through_a_proxy_dev. If you don't want to do
that or don't have the time, and I expect it will be the case of 99.9%
of the users, it's fine. This project is only here for the remaining 0.1 %.

 
/Alexandre
-- 
Hi, I'm a .signature virus! Please copy me in your ~/.signature.

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

Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)

[Robert Cernansky]

On Fri, 28 Jul 2006 15:26:37 -0400 Luis Francisco Araujo <araujo@gentoo.org> wrote:
> 
> An ebuild offer several advantages even for tiny packages.

If it is self-maintained ebuild, it depends on complexity of
it. Currently I have one application outside the portage tree and
I found out to easier/less time consuming to just install it directly
from .tar.gz rather then maintaining an ebuild.

I plan to make an ebuild for it and submit, but probably I'll not have
time to maintain it.

Robert


-- 
Robert Cernansky
E-mail: hslists2@zoznam.sk
Jabber: HS@jabber.sk

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)

[Robert Cernansky]

On Fri, 28 Jul 2006 21:49:02 +0200 Alexandre Buisse <nattfodd@gentoo.org> wrote:

> On Fri, Jul 28, 2006 at 21:27:31 +0200, Robert Cernansky wrote:
> 
> > I just understand it so, that if a user submits a new ebuild he has to
> > in fact maintain it. So overall maintenance time required by his
> > operating system will be pretty high. Because besides the
> > 'emerge --sync' and 'emerge -u world', he needs take care of "his"
> > ebuilds.
> 
> I think you misunderstood luis' proposition. Everything would go on
> as now, including users submitting ebuilds on bugzilla and not
> "maintainaing" them anymore, but there would also be the solution of
> asking to do more and being
> a user_maintaining_an_ebuild_through_a_proxy_dev. If you don't want
> to do that or don't have the time, and I expect it will be the case
> of 99.9% of the users, it's fine. This project is only here for the
> remaining 0.1 %.

So it is something like communication channel between developers and
users willing to maintain some ebuild? If yes, it is great. I see no
problem then.

Robert


-- 
Robert Cernansky
E-mail: hslists2@zoznam.sk
Jabber: HS@jabber.sk

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)

[Luis Medinas]

On Fri, 2006-07-28 at 22:09 +0200, Robert Cernansky wrote:
> On Fri, 28 Jul 2006 21:49:02 +0200 Alexandre Buisse <nattfodd@gentoo.org> wrote:
> 
> > On Fri, Jul 28, 2006 at 21:27:31 +0200, Robert Cernansky wrote:
> > 
> > > I just understand it so, that if a user submits a new ebuild he has to
> > > in fact maintain it. So overall maintenance time required by his
> > > operating system will be pretty high. Because besides the
> > > 'emerge --sync' and 'emerge -u world', he needs take care of "his"
> > > ebuilds.
> > 
> > I think you misunderstood luis' proposition. Everything would go on
> > as now, including users submitting ebuilds on bugzilla and not
> > "maintainaing" them anymore, but there would also be the solution of
> > asking to do more and being
> > a user_maintaining_an_ebuild_through_a_proxy_dev. If you don't want
> > to do that or don't have the time, and I expect it will be the case
> > of 99.9% of the users, it's fine. This project is only here for the
> > remaining 0.1 %.
> 
> So it is something like communication channel between developers and
> users willing to maintain some ebuild? If yes, it is great. I see no
> problem then.
> 
> Robert
> 
> 
Not only for communication but to help developers too. I'm a
proxy/sponsor for a few packages and i'm very happy with the procedure.
Users maintain the best they can and we review their work and commit.
This is very good because we can teach anything users need and it's a
good thing too increase communication as long as everybody follow the
policies.


-- 
Gentoo Linux Developer
http://dev.gentoo.org/~metalgod


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)

[Alastair Tse]

On Fri, 2006-07-28 at 11:51 -0700, Donnie Berkholz wrote:
> Robert Cernansky wrote:
> > If I have some application that is not included in portage why
> > I decide to make an ebuild? Because I hope that then it will be
> > accepted and included to portage, so maintained by developers (big
> > thanks for this). If I have to take care of package + ebuild +
> > dependencies, I'll rather choose not to make an ebulid but compile
> > package right from .tar.gz archive.
> 
> Many people disagree with you here, that's why overlays exist. Somebody
> wants to use Portage to manage ebuilds that aren't yet in the actual tree.
> 

I have to say I agree with Donnie here on this.

I've been using private ebuilds for certain things that are installed on
my work systems that will never be applicable to anyone except for 4
people on this planet. Yet I use these because then I'm able to take
this simple single file, plonk it into another Gentoo machine and
recreate the same installation. Maybe it is just because making ebuilds
is now just second nature to me. 

Look at my overlay at the moment, half the stuff there have a less than
30% chance of ever making it into the main portage tree. But I still
make those ebuilds in the off chance that either (a) I do decide to put
them in, or (b) someone else might stumble across them and find it, and
(c) there are just things that I cannot test because I don't have the
hardware.

Proxy-dev and sunrise are completely different things. But both are
trying to decrease the steps needed to contribute to open source, so in
my book, that is a good thing.

Cheers,

Alastair

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)

[Bruno]

On Saturday 29 July 2006 02:19, Alastair Tse wrote:
> On Fri, 2006-07-28 at 11:51 -0700, Donnie Berkholz wrote:
> > Robert Cernansky wrote:
> > > If I have some application that is not included in portage why
> > > I decide to make an ebuild? Because I hope that then it will be
> > > accepted and included to portage, so maintained by developers (big
> > > thanks for this). If I have to take care of package + ebuild +
> > > dependencies, I'll rather choose not to make an ebulid but compile
> > > package right from .tar.gz archive.
> >
> > Many people disagree with you here, that's why overlays exist. Somebody
> > wants to use Portage to manage ebuilds that aren't yet in the actual
> > tree.
>
> I have to say I agree with Donnie here on this.
>
> I've been using private ebuilds for certain things that are installed on
> my work systems that will never be applicable to anyone except for 4
> people on this planet. Yet I use these because then I'm able to take
> this simple single file, plonk it into another Gentoo machine and
> recreate the same installation. Maybe it is just because making ebuilds
> is now just second nature to me.

I, as a simple user, also have my overlay, with ebuilds for software I use (at 
work also company-internal software), some driver that's not in portage, and 
whatever I need.
Big advantage of using ebuilds with portage over manually installing from 
tarballs is visible at update/uninstall time when old files should get 
deleted! Ebuild that fetch source from revision system (cvs, svn) are very 
useful too as recompiling is then as easy as typing "emerge <mysoftware>".

Ease of installation on second box comes on second position.

> Look at my overlay at the moment, half the stuff there have a less than
> 30% chance of ever making it into the main portage tree. But I still
> make those ebuilds in the off chance that either (a) I do decide to put
> them in, or (b) someone else might stumble across them and find it, and
> (c) there are just things that I cannot test because I don't have the
> hardware.

Through proxy-dev I may contribute ebuild for a few packages and maintain them 
over the time period I have use for them. E.g. drivers as long as I have 
given hardware (in use).

What would be useful is to have the option for a few users to maintain the 
same ebuild through one proxy-dev, this way when one user stops having 
usecase for the ebuild others can continue maintainership. Even maintaining 
while initial user lacks of time or is away would then not stop or fallback 
to the dev.

Regards,
Bruno
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: proxy-dev (an alternative to sunrise?)

[Ryan Hill]

Luis Francisco Araujo wrote:

> The 'modus-operandi' would go like this:
> 
> 1 - We setup a mailing list (yes, yet another one, but this one is gonna
> be useful!) , call it , proxy-dev@g.o , or proxy-review@g.o.
> 
> 2 - Developers interested to serve as a proxy , subscribe to the list.
> 
> 3 - Users ask on this mailing list if there exist any developer
> interested to include X, or Y ebuild into the tree. (Probably we could
> create a template for this?)
> 
> 4 - An interested developer says 'yes' on the list (so the rest of devel
> can see him too) , and from there on, the developer and the user work
> off-list.
>    Or a developer can say 'no'. Explaining the reason (if any) of why
> this ebuild shouldn't be included into the tree.

So far the only difference between this and doing a query on b.g.o for 
maintainer-wanted is that it's on mailing list.

> Now .. most of you must already be thinking, "well .. isn't this the
> same that going and picking maintainer-wanted ebuilds after all?"

Yep. ;)

> Here it comes the trick or 'trap' ;-)
> 
> The user _has_ to compromise to take care of those previous commented
> three points that some of us might be afraid of, besides of giving us a
> centralized way of keeping informed about new ebuilds.

_Has_ to?  How do we enforce that?

> The users explicitly compromise to (just to make it clear):
> 
> 1 - To fix *all* bugs and problems of the package: The user will need to
> take care of all the bugs and problems of the specific package.
> Including all dependencies if needed, in the case that the package need
> dependencies that are not in the tree yet. (All these requirements
> should of course be explicitly stated in the user request email)
> 
> 2 - To keep track of upstream: The user needs to know the package's
> project, and all the communication with upstream should be
> responsibility of the user. we also sometimes find developers of a
> specific project who would like to cooperate with gentoo , in my opinion
> this model would give them an easy and organized opportunity to do so
> either.
> 
> 3 - This will give us a nice way to officially include into the tree
> those packages that are more interesting for our users community. After
> all they are the ones maintaining them.
> 
> 4 - These users will need to keep constant and fluent communication with
> the developers , you can even call it a 'team' , where the gentoo
> developer is the official representation of the project. This also would
> give a nice 'isolated' environment , where Gentoo as a project only
> would see one developer , so we don't need any internal changes to our
> current way of working. /me knock infra doors :-)

So basically, the user does all the work in exchange for the ebuild being in 
portage.  Once it's in they disappear off the face of the earth.  I still don't 
see how this is any different than the status quo.

> This evidently brings some developers responsibilities too, we will need
> to review, and test the ebuilds. we sometimes will have to check with
> upstream, and comment on the ebuild, or fixing some details. But it
> should be a far minimimal effort than the developer taking care of the
> package(s) by his own, in the better of the cases, he even shouldn't do
> anything but to test, review and commit, from there on, the ebuild will
> be under the standard procedures of maintenance (arch testing to
> stabilize, bug reports to notify problems, etc). The developer should
> also take care of any internal developer communication if needed.

Right, just like now.

> You also can see, how we would be growing the seeds for future
> developers right?
> 
> I know there already exist some developers working as proxy, well, i
> appreciate if they got any comment or observation about this idea. This
> is just a way of giving some organization to this kind of cooperative
> mechanism at some degree. And an 'official' representation inside Gentoo
> if we agree with it.

I don't think it's necessary to formalize it.  If you find a user who wants to 
help then great.  Go ahead.  You're free to define whatever relationships that 
work for you.  It doesn't have to be officially stamped and sealed, it's just 
everyday social interaction.

--de.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)

[Luis Francisco Araujo]

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

Bruno wrote:
> 
> Through proxy-dev I may contribute ebuild for a few packages and maintain them 
> over the time period I have use for them. E.g. drivers as long as I have 
> given hardware (in use).

That is great!

> 
> What would be useful is to have the option for a few users to maintain the 
> same ebuild through one proxy-dev, this way when one user stops having 
> usecase for the ebuild others can continue maintainership. Even maintaining 
> while initial user lacks of time or is away would then not stop or fallback 
> to the dev.
> 

I think this perfectly could be done,since it is going to be like a
team, many users could help with one single ebuild.

Thanks for your suggestions!

- --


Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux


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

iD8DBQFEy+LYdZ42PGEF17URAgVUAJ98u6T8OLhwruQyysZPMZAqdkBdYwCeK8ZB
0t5NqlzI3f2FsOMB/D7EEc8=
=b1yA
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: proxy-dev (an alternative to sunrise?)

[Luis Francisco Araujo]

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

Ryan Hill wrote:
> 
> So far the only difference between this and doing a query on b.g.o for
> maintainer-wanted is that it's on mailing list.

Which (as a side note), increase the flow of communication between
developers and users, giving an alternative bugzilla.

> 
>> Here it comes the trick or 'trap' ;-)
>>
>> The user _has_ to compromise to take care of those previous commented
>> three points that some of us might be afraid of, besides of giving us a
>> centralized way of keeping informed about new ebuilds.
> 
> _Has_ to?  How do we enforce that?
>

Nobody forces anybody here to do anything. In the same way we (by
ourselves) compromise as developer to cooperate with Gentoo , we also
need the same degree of compromise from the users. That simple. This is
a project for people who wants to cooperate under these requirements.

The users will need to read the guidelines of the project (when posted),
and all these points would be explained as better as possible, so he/she
might know what kind of work they need to do inside the proxy project.

> So basically, the user does all the work in exchange for the ebuild
> being in portage.  Once it's in they disappear off the face of the
> earth.  I still don't see how this is any different than the status quo.
>

Please (re^10e)-read the point 4. (the most important one by the way)

>> This evidently brings some developers responsibilities too, we will need
>> to review, and test the ebuilds. we sometimes will have to check with
>> upstream, and comment on the ebuild, or fixing some details. But it
>> should be a far minimimal effort than the developer taking care of the
>> package(s) by his own, in the better of the cases, he even shouldn't do
>> anything but to test, review and commit, from there on, the ebuild will
>> be under the standard procedures of maintenance (arch testing to
>> stabilize, bug reports to notify problems, etc). The developer should
>> also take care of any internal developer communication if needed.
> 
> Right, just like now.

Not for those packages we fully maintain.

> 
> I don't think it's necessary to formalize it.  If you find a user who
> wants to help then great.  Go ahead.  You're free to define whatever
> relationships that work for you.  It doesn't have to be officially
> stamped and sealed, it's just everyday social interaction.
> 
> --de.
> 

It is organizing more than formalizing. I actually can see it might help
to spread the word about this technique that many of us have been using
for quite a time now. And even if we gain only one more user interested
to help with this, i think it is worthy.

- --


Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQFEy+YAdZ42PGEF17URAkhrAKDe7BNWY1yhOJibXoNBMu4ZbJYZqwCfZ32Q
2nKjQcISUdErK0jx7cVs5U0=
=Y8YL
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)

[Paul de Vrieze]

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

On Friday 28 July 2006 20:51, Donnie Berkholz wrote:
> Robert Cernansky wrote:
> > If I have some application that is not included in portage why
> > I decide to make an ebuild? Because I hope that then it will be
> > accepted and included to portage, so maintained by developers (big
> > thanks for this). If I have to take care of package + ebuild +
> > dependencies, I'll rather choose not to make an ebulid but compile
> > package right from .tar.gz archive.
>
> Many people disagree with you here, that's why overlays exist. Somebody
> wants to use Portage to manage ebuilds that aren't yet in the actual tree.

I'm one of those. Portage namely is also a package manager allowing what using 
the tarbal method does not: file tracking and deinstallation.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] Re: proxy-dev (an alternative to sunrise?)

[Simon Stelling]

Enrico Weigelt wrote:
> The gentoo devs currently do much of the upstream's work.
> Fixing bugs or even adding new stuff which does not directly have to
> do w/ gentoo should be done exlusively by the upstream.

This is not really a problem. Fixing bugs is what I enjoy after all, this is the
interesting stuff. Spending hours on one broken build system is far more
interesting than writing 100 ebuilds.

-- 
Kind Regards,

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

Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)

[Daniel Gryniewicz]

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

On Sun, 2006-07-30 at 15:50 +0200, Paul de Vrieze wrote:
> On Friday 28 July 2006 20:51, Donnie Berkholz wrote:
> > Robert Cernansky wrote:
> > > If I have some application that is not included in portage why
> > > I decide to make an ebuild? Because I hope that then it will be
> > > accepted and included to portage, so maintained by developers (big
> > > thanks for this). If I have to take care of package + ebuild +
> > > dependencies, I'll rather choose not to make an ebulid but compile
> > > package right from .tar.gz archive.
> >
> > Many people disagree with you here, that's why overlays exist. Somebody
> > wants to use Portage to manage ebuilds that aren't yet in the actual tree.
> 
> I'm one of those. Portage namely is also a package manager allowing what using 
> the tarbal method does not: file tracking and deinstallation.
> 
> Paul

FWIW, my company uses Gentoo and overlays extensively to manage our
workstations and testbeds.  The packages we have are not suitable for
inclusion in portage (for a number of reasons), and we have no intention
of ever submitting them.

Overlays are a *great* way of customizing a local network of boxes to be
different than upstream Gentoo for whatever reason.  I, personally, find
this to be a more useful function than a place to hold ebuilds not-yet
in portage (although, I do that also).

-- 
Daniel Gryniewicz
Gentoo AMD64 Team / Gentoo Gnome Herd / Gentoo Kernel Herd / Gentoo Printing Herd
AMD64 Operational AT Lead

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