[gentoo-dev] Some ideas on how to reduce territoriality

[gentoo-dev] Some ideas on how to reduce territoriality

[Chris Gianelloni]

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

More and more, I am finding developers who are afraid to touch packages
for even minor things if they're not the maintainer.  This is a sad
state of affairs and not the reason we have maintainers.  We have
maintainers to assure that a package is being taken care of, not to
establish some kind of "territory" over that package.  Because of this
misconception, I would like to come up with and document a listing of
things that any ebuild developer can feel free to do to any package
*without* maintainer consent.  These are generally all minor things, but
things that I think are important.  I'm going to list off the things
that I can think of, and encourage everyone else to speak up if I've
missed something.

- HOMEPAGE changes
- LICENSE changes
- arch-specific patches/dependencies - If someone is requesting KEYWORD
changes on a package and it requires a patch or additional dependencies
for your architecture, you are not only permitted, but really are
required to make the necessary changes to add support for your
architecture.
- Typo fixes
- SRC_URI changes - If the source has moved, feel free to fix it.  We
shouldn't have to wait on the maintainer to fix something this simple.
- *DEPEND changes due to changes in your packages - If a package that
you maintain moves, splits, or otherwise changes in a manner that
requires dependency changes on any other packages in the tree, you
should make those changes yourself.  You're free to ask for assistance,
of course, but you have the power to make the changes yourself without
asking permission.  After all, you're the one "breaking" the package, so
you should be the one to "fix" it.
- Manifest/digest fixes
- metadata.xml changes

There's a couple more that I wouldn't mind seeing as things developers
can do without the maintainer, but I can see how these might be a bit
more controversial, so I'm asking for input.

- Version bumps where the only requirement is to "cp" the ebuild
- (for arch teams) Stabilization of new revisions of an already stable
package - An example of this would be being able to stabilize foo-1.0-r2
if foo-1.0 (or foo-1.0-r1) is already stable, but not if only foo-0.9 is
stable.

So, what do you guys think?

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Mike Doty]

Chris Gianelloni wrote:
[snip]

> 
> There's a couple more that I wouldn't mind seeing as things developers
> can do without the maintainer, but I can see how these might be a bit
> more controversial, so I'm asking for input.
> 
> - Version bumps where the only requirement is to "cp" the ebuild
This is more on a per package basis.  it's not fair to force the maintainer to
support a new version before he feels it's ready.  For example, I'd love to
bump games-simulation/simutrans but Mr_Bones_ claims it's unstable and doesn't
want it bumped.  It wouldn't be fair to him for me to bump it unless I took the
burden of support.

> - (for arch teams) Stabilization of new revisions of an already stable
> package - An example of this would be being able to stabilize foo-1.0-r2
> if foo-1.0 (or foo-1.0-r1) is already stable, but not if only foo-0.9 is
> stable.
arch teams are the definitive authority on keywording for their arch.  That
said, if there is a disagreement between maintainer and arch team, the support
burden falls on whoever did the keyword.  Teamwork should solve this problem
every time.

I think the territoriality issue is one of support burden more than anything else.

--taco
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Chris Gianelloni]

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

On Fri, 2007-08-03 at 15:19 -0700, Mike Doty wrote:
> Chris Gianelloni wrote:
> [snip]
> 
> > 
> > There's a couple more that I wouldn't mind seeing as things developers
> > can do without the maintainer, but I can see how these might be a bit
> > more controversial, so I'm asking for input.
> > 
> > - Version bumps where the only requirement is to "cp" the ebuild
> This is more on a per package basis.  it's not fair to force the maintainer to
> support a new version before he feels it's ready.  For example, I'd love to
> bump games-simulation/simutrans but Mr_Bones_ claims it's unstable and doesn't
> want it bumped.  It wouldn't be fair to him for me to bump it unless I took the
> burden of support.

This is why I said it should be discussed.  Also, it might very likely
be better to opt-out rather than opt-in on this.  I really don't know,
myself.

> > - (for arch teams) Stabilization of new revisions of an already stable
> > package - An example of this would be being able to stabilize foo-1.0-r2
> > if foo-1.0 (or foo-1.0-r1) is already stable, but not if only foo-0.9 is
> > stable.
> arch teams are the definitive authority on keywording for their arch.  That
> said, if there is a disagreement between maintainer and arch team, the support
> burden falls on whoever did the keyword.  Teamwork should solve this problem
> every time.

Well, I meant that this should be doable without the maintainer's
consent.  Meaning, I ask you to stabilize 1.0-r1 and a few weeks later,
you can decide to stabilize -r2 without me having to file a bug.
Basically, the maintainer decides the minimal revision he wants to go
stable (so bugs are fixed, etc) but the revisions after that are up to
the arch teams, unless the maintainer sees a need for everyone to update
(major bug, security).  My main goal here is to reduce the "we have to
wait on the maintainer to ask" issue within a given version of a
package.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Marius Mauch]

On Fri, 03 Aug 2007 15:47:27 -0700
Chris Gianelloni <wolf31o2@gentoo.org> wrote:

> Well, I meant that this should be doable without the maintainer's
> consent.  Meaning, I ask you to stabilize 1.0-r1 and a few weeks
> later, you can decide to stabilize -r2 without me having to file a
> bug. Basically, the maintainer decides the minimal revision he wants
> to go stable (so bugs are fixed, etc) but the revisions after that
> are up to the arch teams, unless the maintainer sees a need for
> everyone to update (major bug, security).  My main goal here is to
> reduce the "we have to wait on the maintainer to ask" issue within a
> given version of a package.

Well, that's probably ok when the higher revision is just a "fixed"
version, but if for example it includes new (invasive) patches or other
major changes to the ebuild it's a different story. But I'd hope we can
rely on common sense here.

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

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Philipp Riegger]

On Fri, 2007-08-03 at 15:06 -0700, Chris Gianelloni wrote:
> So, what do you guys think?

One problem i see is changing versions in the tree but not puting the
changes to the wip ebuilds in an overlay or somewhere else. Is there a
system to email any changes done to ebuilds maintained by developer X to
developer X? Like... selective commit mailinglist?

Philipp

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Petteri Räty]

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

Philipp Riegger kirjoitti:
> On Fri, 2007-08-03 at 15:06 -0700, Chris Gianelloni wrote:
>> So, what do you guys think?
> 
> One problem i see is changing versions in the tree but not puting the
> changes to the wip ebuilds in an overlay or somewhere else. Is there a
> system to email any changes done to ebuilds maintained by developer X to
> developer X? Like... selective commit mailinglist?
> 
> Philipp
> 

No.

Regards,
Petteri


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

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Donnie Berkholz]

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

Petteri Räty wrote:
> Philipp Riegger kirjoitti:
>> On Fri, 2007-08-03 at 15:06 -0700, Chris Gianelloni wrote:
>>> So, what do you guys think?
>> One problem i see is changing versions in the tree but not puting the
>> changes to the wip ebuilds in an overlay or somewhere else. Is there a
>> system to email any changes done to ebuilds maintained by developer X to
>> developer X? Like... selective commit mailinglist?
>>
>> Philipp
>>
> 
> No.

We really need to get a -commits mailing list going again. If the
subject and/or sender are set appropriately, it should be easy to filter
for items of interest.

Thanks,
Donnie


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

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Mike Doty]

Donnie Berkowitz wrote:
> Petteri Räty wrote:
>> Philipp Riegger kirjoitti:
>>> On Fri, 2007-08-03 at 15:06 -0700, Chris Gianelloni wrote:
>>>> So, what do you guys think?
>>> One problem i see is changing versions in the tree but not puting the
>>> changes to the wip ebuilds in an overlay or somewhere else. Is there a
>>> system to email any changes done to ebuilds maintained by developer X to
>>> developer X? Like... selective commit mailinglist?
>>>
>>> Philipp
>>>
>> No.
> 
> We really need to get a -commits mailing list going again. If the
> subject and/or sender are set appropriately, it should be easy to filter
> for items of interest.
> 
> Thanks,
> Donnie
> 
some of us infra types were entertaining a RS feed for this...
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Mike Doty]

Mike Doty wrote:
> Donnie Berkowitz wrote:
>> Petteri Räty wrote:
>>> Philipp Riegger kirjoitti:
>>>> On Fri, 2007-08-03 at 15:06 -0700, Chris Gianelloni wrote:
>>>>> So, what do you guys think?
>>>> One problem i see is changing versions in the tree but not puting the
>>>> changes to the wip ebuilds in an overlay or somewhere else. Is there a
>>>> system to email any changes done to ebuilds maintained by developer X to
>>>> developer X? Like... selective commit mailinglist?
>>>>
>>>> Philipp
>>>>
>>> No.
>> We really need to get a -commits mailing list going again. If the
>> subject and/or sender are set appropriately, it should be easy to filter
>> for items of interest.
>>
>> Thanks,
>> Donnie
>>
> some of us infra types were entertaining a RS feed for this...
stupid spell checker, that's RSS feed and sorry for mangling your name.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Robin H. Johnson]

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

On Fri, Aug 03, 2007 at 04:06:25PM -0700, Mike Doty wrote:
> >> We really need to get a -commits mailing list going again. If the
> >> subject and/or sender are set appropriately, it should be easy to filter
> >> for items of interest.
> > some of us infra types were entertaining a RS feed for this...
> stupid spell checker, that's RSS feed and sorry for mangling your name.
Alternatively, we try to create custom headers for the relevant portion
of the mails.

X-VCS-Repository: gentoo-x86
X-VCS-Directories: profiles/ licenses/
X-VCS-Files: profiles/foo licenses/bar
etc? (Suggest more headers that can be gained PURELY from the commit
data).

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Council Member
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

[gentoo-dev] Commitlog-mailinglist (was: Re: Some ideas on how to reduce territoriality)

[Lars Weiler]

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

* Robin H. Johnson <robbat2@gentoo.org> [07/08/03 16:20 -0700]:
> X-VCS-Repository: gentoo-x86
> X-VCS-Directories: profiles/ licenses/
> X-VCS-Files: profiles/foo licenses/bar

Everything implemented :-P  At least for all commits to
gentoo-x86.

Well, I reactivated the commitlog-script (quite the same we
use for the gentoo-doc-cvs-list) and added some more
Headers to it.  Currently I'm testing it with messages sent
to my own address as it seems that the old commit-list is
deactivated.

With the new VCS-server it should not cause any overhead and
with a real MTA on that machine those messages will be
queued even if our mailserver is not running.

So, if you want, we can reactivate that list.

Regards, Lars

-- 
Lars Weiler  <pylon@gentoo.org>  +49-171-1963258
Instant Messaging     : pylon@jabber.ccc.de
Gentoo Linux PowerPC  : Developer
Gentoo Infrastructure : CVS Administrator

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

Re: [gentoo-dev] Commitlog-mailinglist

[Donnie Berkholz]

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

Lars Weiler wrote:
> * Robin H. Johnson <robbat2@gentoo.org> [07/08/03 16:20 -0700]:
>> X-VCS-Repository: gentoo-x86
>> X-VCS-Directories: profiles/ licenses/
>> X-VCS-Files: profiles/foo licenses/bar
> 
> Everything implemented :-P  At least for all commits to
> gentoo-x86.
> 
> Well, I reactivated the commitlog-script (quite the same we
> use for the gentoo-doc-cvs-list) and added some more
> Headers to it.  Currently I'm testing it with messages sent
> to my own address as it seems that the old commit-list is
> deactivated.
> 
> With the new VCS-server it should not cause any overhead and
> with a real MTA on that machine those messages will be
> queued even if our mailserver is not running.
> 
> So, if you want, we can reactivate that list.

Pylon, you rock! Now that everything's working, let's get the -commits
list reactivated.

Thanks,
Donnie


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

[gentoo-dev] Re: Commitlog-mailinglist

[Christian Faulhammer]

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

Donnie Berkholz <dberkholz@gentoo.org>:
> > So, if you want, we can reactivate that list.
> Pylon, you rock! Now that everything's working, let's get the -commits
> list reactivated.

 Yes, please.  AOL.

V-Li

-- 
http://www.gentoo.org/
http://www.faulhammer.org/
http://www.gnupg.org/

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

Re: [gentoo-dev] Commitlog-mailinglist (was: Re: Some ideas on how to reduce territoriality)

[Mike Frysinger]

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

On Saturday 04 August 2007, Lars Weiler wrote:
> So, if you want, we can reactivate that list.

doit (and update lists.xml in the process)
-mike

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

Re: [gentoo-dev] Commitlog-mailinglist

[Lars Weiler]

* Mike Frysinger <vapier@gentoo.org> [07/08/06 08:23 -0400]:
> doit (and update lists.xml in the process)

I can't.  The list seems to be closed or limited to a
special address.  Furthermore it seems that our listmaster
is either MIA or at LWE.

Regards, Lars

-- 
Lars Weiler  <pylon@gentoo.org>  +49-171-1963258
Instant Messaging     : pylon@jabber.ccc.de
Gentoo Linux PowerPC  : Developer
Gentoo Infrastructure : CVS Administrator
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Commitlog-mailinglist

[Ned Ludd]

On Mon, 2007-08-06 at 16:43 +0200, Lars Weiler wrote:
> * Mike Frysinger <vapier@gentoo.org> [07/08/06 08:23 -0400]:
> > doit (and update lists.xml in the process)
> 
> I can't.  The list seems to be closed or limited to a
> special address.  Furthermore it seems that our listmaster
> is either MIA or at LWE.

One thing to note.. If we do make mailing list for this. It should not 
be archived in any such way. devs that subscribe to the mailing list 
better not be storing mail in imap on infra resources. 
We simply don't have that kinda spare space to mirror all 
cvs commits 2-300 times.

-- 
Ned Ludd <solar@gentoo.org>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Commitlog-mailinglist

[Lars Weiler]

* Ned Ludd <solar@gentoo.org> [07/08/06 08:01 -0700]:
> One thing to note.. If we do make mailing list for this. It should not 
> be archived in any such way. devs that subscribe to the mailing list 
> better not be storing mail in imap on infra resources. 
> We simply don't have that kinda spare space to mirror all 
> cvs commits 2-300 times.

It's a stupid idea to refuse storing of these messages on
woodpecker.  There are still some devs out there who fetch
their mails from that machine than using imap or a forward.

During the two days of testing I received 359 emails with a
total size of 1.4MB.  But this varies, especially during
phases of "please stabilise $Desktop-Engine".

Regards, Lars

-- 
Lars Weiler  <pylon@gentoo.org>  +49-171-1963258
Instant Messaging     : pylon@jabber.ccc.de
Gentoo Linux PowerPC  : Developer
Gentoo Infrastructure : CVS Administrator
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Commitlog-mailinglist

[Petteri Räty]

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

Lars Weiler kirjoitti:
> * Ned Ludd <solar@gentoo.org> [07/08/06 08:01 -0700]:
>> One thing to note.. If we do make mailing list for this. It should not 
>> be archived in any such way. devs that subscribe to the mailing list 
>> better not be storing mail in imap on infra resources. 
>> We simply don't have that kinda spare space to mirror all 
>> cvs commits 2-300 times.
> 
> It's a stupid idea to refuse storing of these messages on
> woodpecker.  There are still some devs out there who fetch
> their mails from that machine than using imap or a forward.
> 
> During the two days of testing I received 359 emails with a
> total size of 1.4MB.  But this varies, especially during
> phases of "please stabilise $Desktop-Engine".
> 
> Regards, Lars
>

Well perhaps we should just look at the overall usage of the mail box
instead of how it's used. I think there is already some limit in our
policy for how big you can keep your mailbox.

Regards,
Petteri


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

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Philipp Riegger]

On Sat, 2007-08-04 at 01:34 +0300, Petteri Räty wrote:
> >> So, what do you guys think?
> > 
> > One problem i see is changing versions in the tree but not puting the
> > changes to the wip ebuilds in an overlay or somewhere else. Is there a
> > system to email any changes done to ebuilds maintained by developer X to
> > developer X? Like... selective commit mailinglist?
>
> No.

Might that be an interesting feature for helping devs keep up to date
with their maintained packages? Or are there reasons against this? This
could of course be muteable...

Philipp

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Petteri Räty]

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

Chris Gianelloni kirjoitti:
> More and more, I am finding developers who are afraid to touch packages
> for even minor things if they're not the maintainer.  This is a sad
> state of affairs and not the reason we have maintainers.  We have
> maintainers to assure that a package is being taken care of, not to
> establish some kind of "territory" over that package.  Because of this
> misconception, I would like to come up with and document a listing of
> things that any ebuild developer can feel free to do to any package
> *without* maintainer consent.  These are generally all minor things, but
> things that I think are important.  I'm going to list off the things
> that I can think of, and encourage everyone else to speak up if I've
> missed something.
> 

I don't find anything wrong with doing the changes after you find that
the maintainer is not responsive. If the maintainer is responsive, he
will a) do the changes b) give you the permission to do it c) give
reasoning on why the proposed changes should not be done.

Regards,
Petteri


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

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Chris Gianelloni]

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

On Sat, 2007-08-04 at 01:23 +0300, Petteri Räty wrote:
> Chris Gianelloni kirjoitti:
> > More and more, I am finding developers who are afraid to touch packages
> > for even minor things if they're not the maintainer.  This is a sad
> > state of affairs and not the reason we have maintainers.  We have
> > maintainers to assure that a package is being taken care of, not to
> > establish some kind of "territory" over that package.  Because of this
> > misconception, I would like to come up with and document a listing of
> > things that any ebuild developer can feel free to do to any package
> > *without* maintainer consent.  These are generally all minor things, but
> > things that I think are important.  I'm going to list off the things
> > that I can think of, and encourage everyone else to speak up if I've
> > missed something.
> > 
> 
> I don't find anything wrong with doing the changes after you find that
> the maintainer is not responsive. If the maintainer is responsive, he
> will a) do the changes b) give you the permission to do it c) give
> reasoning on why the proposed changes should not be done.

Why should someone have to go through all of that just to make these
minor fixes?  Is it really necessary for someone to be required to try
to track down and contact the maintainer to tell them that they put
"ebiuld" instead of "ebuild" into an ebuild?  This is my entire point.
Why are we forcing a process that only fosters inefficiency?  It is much
simpler to say "if you see one of these, fix it" than to force every
single action to go through the maintainer.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Marius Mauch]

On Fri, 03 Aug 2007 15:49:58 -0700
Chris Gianelloni <wolf31o2@gentoo.org> wrote:

> Why should someone have to go through all of that just to make these
> minor fixes?  Is it really necessary for someone to be required to try
> to track down and contact the maintainer to tell them that they put
> "ebiuld" instead of "ebuild" into an ebuild?  This is my entire point.
> Why are we forcing a process that only fosters inefficiency?  It is
> much simpler to say "if you see one of these, fix it" than to force
> every single action to go through the maintainer.

Well, for simple typos it's ok. But some of the things you listed might
have a bigger impact: SRC_URI changes are ok when the actual files are
the same, but if they are somehow different one should really check wih
the maintainer to make sure it's still the correct file (same for
verifying checksums, unless it's obvious). In the end it comes down
that you have to know the consequences of a change, and assuming that
the maintainer knows more about a package than you do he should be
contacted for non-trivial changes (I'm not saying you have to wait for
him at all costs). Of course if a package is plain and
unconditionally broken it's ok to act first and talk later IMO, but
communication is a requirement, not something you should try to avoid.

One thing I completely disagree with however are the metadata.xml
changes. Basically you're saying there it's ok to change the maintainer
of a package without talking to the existing maintainer first (though
I'm sure that wasn't your intention).

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

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Roy Marples]

On Fri, 2007-08-03 at 15:06 -0700, Chris Gianelloni wrote:
> More and more, I am finding developers who are afraid to touch packages
> for even minor things if they're not the maintainer.  This is a sad
> state of affairs and not the reason we have maintainers.  We have
> maintainers to assure that a package is being taken care of, not to
> establish some kind of "territory" over that package.  Because of this
> misconception, I would like to come up with and document a listing of
> things that any ebuild developer can feel free to do to any package
> *without* maintainer consent.  These are generally all minor things, but
> things that I think are important.  I'm going to list off the things
> that I can think of, and encourage everyone else to speak up if I've
> missed something.

Arch bugs that obviously don't affect other arches.
An example of this is the pine/uw-imap/c-client stuff which does this

make lnx

Great! Make linux. Sucks for FreeBSD so I've been changing it to

if use elibc_FreeBSD ; then
   make bsf
else
   make lnx
fi

Obviously that's very simplified, but you get the idea. In this case I
don't expect the ebuild maintainer to use Gentoo/FreeBSD.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Luis Francisco Araujo]

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

Chris Gianelloni wrote:
> More and more, I am finding developers who are afraid to touch packages
> for even minor things if they're not the maintainer.  This is a sad
> state of affairs and not the reason we have maintainers.  We have
> maintainers to assure that a package is being taken care of, not to
> establish some kind of "territory" over that package.  Because of this
> misconception, I would like to come up with and document a listing of
> things that any ebuild developer can feel free to do to any package
> *without* maintainer consent.  These are generally all minor things, but
> things that I think are important.  I'm going to list off the things
> that I can think of, and encourage everyone else to speak up if I've
> missed something.
> 
> - HOMEPAGE changes
> - LICENSE changes
> - arch-specific patches/dependencies - If someone is requesting KEYWORD
> changes on a package and it requires a patch or additional dependencies
> for your architecture, you are not only permitted, but really are
> required to make the necessary changes to add support for your
> architecture.

I am not sure about this last one ... what if for example this patch is
only for supporting a special option of the package for that
architecture, but the maintainer of the package found out that such a
patch is unnecessary and/or will cause other kind of problems in the
package, therefore preferring avoiding such a patch ... or he just
wouldn't like to apply the patch for X or Y; or even further, he just
wouldn't like to have such a package available for that architecture
just yet for Z or W.

> - Typo fixes
> - SRC_URI changes - If the source has moved, feel free to fix it.  We
> shouldn't have to wait on the maintainer to fix something this simple.
> - *DEPEND changes due to changes in your packages - If a package that
> you maintain moves, splits, or otherwise changes in a manner that
> requires dependency changes on any other packages in the tree, you
> should make those changes yourself.  You're free to ask for assistance,
> of course, but you have the power to make the changes yourself without
> asking permission.  After all, you're the one "breaking" the package, so
> you should be the one to "fix" it.
> - Manifest/digest fixes
> - metadata.xml changes
> 
> There's a couple more that I wouldn't mind seeing as things developers
> can do without the maintainer, but I can see how these might be a bit
> more controversial, so I'm asking for input.
> 
> - Version bumps where the only requirement is to "cp" the ebuild
> - (for arch teams) Stabilization of new revisions of an already stable
> package - An example of this would be being able to stabilize foo-1.0-r2
> if foo-1.0 (or foo-1.0-r1) is already stable, but not if only foo-0.9 is
> stable.
> 

I think these two cases should still be handled by the herd or
maintainer of the package.

The stabilization idea sounds good and it could free maintainers from
filing similar bugs over and over ; but wouldn't this be more and harder
work for arch teams?. For example, they should carefully track the
history of all the packages to know when and if they should stabilize it
yet.

> So, what do you guys think?
> 

The other list of things look fine and safe to be changed by any maintainer.

Regards,

- --

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.5 (GNU/Linux)

iD8DBQFGs9KfBCmRZan6aegRAtK7AJ94CDovLQu51QmZy6TW69rMK4Tz1QCgm3C9
tKDsHyNAWsliFCx0MMzcIpA=
=RGhM
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Chris Gianelloni]

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

On Fri, 2007-08-03 at 21:13 -0400, Luis Francisco Araujo wrote:
> > - arch-specific patches/dependencies - If someone is requesting KEYWORD
> > changes on a package and it requires a patch or additional dependencies
> > for your architecture, you are not only permitted, but really are
> > required to make the necessary changes to add support for your
> > architecture.
> 
> I am not sure about this last one ... what if for example this patch is
> only for supporting a special option of the package for that
> architecture, but the maintainer of the package found out that such a
> patch is unnecessary and/or will cause other kind of problems in the
> package, therefore preferring avoiding such a patch ... or he just
> wouldn't like to apply the patch for X or Y; or even further, he just
> wouldn't like to have such a package available for that architecture
> just yet for Z or W.

The vagueness made it kinda hard to follow, but if a maintainer doesn't
want their package on an architecture, they need to mark it -arch for
that architecture.  As it is right now, any arch team can add ~arch
without maintainer consent.

> The stabilization idea sounds good and it could free maintainers from
> filing similar bugs over and over ; but wouldn't this be more and harder
> work for arch teams?. For example, they should carefully track the
> history of all the packages to know when and if they should stabilize it
> yet.

Huh?

It's simple.  The maintainer says "stabilize foo-1.2-r1" which gives a
minimum level that all arches should be using.  If foo-1.2-r2 comes out,
it is up to the arch team to decide if/when to stabilize it, *unless*
the maintainer requests a newer version/revision.  Basically, the
maintainer sets the minimum level they would like stable.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

[gentoo-dev] Re: Some ideas on how to reduce territoriality

[Steve Long]

Chris Gianelloni wrote:
>> The stabilization idea sounds good and it could free maintainers from
>> filing similar bugs over and over ; but wouldn't this be more and harder
>> work for arch teams?. For example, they should carefully track the
>> history of all the packages to know when and if they should stabilize it
>> yet.
> 
> Huh?
> 
> It's simple.  The maintainer says "stabilize foo-1.2-r1" which gives a
> minimum level that all arches should be using.  If foo-1.2-r2 comes out,
> it is up to the arch team to decide if/when to stabilize it, *unless*
> the maintainer requests a newer version/revision.  Basically, the
> maintainer sets the minimum level they would like stable.
> 
Yeah, but is there no way for whatever the maintainer stabilises on their
arch to be what everyone else should stabilise, without "filing similar
bugs over and over"? (ie automation of this bit.)


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Alec Warner]

Ask for forgiveness, not permission.
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Some ideas on how to reduce territoriality

[Steve Long]

Alec Warner wrote:

> Ask for forgiveness, not permission.

++ I think anything that streamlines the process is a good thing. (Obviously
I don't know enough about all the changes to comment on specifics.) Not
saying it should be done recklessly, eg SRC_URI changes. How about a simple
requirement that anyone who changes something test it before committing?
(Isn't this already there?)

I assume there is already a policy that devs take responsibility for any
changes they make.. (That fits with "you broke it, you fix it" [or have it
fixed, i guess.;])


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Some ideas on how to reduce territoriality

[Martin Jackson]

Steve Long wrote:
> Alec Warner wrote:
> 
>> Ask for forgiveness, not permission.
> 
> ++ I think anything that streamlines the process is a good thing. (Obviously
> I don't know enough about all the changes to comment on specifics.) Not
> saying it should be done recklessly, eg SRC_URI changes. How about a simple
> requirement that anyone who changes something test it before committing?
> (Isn't this already there?)
> 
> I assume there is already a policy that devs take responsibility for any
> changes they make.. (That fits with "you broke it, you fix it" [or have it
> fixed, i guess.;])
> 
> 

In general, while there are a lot of bad things that *can* happen when 
bumping a package, in most cases they don't.  In the cases they do, the 
dev that bumped should take responsibility.

I believe users will be understanding...ricing does have some risks, 
after all. :)

++

Thanks,
Marty
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Jeroen Roovers]

On Fri, 03 Aug 2007 15:06:07 -0700
Chris Gianelloni <wolf31o2@gentoo.org> wrote:

<list of trivial changes>

> There's a couple more that I wouldn't mind seeing as things developers
> can do without the maintainer, but I can see how these might be a bit
> more controversial, so I'm asking for input.

Another good candidate is correcting errors in anything dodoc is tasked
to install. When a TODO or other metafile goes missing in the course of
development, I often find ebuilds that still mention them. When I
haven't done my arch commit yet, I often correct the error after I
check whether the file has simply been moved, by either correcting the
path or removing the filename from the dodoc call.


Kind regards,
     JeR
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Vlastimil Babka]

Jeroen Roovers wrote:
> On Fri, 03 Aug 2007 15:06:07 -0700
> Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> 
> <list of trivial changes>
> 
>> There's a couple more that I wouldn't mind seeing as things developers
>> can do without the maintainer, but I can see how these might be a bit
>> more controversial, so I'm asking for input.
> 
> Another good candidate is correcting errors in anything dodoc is tasked
> to install. When a TODO or other metafile goes missing in the course of
> development, I often find ebuilds that still mention them. When I
> haven't done my arch commit yet, I often correct the error after I
> check whether the file has simply been moved, by either correcting the
> path or removing the filename from the dodoc call.

dodoc calls should have || die and USE=doc should be tested before 
commiting a bump, IMHO

-- 
Vlastimil Babka (Caster)
Gentoo/Java
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Steev Klimaszewski]

Vlastimil Babka wrote:

> dodoc calls should have || die and USE=doc should be tested before 
> commiting a bump, IMHO
> 

Sorry, I didn't realize my 3 hour compile of $APPLICATION should die 
because TODO wasn't around.  Vote against || die - it doesn't affect 
anything aside from misc docs not being installed, if its really that 
important, most people hit the website anyway.  (But yes, they should be 
corrected and tested before committing)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Petteri Räty]

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

Steev Klimaszewski kirjoitti:
> Vlastimil Babka wrote:
> 
>> dodoc calls should have || die and USE=doc should be tested before
>> commiting a bump, IMHO
>>
> 
> Sorry, I didn't realize my 3 hour compile of $APPLICATION should die
> because TODO wasn't around.  Vote against || die - it doesn't affect
> anything aside from misc docs not being installed, if its really that
> important, most people hit the website anyway.  (But yes, they should be
> corrected and tested before committing)
>

And is the average ebuild 3 hours and haven't you heard about FEATURES
noauto? The || die is there for maintainers to spot when version
bumping. If you commit a version that's broken with missing TODO and ||
die you should think about if you are doing everything right...

Regards,
Petteri


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

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Jurek Bartuszek]

Petteri Räty wrote:
> Steev Klimaszewski kirjoitti:
>> Vlastimil Babka wrote:
>>
>>> dodoc calls should have || die and USE=doc should be tested before
>>> commiting a bump, IMHO
>>>
>> Sorry, I didn't realize my 3 hour compile of $APPLICATION should die
>> because TODO wasn't around.  Vote against || die - it doesn't affect
>> anything aside from misc docs not being installed, if its really that
>> important, most people hit the website anyway.  (But yes, they should be
>> corrected and tested before committing)
>>
> 
> And is the average ebuild 3 hours and haven't you heard about FEATURES
> noauto? The || die is there for maintainers to spot when version
> bumping. If you commit a version that's broken with missing TODO and ||
> die you should think about if you are doing everything right...
> 

Just thinking aloud - why not add some (QA?) notice in the summary when
dodoc (and possibly other do*'s) fails? One would be instructed to file
a new bug when he sees it *and*, after all, the package will have still
been merged successfuly.

Best regards,
Jurek Bartuszek
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Jeroen Roovers]

On Sun, 05 Aug 2007 01:56:47 +0200
Jurek Bartuszek <jurek@gentoo.org> wrote:

> Just thinking aloud - why not add some (QA?) notice in the summary
> when dodoc (and possibly other do*'s) fails? One would be instructed
> to file a new bug when he sees it *and*, after all, the package will
> have still been merged successfuly.

That's already in place. dodoc does the following:

     echo "dodoc: ${x} does not exist" 1>&2

and anything in stderr is reported as a QA notice. All done. BAM!


Kind regards,
     JeR
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Mike Frysinger]

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

On Saturday 04 August 2007, Petteri Räty wrote:
> Steev Klimaszewski kirjoitti:
> > Vlastimil Babka wrote:
> >> dodoc calls should have || die and USE=doc should be tested before
> >> commiting a bump, IMHO
> >
> > Sorry, I didn't realize my 3 hour compile of $APPLICATION should die
> > because TODO wasn't around.  Vote against || die - it doesn't affect
> > anything aside from misc docs not being installed, if its really that
> > important, most people hit the website anyway.  (But yes, they should be
> > corrected and tested before committing)
>
> And is the average ebuild 3 hours and haven't you heard about FEATURES
> noauto? The || die is there for maintainers to spot when version
> bumping. If you commit a version that's broken with missing TODO and ||
> die you should think about if you are doing everything right...

so you think everyone should be an ebuild ninja and know exactly how to 
recover ?  or edit an ebuild to fix the issue themselves (you're assuming 
dodoc was the last statement in src_install, not the first)
-mike

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

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Petteri Räty]

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

Mike Frysinger kirjoitti:
> On Saturday 04 August 2007, Petteri Räty wrote:
>> Steev Klimaszewski kirjoitti:
>>> Vlastimil Babka wrote:
>>>> dodoc calls should have || die and USE=doc should be tested before
>>>> commiting a bump, IMHO
>>> Sorry, I didn't realize my 3 hour compile of $APPLICATION should die
>>> because TODO wasn't around.  Vote against || die - it doesn't affect
>>> anything aside from misc docs not being installed, if its really that
>>> important, most people hit the website anyway.  (But yes, they should be
>>> corrected and tested before committing)
>> And is the average ebuild 3 hours and haven't you heard about FEATURES
>> noauto? The || die is there for maintainers to spot when version
>> bumping. If you commit a version that's broken with missing TODO and ||
>> die you should think about if you are doing everything right...
> 
> so you think everyone should be an ebuild ninja and know exactly how to 
> recover ?  or edit an ebuild to fix the issue themselves (you're assuming 
> dodoc was the last statement in src_install, not the first)
> -mike

Yes, every gentoo dev with gentoo-x86 access should know how to deal
with it.

Regards,
Petteri


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

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Mike Frysinger]

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

On Monday 06 August 2007, Petteri Räty wrote:
> Mike Frysinger kirjoitti:
> > On Saturday 04 August 2007, Petteri Räty wrote:
> >> Steev Klimaszewski kirjoitti:
> >>> Vlastimil Babka wrote:
> >>>> dodoc calls should have || die and USE=doc should be tested before
> >>>> commiting a bump, IMHO
> >>>
> >>> Sorry, I didn't realize my 3 hour compile of $APPLICATION should die
> >>> because TODO wasn't around.  Vote against || die - it doesn't affect
> >>> anything aside from misc docs not being installed, if its really that
> >>> important, most people hit the website anyway.  (But yes, they should
> >>> be corrected and tested before committing)
> >>
> >> And is the average ebuild 3 hours and haven't you heard about FEATURES
> >> noauto? The || die is there for maintainers to spot when version
> >> bumping. If you commit a version that's broken with missing TODO and ||
> >> die you should think about if you are doing everything right...
> >
> > so you think everyone should be an ebuild ninja and know exactly how to
> > recover ?  or edit an ebuild to fix the issue themselves (you're assuming
> > dodoc was the last statement in src_install, not the first)
> > -mike
>
> Yes, every gentoo dev with gentoo-x86 access should know how to deal
> with it.

we're not talking developers, we're talking users.  it's inappropriate for a 
user to have spent significant time compiling a package only to have it fail 
because TODO does not exist.
-mike

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

[gentoo-dev] Re: Some ideas on how to reduce territoriality

[Steve Long]

Vlastimil Babka wrote:
> 
> dodoc calls should have || die and USE=doc should be tested before
> commiting a bump, IMHO
> 
Would it not be easier to roll the || die into dodoc? I know some eclass
functions die on error, but I haven't been able to find out what the
definitive list is, or at least the policy on how it's decided whether a
call should die.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Some ideas on how to reduce territoriality

[Petteri Räty]

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

Steve Long kirjoitti:
> Vlastimil Babka wrote:
>> dodoc calls should have || die and USE=doc should be tested before
>> commiting a bump, IMHO
>>
> Would it not be easier to roll the || die into dodoc? I know some eclass
> functions die on error, but I haven't been able to find out what the
> definitive list is, or at least the policy on how it's decided whether a
> call should die.
> 

Will be done in EAPI-1... Dealing with the breakage it would cause if
put into EAPI-0 would be a pain in the ass.

Regards,
Petteri



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

[gentoo-dev] Re: Some ideas on how to reduce territoriality

[Tiziano Müller]

Chris Gianelloni schrieb:
> - arch-specific patches/dependencies - If someone is requesting KEYWORD
> changes on a package and it requires a patch or additional dependencies
> for your architecture, you are not only permitted, but really are
> required to make the necessary changes to add support for your
> architecture.
And what is going to happen with the patch? Should go upstream, but 
who's responsible for that?

> - Typo fixes
> - SRC_URI changes - If the source has moved, feel free to fix it.  We
> shouldn't have to wait on the maintainer to fix something this simple.
This isn't simple. I know a couple of packages where there's more than 
one upstream and there might be a good reason to not use the original 
one. But I admit that this is corner case.

> - metadata.xml changes
With limitations.

> - Version bumps where the only requirement is to "cp" the ebuild
Just "cp"'ing the ebuilds is the reason that so many ebuilds are still a 
nightmare and full of little nasty bugs.

This is a complete no-go since there are so many things a careful 
maintainer has to consider (besides checking the packages changelog, the 
dependencies, the license, the docs, etc. he should also check the ebuild).

Cheers,
Tiziano

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Some ideas on how to reduce territoriality

[Steve Long]

Tiziano Müller wrote:

> Chris Gianelloni schrieb:
>> - arch-specific patches/dependencies - If someone is requesting KEYWORD
>> changes on a package and it requires a patch or additional dependencies
>> for your architecture, you are not only permitted, but really are
>> required to make the necessary changes to add support for your
>> architecture.
> And what is going to happen with the patch? Should go upstream, but
> who's responsible for that?
>
Er, the maintainer; if s/he's not bothered about the package compiling on
different archs, should s/he really be maintaining it? I doubt upstream
would appreciate that from a distro -- and it's not hard to file a quick
bug with a link to the gentoo one; a quick comment on the gentoo one and
any interested users can help upstream to triage it.

>> - metadata.xml changes
> With limitations.
>
Maintainer sounds like a definite no-no. Any others?

>> - Version bumps where the only requirement is to "cp" the ebuild
> Just "cp"'ing the ebuilds is the reason that so many ebuilds are still a
> nightmare and full of little nasty bugs.
>
> This is a complete no-go since there are so many things a careful
> maintainer has to consider (besides checking the packages changelog, the
> dependencies, the license, the docs, etc. he should also check the
> ebuild).
>
Yeah but if they can compile it and it works as an app (however that's
defined, this /is/ usr-land) what's the harm in bumping and allowing others
to test it? (This is unstable, I hope..) If they can't be bothered to do
that, how can they possibly claim to be testing it? (And why are they even
touching it if they're not interested? ;) [I dunno how make test fits into
this, either, as tests were broken for synfig.]

If the maintainer doesn't like it, well s/he's already got the new version
working on one arch/ machine (plus whichever user bugged the dev.) I can't
see anyone really bemoaning a new tester ;P


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Ciaran McCreesh]

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

On Fri, 03 Aug 2007 15:06:07 -0700
Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> - arch-specific patches/dependencies - If someone is requesting
> KEYWORD changes on a package and it requires a patch or additional
> dependencies for your architecture, you are not only permitted, but
> really are required to make the necessary changes to add support for
> your architecture.

arch-specific patches are almost always wrong. The last thing people
need is to come along and find some arch developer has applied a bad
arch-specific patch without asking first...

-- 
Ciaran McCreesh


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

[gentoo-dev] Re: Some ideas on how to reduce territoriality

[Steve Long]

Ciaran McCreesh wrote:

> On Fri, 03 Aug 2007 15:06:07 -0700
> Chris Gianelloni <wolf31o2@gentoo.org> wrote:
>> - arch-specific patches/dependencies - If someone is requesting
>> KEYWORD changes on a package and it requires a patch or additional
>> dependencies for your architecture, you are not only permitted, but
>> really are required to make the necessary changes to add support for
>> your architecture.
> 
> arch-specific patches are almost always wrong. The last thing people
> need is to come along and find some arch developer has applied a bad
> arch-specific patch without asking first...
> 
Thing is, in such a case, the maintainer isn't going to be using the arch
(or s/he'd have applied it already.) If there's a problem with the patch
_on that arch_ (where else is it going to show up) the arch team (or the
dev who applied it) is responsible for any bugs.

If there's a problem with getting the bugs assigned to that team, it's a
different issue (which needs to be resolved ofc.)

You seem to be saying that arch teams are deliberately going to apply "bad
patches" which makes no sense. If they do it's a QA and, ultimately, a
devrel issue aiui.


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Some ideas on how to reduce territoriality

[Christian Faulhammer]

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

Chris Gianelloni <wolf31o2@gentoo.org>:

[a lot of things]

everything but

> - metadata.xml changes

 is ok in my eyes.  Additions should be fine, but removing should be a
no-no.  Emphasize on common sense and after reading the "guide" and
doing the first commit, the person should write "I will test the change
well if it is more than a typo" a hundred time...with pen and paper.
 
V-Li

-- 
http://www.gentoo.org/
http://www.faulhammer.org/
http://www.gnupg.org/

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

Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Paul de Vrieze]

On Sat, 4 Aug 2007 08:06:07 Chris Gianelloni wrote:
> - HOMEPAGE changes
> - LICENSE changes
> - arch-specific patches/dependencies - If someone is requesting KEYWORD
> changes on a package and it requires a patch or additional dependencies
> for your architecture, you are not only permitted, but really are
> required to make the necessary changes to add support for your
> architecture.
> - Typo fixes
> - SRC_URI changes - If the source has moved, feel free to fix it.  We
> shouldn't have to wait on the maintainer to fix something this simple.
> - *DEPEND changes due to changes in your packages - If a package that
> you maintain moves, splits, or otherwise changes in a manner that
> requires dependency changes on any other packages in the tree, you
> should make those changes yourself.  You're free to ask for assistance,
> of course, but you have the power to make the changes yourself without
> asking permission.  After all, you're the one "breaking" the package, so
> you should be the one to "fix" it.
> - Manifest/digest fixes
> - metadata.xml changes

<snip>

> So, what do you guys think?

From my maintaining perspective it is ok if language support teams come in and 
fix binding issues with packages that are not specifically for that language 
but somehow have bindings. Like emacs, bash-completion, perl, python, java, 
etc. support in subversion. I don't really know some of these languages well, 
let alone how to best support them in gentoo. I don't mind help from those 
teams to get that stuff integrated and running well.

Paul
--
gentoo-dev@gentoo.org mailing list