[gentoo-dev] list masked for removal

2008-01-19 Thread Stefan Schweizer
# Stefan Schweizer [EMAIL PROTECTED] (19 Jan 2008)
# Project abandoned. Masked for removal, bug 206105
sys-apps/list
-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] last-rite bpalogin for mark_alec

2007-09-02 Thread Stefan Schweizer
someone should get him a cvs account ;)

# Stefan Schweizer [EMAIL PROTECTED] (02 Sep 2007)
# last-rite bpalogin for mark_alec, as the package is useless now (ISP
# no longer needs it) and the initscript is broken with baselayout2
net-dialup/bpalogin

-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] Re: ML changes

2007-07-12 Thread Stefan Schweizer
Mike Doty wrote:
 We're going to change the -dev mailing list from completely open to where
 only devs can post,

Restricting freedom to post is like setting up surveilance and censorship
against terrorism.

I hate it when the rulers think they can impose such decisions upon the
people and do not see how they obviously impact their freedom.

If it is only against a single User who has done something bad, but against
all users in general, you are crazy ..

-Stefan

-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] Last rites: media-tv/freevo

2007-07-11 Thread Stefan Schweizer
Hi,

# unmaintained, masked for removal, bug 156497
# You can find a new version in the sunrise overlay
media-tv/freevo-1.7.2

Best regards,
Stefan

-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] Re: [RFC] should we do an EAPI bump now with features that are already implemented?

2007-07-10 Thread Stefan Schweizer
Can you please also list #138792 as implemented? It has a patch attached.

-Stefan

-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] Re: [gentoo-council] Nominations open for the Gentoo Council 2007/08

2007-07-02 Thread Stefan Schweizer

A good time for a fresh wind in the Gentoo world :)

nominating:

betelgeuse
dberkholz
jokey

Best regards,
Stefan
--
[EMAIL PROTECTED] mailing list



[gentoo-dev] Re: [RFC] Non-Dev Contributors and the Tree

2007-06-08 Thread Stefan Schweizer
Steve Long wrote:
 Dunno what the procedure might end up becoming, but my understanding is
 commit right to the sunrise overlay, from where a dev has to commit it to
 the main tree. It seems like a logical extension of sunrise, and i am sure
 there are stats on who has submitted what to sunrise in the past. So there
 is a baseline for whom to invite to become insertNameOfNewPosts.

Snrise already has such an extension. A portage-review/ subdirectory,
where ebuilds from the gentoo-x86 + changes can be posted. A dev then takes
those and reviews them to the main tree and removes them again from the dir

The process has worked really good so far. I suggest you to read up on how
this is currently being done on overlays.gentoo.org/proj/sunrise and if you
are interested I invite you to join #gentoo-sunrise to see how it is done.

The current log:
http://overlays.gentoo.org/proj/sunrise/log/portage-review

You will notice the regular in portage, now reviewed, in cvs messages

Best regards,
Stefan

-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] Re: invalid herd in metadata.xml

2007-05-10 Thread Stefan Schweizer
Thilo Bangert wrote:
 All packages with herdmaintainer-needed/herd will be moved to
 herdno-herd/herd.

I think that is not quite right, and since maintainer-needed is not a
maintainer but multiple people listening to the alias and users I would
like to suggest the following addition to herds.xml to make it legal:

herd
namemaintainer-needed/name
email[EMAIL PROTECTED]/email
descriptionOrphaned packages. Every developer is encouraged to fix
bugs here, proxy-maintain or take over maintainance/description
maintainer
email[EMAIL PROTECTED]/email
nameMaintainer Needed/name
/maintainer
/herd


Best regards,
Stefan

-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] Re: OT: was 2007.0 release

2007-04-14 Thread Stefan Schweizer
Rumen Yotov wrote:
 Somebody might want to know (for a new install) for how long
 (eventually) he/she will have to wait.

You do not have to wait for the gentoo release engineering team. You will
get an up to date install after running emerge -uvaD system in your fresh
system.

If the livecd is not up-to-date enough for you you can use any liecd in the
linux world. The only thing you need is chroot support.

Do not wait - Go ahead and start installing Gentoo now :)

best regards,
Stefan

-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] Re: New Developer: Tobias Heinlein (keytoaster)

2007-04-14 Thread Stefan Schweizer
Christian Heim wrote:
 Tobias is joining us from Hamm, Germany where he's currently finishing the
 junior high school.

Wow he must be really young then. But I cannot find the adequate german
translation for junior high school. What is it?

Welcome to the devs!

-Stefan

-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] Re: Last rites: app-misc/gfontview

2007-04-08 Thread Stefan Schweizer
»Q« wrote:

 In news:[EMAIL PROTECTED],
 Philip Webb [EMAIL PROTECTED] wrote:
 
 070407 Stefan Schweizer wrote:
  # masked for removal: no release since 2001, build broken, bug
  154671 app-misc/gfontview
 
 I have added a comment to the bug.
 If you want to remove this package, please provide a better
 explanation.
 
 The bug is now marked invalid, but I'm not clear on what's happening,
 because the last comment also justifies removal.  Is gfontview still
 scheduled for removal?
 

no

Best regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Last rites: app-misc/gfontview

2007-04-07 Thread Stefan Schweizer
# Stefan Schweizer [EMAIL PROTECTED] (07 Apr 2007)
# masked for removal: no release since 2001, build broken, bug 154671
app-misc/gfontview


-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Last rites: app-misc/gfontview

2007-04-07 Thread Stefan Schweizer
Philip Webb wrote:

 070407 Stefan Schweizer wrote:
 # masked for removal: no release since 2001, build broken, bug 154671
 app-misc/gfontview
 
 I have added a comment to the bug.
 If you want to remove this package, please provide a better explanation.
 
 right you are. The bug is invalid - it was because he unmerged some
libraries he used earlier in depends and did not rebuild those depends.
Have unmasked it again for you :)

best regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] [last rites] virtual/x11

2007-03-25 Thread Stefan Schweizer

Hi,

virtual/x11 has been deprecated for some time and now that all packages 
that only use it have been removed it is time to mask and remove it. I 
have put it in package.mask now - please fix your overlays in case you 
still use virtual/x11 somewhere. It will be removed in 30 days as per 
the usual schedule.


Best regards,
Stefan

--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Package removals: libzvt+deps: gnomesu, xsu2, root-portal

2007-03-24 Thread Stefan Schweizer

# Stefan Schweizer [EMAIL PROTECTED] (24 Mar 2007)
# as-needed broken, unmaintained, for removal, bug 147550
x11-libs/libzvt
# use gksu now
app-admin/gnomesu
app-admin/xsu2
# use root-tail now
x11-misc/root-portal

--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: New developer: Bernard Cafarelli (voyageur)

2007-03-21 Thread Stefan Schweizer
Christian Heim wrote:
 Please welcome Bernard as a new fellow developer among us !
 

Thanks Bernhard - it is awesome to have up to date NX packages again! Thank
you also Christian for taking the time to set him up. Your work is really
appreciated.

Best regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] media-libs/libhydrogen masked for removal

2007-02-27 Thread Stefan Schweizer

libhydrogen is now masked for removal, modular X broken and unused.
Bug 153202

-Stefan

--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Masked for removal: app-i18n/skkinput, media-video/xiron

2007-02-27 Thread Stefan Schweizer

# Stefan Schweizer [EMAIL PROTECTED] (27 Feb 2007)
# Masked for removal, modular X incompatible
# bug 153202, upstream dead
media-libs/libhydrogen
# bug 139792, upstream dead
app-i18n/skkinput
# bug 116233, upstream dead
media-video/xiron

--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Global ebuild variables and pkg_setup

2007-02-21 Thread Stefan Schweizer
Some time ago the development version of portage used to source the 
ebuild only once. I very much liked this and in the process fixed some 
ebuilds like you described it.


Sadly this feature was removed from portage again - nice to see it 
coming up again. Please fix or point out ebuilds that are broken.


Best regards,
Stefan

--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] RFC: reduce conflicts, separate keywording from ebuilds

2007-02-19 Thread Stefan Schweizer

To my fellow arguing Gentoo developers,

due to the recent conflict concerning keywording I want to propose to
separate keywording completely from ebuilds. The keywords would reside
in a special file in profiles/, maybe even in more than one file to
allow more granular permissions. For example only mips developers can 
access

the mips keywording file then.

The arch team can then decide themselves which ebuild they want to mark
~arch and they can take care of possible new dependencies themselves.

Also currently kde keywording/stabling needs ~300 commits. The problem
being that all changes files also get transferred in a rsync. A separate
keywording file would be the only one changed thus greatly reducing the
sync time.

comments?

Best regards,
Stefan

--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: RFC: reduce conflicts, separate keywording from ebuilds

2007-02-19 Thread Stefan Schweizer

Bryan Østergaard wrote:

A. ~arch keywords are supposed to be carried over to new versions unless
we're talking about big rewrites or similar (so old versions doesn't
have to linger around in portage tree at all).

right, we all agree :)


B. If we're complaining about MIPS team not being able to ~mips kde-meta
on time we need to remove all the arch teams that falls behind from
time. I think that leaves us with maybe x86, amd64, sparc as *the only*
arch teams allowed to keyword kde-meta which is completely insane and an
insult to our users.
every arch team is allowed to keyword kde-meta, just they should not 
complain about their keywords not being on bumps when they are late.


Keyword-ebuild separation allows to clearly show the arch teams that 
they are responsible and allows the developers not to get into conflict 
here. It clearly would have avoided the recent conflict.


The problem is with ebuild developers like me having no means to get 
arch teams to keyword stuff yet we are responsible if something fails 
and we get bugs assigned.



[remove kde-meta talk]

Besides that splitting keywords out from ebuilds doesn't solve
*anything* at all related to this as the ebuilds *still* have to stay
around as long as they have keywords. Just like current policy says.
Moving metadata to another place doesn't change that at all.


yeah. A script for removing all ebuilds that are allowed to be removed 
by policy would be cool. Sadly I don't have one currently :(


We can for example also offer x86-only sync trees without all the 
ebuilds that are only relevant to the other arches.


Best regards,
Stefan

--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: RFC: reduce conflicts, separate keywording from ebuilds

2007-02-19 Thread Stefan Schweizer

Alexander Færøy schrieb:

It was discussed at the last council meeting... Proposed by jokey.


Thanks. Sorry I did not know about it because there was no summary for 
the last council meeting. From the log that I read now I cannot clearly 
define an outcome.


I would appreciate to see summaries again for the council.

- Stefan

--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: RFC: reduce conflicts, separate keywording from ebuilds

2007-02-19 Thread Stefan Schweizer

George Shapovalov schrieb:
a) move all the keywording into profiles (that is remove all KEYWORDS fields 
from all the ebuild) and disallow package maintainers and other devs (other 
than arch teams) to touch keywords


or 

b) leave ebuilds with simple ~arch/arch/-arch (literally) keywords and move 
granular per-arch settings to profiles


the first one + maintainer arch is what I like to have. Other arches can 
then go up to maintainer arch automatically(with a bot) for ~arch and 
manually for arch or define their own policies like they want.


or something else? Even then I am not sure how either of these is going to 
work, especially this:

The arch team can then decide themselves which ebuild they want to mark
~arch and they can take care of possible new dependencies themselves.


normally new versions/packages go directly into ~arch unless they are 
transiently masked by developer (waiting for release, etc) or are permanently 
masked live-cvs/svn ones. 
The particular case is about having new depends in new versions. For 
example in ghostscript-esp-8.15.3-r1 there is a new dependency on 
app-text/djvu and mips, arm, s390 and sh do not keyword it. See bug 
148945 too.


moving keywording only in the arch teams responsibility is the way to go 
imo because I hate having keywording bugs assigned to my herd where I 
can do nothing about it.


I am not sure how a) is going to work at all in 
this respect. Are we going to get tons of ebuilds just sitting there never 
made visible to any arch now (since even x86 would have a large backlog)? 


it can be automated to do this from the maintainer arch if the arch team 
wants it.


-Stefan

--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Package removals: net-misc/kssh, sys-fs/captive, net-print/hpoj

2007-02-19 Thread Stefan Schweizer

# Stefan Schweizer [EMAIL PROTECTED] (19 Feb 2007)
# bug 152513 broken on gcc4 and no release since 2002, masked for removal
net-misc/kssh

# Stefan Schweizer [EMAIL PROTECTED] (07 Nov 2006)
# Please use ntfs3g now - it is better. Will be removed someday
sys-fs/captive

# Stefan Schweizer [EMAIL PROTECTED] (06 Feb 2006)
# deprecated - please use net-print/hplip now
net-print/hpoj

Will remove in one month

Best regards,
Stefan

--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: GPL-2 vs GPL-2+

2006-12-22 Thread Stefan Schweizer
Diego 'Flameeyes' Pettenò wrote:
 Comments, ideas, proposals?

currently we have all those under GPL-2. Now when GPL-3 becomes available
people have the option to use GPL-3. However that will still allow people
to use GPL-2 if their patents, etc need it. SO it is not much difference.

The big difference that actually matters is when applications start to get
distributed only for the GPL-3 and actually then I would also like to see
the LICENSE change to GPL-3.

I see little benifit in having GPL-2+ but a lot of potential confusion and a
lot of work for developers to check all pkges.

- Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: eclass cvs should not use -z4 by default

2006-11-30 Thread Stefan Schweizer
[EMAIL PROTECTED] wrote:
 and the reply by Mike Frysinger (vapier), maintainer of this eclass:
 i would use -z1 or -z2 as the default and allow people to override it via
 make.conf ... but you should send your proposal to the gentoo-dev mailing
 list to see how people feel

why not use -z0? No compression at all should put less load on the servers.
And people that have less bandwidth can adjust it if they need.

Regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: New developer: Charlie Shepherd (masterdriverz)

2006-11-22 Thread Stefan Schweizer
Petteri Räty wrote:
 It's my pleasure to introduce to you Charlie masterdriverz Shepherd.
 He is joining us to help with the multiple kernel sources we have in the
 tree. Maybe we will have master-sources soon? Previously he has been
 helping in the sunrise overlay and he is also looking to join other
 herds than kernel.
 
 He hails from London, UK. This is how he describes himself in his own
 words: Apathetic KDE user, die hard vim user, relutanct irssi user,
 lived in London all my life, currently learning the bass (guitar).


congrats! Enjoy your time with Gentoo.

- Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: New developer: Cédric Krier

2006-11-13 Thread Stefan Schweizer
Petteri Räty wrote:
 It's my pleasure to introduce to you Cédric cedk Krier. He is joining
 us to help with the netmon herd. Previously he has been filling the
 bugzilla with new ebuilds and participating in the sunrise overlay.


Welcome! Finally some of those many many ebuilds you made will get into
portage.

Best regards,
- Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] mirroring distfiles/patches on patches.gentoo.org

2006-10-23 Thread Stefan Schweizer
To my fellow Gentoo Devlopers and Users,

The Gentoo Infrastructure team proposed this idea in june 2006
 * Reduce mirror time for Gentoo specific patches/tarballs
 * Offer an official location for Gentoo specific patches/tarballs
   (Instead of using dev.g.o, this would be the official place)
 * Offer a distributed (3+ servers) mirror rotation for this

This would be the official location for those distfiles when infra makes
it available. I am asking them for status reports on this you will maybe
see some here :)

But for the meantime I am using http://gentooexperimental.org/~genstef/dist
for this purpose. The reason is that I can remove and add stuff there
myself and can keep control of what gets deleted. I can use my favourite
scripts to create distfiles and keep them ordered. For example I am using
this for firefox-2.0. This workaround I initially had to use when I
discovered a bug in the mirroring script that was annoying me regularly.
The mirroring script does ignore all RESTRICT=mirror SRC_URIs even those at
mirror://gentoo/.
Bug 121332 ppp patch missing from distfiles
Bug 100260 The File foo2zjs-20050319.tar.gz missed on Gentoo-Mirrors
Those get uploaded and look fine but after 6 months they are suddenly being
removed by the script.

Initially of course I needed a solution of that bug badly and because the
mirrors kept dropping it I have just uploaded it to dev.gentoo.org in lack
of any other proper place to put it. But using dev.gentoo.org is deprecated
by our infra because the server may not be able to cope with the traffic.
Fortunately later I was able to get an account on Patrick Lauers
development server http://gentooexperimental.org/~genstef/dist to upload my
distfiles there.

So this is my current practice and I am eagerly waiting for infra to allow
me to use an official service instead of my bandaid. Unfortunately some
people are really afraid of what I am doing and want to harass me into
using the mirror://gentoo that I do not want to use. This mail is dedicated
to explain the issue to those people. 

Please, dont argue such discussions that only give you personal satisfaction
of being correct or an excuse to annoy other people. Useless yelling at
each other because of a minority where opinions differ is misplaced in a
project that is driven by volunteers. That is also why I have stopped and
written this mail.

But I can see that you are a bit frustrated because you did not get your way
through. So here is a guide of what you can do. I will gladly stop using
workarounds when I am allowed to have an equally bugfree and fast workflow
as currently. What you can do:

1) write a patch for portage to allow granular mirror restrictions for the
SRC_URI and work with infra on improving the mirroring script to not ignore
mirror://gentoo in mirror-restricted ebuilds. Also for this solution the
time for a distfile in /space/distfiles-local to hit the first mirror
should be equal to the time for ebuilds to get into the rsync rotation so
that problems for users who are too early.

2) get infra to provide patches.gentoo.org as a permanent solution that I
have asked for since march 2005 and it sometimes even looked close to
getting it on bug 85098.

Thanks for understanding
Stefan Schweizer

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: mirroring distfiles/patches on patches.gentoo.org

2006-10-23 Thread Stefan Schweizer
Alec Warner wrote:
 Those get uploaded and look fine but after 6 months they are suddenly
 being removed by the script.
 
 
 There is a distfiles whitelist[1] for this exact purpose...isn't there?
 
 [1]
 http://www.gentoo.org/proj/en/infrastructure/mirrors/overview-distfile.xml

Thanks for the heads up. I was not aware of this when I was looking for a
solution badly back then. Must be a rather recent development. Looks easy
and straightforward - even deleting is possible. Good job, guys :)

Still the developer needs to know about it and think of it in the moment of
adding mirror restrictions to an ebuild with mirror://gentoo sources. A
risk that is not going to be taken in any of my ebuilds.

I hope the people that prefer mirror://gentoo know about the issue and the
solution :)

Thanks,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: mirroring distfiles/patches on patches.gentoo.org

2006-10-23 Thread Stefan Schweizer
Grant Goodyear wrote:
 Truly, the sarcasm doesn't help.  It takes a potentially reasonable
 grievance and reduces it to just the author appearing to be a jerk.

Sorry, I have no intention to cause any ill fate. Is meant explanatory.

- Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: New Developer: David Shakaryan (omp)

2006-10-15 Thread Stefan Schweizer
Christian Heim wrote:
 So please welcome David as a new fellow developer among us!

You are welcome, David! It is nice to see another of the sunrise people join
Gentoo.

Also thanks to Christian - you are doing an awesome job these days handling 
new developers. Delays are no longer an issue. You are one of the people
that make working on Gentoo fun again!

- Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: New Developer: Alon Bar-Lev (alonbl)

2006-10-07 Thread Stefan Schweizer
Hi,

it has been a pleasure to work with you through bugzilla. I am really glad
you are a developer now - I will not have to commit anything for you
anymore now ;)

Best regards,
- Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Sunrise trusted committers with bugzilla access

2006-09-15 Thread Stefan Schweizer
Bryan Østergaard wrote:
 As there's been very little, if any, interest from anybody besides
 Stefan and Recruiters / Developer Relations I'm going to deny the
 contributor access idea. Recruiters and Developer Relations feels that
 this is a bad idea, especially seeing how hard it has been to reach any
 kind of resolution regarding who should get access and how we should
 solve the problems that I've outlined earlier.

thanks for the clear no. I should have realized that before writing the GLEP
and everything. Sorry :(

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Sunrise trusted committers with bugzilla access

2006-09-13 Thread Stefan Schweizer
To my fellow Gentoo developers,

in the Sunrise project we have some users who are ambitious and cotribute
more than a few ebuilds. Those regulars have the possibility to take the
ebuild quiz and acquire the title Sunrise trusted committer. Those
sunrise committers can use extended bugzilla permissions to edit keywords
EBUILD and REQUEST for example in the maintainer-wanted@ and
maintainer-needed@ bugzilla region where usually developers clean up litle
or have no interest in spending time on.

Now I tried to get this done with the [GLEP] Bugzilla access for
contributors and I was told it is to undefined and misses out the point of
removing access levels again. Also I was told that a GLEP for this is
overkill.

All this is addressed and working with the current arch testers procedure.
The plan is to just treat Sunrise trusted committers the same as arch or
herd testers. The difference is that they operate on ebuilds of all
flavours that interest themself in the sunrise overlay and not on a certain
herd of packages. Neither do they focus on testing for a specific
architecture. Just coding is their work, not testing - which explains the
difference in the name.

Now how do people feel about this approach?


-Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: [GLEP] Bugzilla access for contributors

2006-09-09 Thread Stefan Schweizer
Bryan Østergaard wrote:
[..] Adding a bit of structure to it seemed like a good
 thing and I'd argue that the small bit of structure have helped keep
 the discussion on track.

I talked with kloeri in private about this and a GLEP that allows giving out
bugzilla access permissions by non-recruiters is not wanted. Because of
this we concluded to apply the AT/HT procedure on overlays:

Projects operating on overlays can also recruit herd testers and call them
trusted committer. This explicitly includes sunrise which operates on a
random mumbo-jumbo of ebuilds.


thanks kloeri and request for discussion :)

best regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Re: Re: packages going into the tree with non-gentoo maintainers

2006-09-07 Thread Stefan Schweizer
Luca Barbato wrote:

 Carsten Lohrke wrote:
 On Sunday 03 September 2006 16:36, Stefan Schweizer wrote:
 I am not adding stuff. I am fixing existing packages. And I am taking
 responsibility.
 
 How wonderful this sort of maintenance is you can read here:
 
 https://bugs.gentoo.org/show_bug.cgi?id=146626
 
 Am I the only one who has a problem with this?
 
 
 Genstef PLEASE always contact the related herd before adding stuff.

I am part of the kde herd, thanks.

- Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: I'm concerned about a bug (#121142, imagemagick)

2006-09-06 Thread Stefan Schweizer
Roy Marples wrote:

 On Tuesday 05 September 2006 15:18, Sven Köhler wrote:
 There's no comment by the maintainer for a while. I wrote the patches
 that are needed to fix the problem. They work fine as far as i can tell.
 
 Don't feel too bad - I frequently post patches to bugs reported on the
 same day and ask for feedback. Some of which are now over a year old
 without any feedback from the reporter.

that is why I try to close a bug when commenting something on it. NEEDINFO
usually works on those and allows you to clean up your list of inactive
bugs.

Best regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: [GLEP] Bugzilla access for contributors

2006-09-04 Thread Stefan Schweizer
Elfyn McBratney wrote:
 thus that developer can request
 write access for them.  It's worked like that for at least two
 years...

I did that and devrel asked me to write a GLEP. If you can show me another
way to do it, I would like to hear about it! I have two contributors with
ebuild quiz here.

Regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: [GLEP] Bugzilla access for contributors

2006-09-04 Thread Stefan Schweizer
Josh Saddler wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Stefan Schweizer wrote:
 [. . .]
 
 Define contributors -- is this a special status? If it is, how does one
 *become* a contributor to get these rights?
 
 This is potentially a big problem, the way I see it.

As the word might tell a contributor is someone who is contributing. No
special status involved.

- Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: [GLEP] Bugzilla access for contributors

2006-09-04 Thread Stefan Schweizer
Alec Warner wrote:
 C.  No real standard on any other fora.  I don't need a GLEP to add
 someone to my project overlay, or grant them voice or ops in my
 project's IRC channel.  I don't need a GLEP to get them subscribed to my
 mailing list and I don't need a GLEP to add them to (most) project
 aliases.  Why does this require one?

devrel, plasmaroo, asked me to send this here. And hparker wanted me to send
it in, too. Cannot really answer that myself, but obviously there is no
working solution without a GLEP. I have two users on queue with their
ebuild quiz ready. Show me a way to get access for them if you think that
this is unneeded!

Regards,
Stefan 

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Re: [GLEP] Bugzilla access for contributors

2006-09-04 Thread Stefan Schweizer
Josh Saddler wrote:
 Stefan Schweizer wrote:
 Josh Saddler wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Stefan Schweizer wrote:
 [. . .]

 Define contributors -- is this a special status? If it is, how does
 one *become* a contributor to get these rights?

 This is potentially a big problem, the way I see it.
 
 As the word might tell a contributor is someone who is contributing. No
 special status involved.
 
 - Stefan
 
 Contributing what? Contributing how much? Contributing how long? How is
 quality measured? Is there a minimum level somewhere? X amount of ebuilds?
 X amount of patches for docs/packages, or donating hardware, or adminning
 a webnode somewhere?

It does not matter. The real requirement is not to be defined as
a contributor but to take the ebuild quiz:

To ensure that not everyone who asks for it can get access to edit bugs it
is required to complete the ebuild quiz prior to requesting access

-Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Re: [GLEP] Bugzilla access for contributors

2006-09-04 Thread Stefan Schweizer
Mike Frysinger wrote:

 On Monday 04 September 2006 02:45, Stefan Schweizer wrote:
 Josh Saddler wrote:
  Stefan Schweizer wrote:
  [. . .]
 
  Define contributors -- is this a special status? If it is, how does
  one *become* a contributor to get these rights?
 
  This is potentially a big problem, the way I see it.

 As the word might tell a contributor is someone who is contributing. No
 special status involved.
 
 huh ?  if contributors dont require special status, why are you proposing
 a GLEP ?
 -mike

they are not defined by their status. I wonder why this word is causing
problems ..

The status is maybe being an arch tester. This GLEP is not about status,
only about giving some people bugzilla access when needed.

-stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Re: Re: [GLEP] Bugzilla access for contributors

2006-09-04 Thread Stefan Schweizer
Josh Saddler wrote:
 Because as much as possible, we need to see something concrete, not maybe
 an arch tester. We need to have a better definition of what when needed
 is and who these some people are -- think about it. Do we want a system
 that works like devship, but only halfway -- like you suggested, just
 passing the ebuild quiz -- or is something more needed?

If it needs to be extended a new GLEP like this one can be written or this
one extended. This is only about bugzilla access, nothing more. So no, it
is meant to be as non-concrete as possible to allow usage in as many cases
as possible.

-Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

2006-09-03 Thread Stefan Schweizer
Kevin F. Quinn wrote:
 Then you should not have committed it - as a dev it is your
 responsibility to test any ebuilds your commit.  There's nothing
 stopping you doing the normal checks on the ebuild, even if you can't
 read Hebrew.  For example you should verify whether the '-j1' is really
 necessary on emake.

yeah, I do those tests of course. Had not thought of -j1 though. You are
right - it is not needed. Sorry :( 

 Furthermore I am actually part of
 maintainer-needed and commit fixes there. I am also on the
 maintainer-needed email alias.
 
 The point of a herd is to provide a contact for maintenance of the
 member packages - and maintainer-needed by definition does not do
 maintenance.

yup. This is just so I can keep track of bugs filed against it while clearly
separating them from bugs for packages which I judge more important and
maintain directly. Support is provided by upstream and the user,
build-testing/committing/ebuildfixes is provided by maintainer-needed
(which is most likely me)

 Also maintainer-needed makes obvious to everyone that they do not
 have to ask me to fix sth. or take over the package - less
 communication overhead.
 
 You can put notes into metadata.xml - see other instances for
 examples; the easiest way is to have two maintainer entries, and in
 the description field describe the maintenance arrangement.  

Give jeeves and herdstat support for reading notes and I might consider it.
What annoys me most when putting myself in is that arch teams will ask me
if I would want that stable. I honestly do not care.
The annoying thing about it is that I get more than one bugmailspam about it
and it also happens regularly for new versions :/
Such things the user should be able to decide himself.

 Putting 
 maintainer-needed as the herd just means the package is essentially
 unmaintained, and is a candidate for removal. 

that is what I want to imply by putting it in, you got me correctly.

 We should not be putting 
 stuff into the official tree if no dev has taken responsibility for it.

we are not putting new stuff in there, we are just fixing existing stuff so
that it does not need to be removed.

 And for proxying it does not matter who is proxying.
 
 Proxying is more than just doing whatever the non-dev says.  By
 committing to the tree, you take full responsibility for those
 commits.

I do. And if it breaks anyone I will fix it of course.

 Whoever does the commit takes formal responsibility for those commits.
 Therefore they should take note of bug activity relating to those
 commits.  If they don't care about that then they should not be acting
 as proxy in that case.

I do take note of all maintainer-needed bug activity. I do not put in myself
to clearly separate those from the other bugs where I am directly
maintaining stuff myself.

 Surely this is what the Sunrise overlay was for; user-supplied ebuilds
 that don't have a a Gentoo dev to take responsibility for maintenance.

true. Sunrise is only for new ebuilds however. It is not designed as a place
to dump ebuilds from portage to and force users of them to use Sunrise.
If you or antarus or someone else wants to remove it from the tree feel free
to do so, I am not in metadata, I do not care. I just fixed the bug.

- Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

2006-09-03 Thread Stefan Schweizer
Bryan Ãstergaard wrote:
 Ok, let me see if I can get this straight.. You're saying that
 maintainer-needed requires less communication overhead compared to
 ebuilds with maintainers assigned? And that maintainer-needed is
 therefore better than ebuilds having maintainers.

agreed. I prefer to fix ebuilds in maintainer-needed than maintained ebuilds
because communication takes eternally compared to fixing simple things
quickly.

 the committer in this case has no interest in maintaining the thing. And
 for proxying it does not matter who is proxying.
 Of course it matters. There's a big difference between a proxy
 maintainer having to ask a *specific* dev that's proxying his ebuild
 updates/changes or trying to find a random dev willing to help.

I will of course commit all fixes when anyone asks me to. But it does not
matter if I commit them or anyone else who cares and has access levels.

 this does not allow the actual maintainer to close the bug and causes a
 lot of bugspam for a person who does not care about it and should be only
 contacted in the end to commit fixes/patches/bumps.
 Shouldn't matter too much as a gentoo dev is still responsible for the
 package? 

of course he is still responsible. Does not mean he likes to get 10 mails
about people asking for stable keywords and arches stabilizing every month.

 Nobody shoud be adding stuff to portage without taking 
 responsibility for it.

I am not adding stuff. I am fixing existing packages. And I am taking
responsibility. The maintainer can always assign me bugs if he thinks I
should take care of them and I read and take care of them anyway because I
am on maintainer-needed.

- Stefan

PS: mailing lists are a bit broken. 3 people answer me and ask almost the
same and I answer almost the same again ..

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] [GLEP] Bugzilla access for contributors

2006-09-03 Thread Stefan Schweizer
Hi,

as requested by multiple devrel members I have written a GLEP to standardize
bugzilla access for contributors. It has already been discussed on the
devrel mailing list before but I am looking for a wider opinion now.

This is also a submission for the new council when it meets.

Best regards,
StefanGLEP: 52
Title: Bugzilla access for contributors
Version: $Revision: 1.1 $
Last-Modified: $Date: 2006/08/16 19:25:14 $
Author: Stefen Schweizer [EMAIL PROTECTED],
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 01-Sep-2006
Post-History: 01-Sep-2006


Abstract


To improve the development flux in Gentoo, we should allow more people to
manage bugs in our large bugzilla database.


Current situation


Currently there are specific deals with arch testers and devrel/infra to allow
arch testers to edit bugs. This GLEP is written to standardize the process and
make it available for all aspects of Gentoo where work is being done by people
who are no full developers.

Requirements


Bugzilla permissions


It is needed that contributors who work on bugs can edit them on their own and
do not have to rely on their mentoring or supervising developers to reassign
or modify bugs.

An example for this has been obvious since the overlays project was established.
Bugs for overlays should be filed on bugs.gentoo.org and will most likely get
assigned to the developer/herd. This does allow a contributor to fix the bug
but only to mark it as fixed in bugzilla when he is also an arch tester.

Security
-

To ensure that not everyone who asks for it can get access to edit bugs it is
required to complete the ebuild quiz prior to requesting access

Management
---

This cannot be managed by recruiters, because they lack the resources to do it.
Instead a developer who mentors more people gets access to edit bugzilla
permissions and can add people there where he has checked the ebuild quiz. The
developer will also take care of removing them again if needed. This reflects
current arch tester practice.

Copyright
=

This document has been placed in the public domain.


[gentoo-dev] repoman: check for deprecated eclasses

2006-09-01 Thread Stefan Schweizer
Hi,

Repoman needs to check for deprecated eclasses, see
http://bugs.gentoo.org/141677

As a result of the discussion in the bug, we would like to add
$PORTDIR/qa-data/eclass.deprecated
to allow to deprecate eclasses properly and make repoman fail.

This will allow us to avoid problems with new ebuilds for deprecated
eclasses which result in bugs like
Bug 141629 dev-util/systemtap-20060325.ebuild uses deprecated
kernel-mod.eclass
I believe the developer has not known anything about that kernel-mod is
deprecated when making that ebuild. Now he ignores the bug and we have that
old eclass used again :(

Best regards,
- Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: repoman: check for deprecated eclasses

2006-09-01 Thread Stefan Schweizer
Carsten Lohrke wrote:
 What about revdep-rebuild and
 emerge regarding installed stuff and overlays?

what do you mean? Please elaborate

I have only repoman in mind for now.

- Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-portage-dev] Re: default postsync

2006-08-14 Thread Stefan Schweizer
Hi,

I think this is a good idea. Now that we have the file installed by
portage-utils there are ideas spreading about using it in layman and eix.
Depending on portage-utils does not seem to be a good way to make sure that
the bin/post_sync file exists. Installing it on ou one neither, because of
collissions. So the best solution is to allow portage to provide this file.
Please add it

Best regards,
Stefan

Ned Ludd wrote:
 Jason and myself had talked about briefly but not in any depth about
 post sync actions. Quickly after the basic idea was accepted it
 started to become clear that a set of default triggered may be
 desired.
 So I was thinking like if portage installed something like the
 following or if we changed the behavior now in emerge.py before the
 existing become to widely adopted to do more or less the same thing
 that this bash script does.
 
 #!/bin/sh
 # Copyright 2006 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 # $Header: $
 
 if [ -d /etc/portage/postsync.d/ ]; then
 for f in /etc/portage/postsync.d/* ; do
 if [ -x ${f} ] ; then
 ${f}
 fi
 done
 else
 :
 fi
 ##
 
 How do you think we should handle it?
 Should we install a post_sync in a postinst phase outside of portage's
 handling if and only if not post_sync already exists?
 Should we change it to handled a postsync.d by default?
 Should we do both? I'm open as heck but would like to start to
 finalize then document it's behavior. I feel it could be one of the
 next untapped really useful features of portage. glsa-checking, news
 handling, search db updating, and stuff etc..


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



[gentoo-dev] Re: new svncache.eclass

2006-08-11 Thread Stefan Schweizer
Mark Stier wrote:
 See http://bugs.gentoo.org/show_bug.cgi?id=141806
 
 Provides caching and release tag support for SVN.


sorry - I do not see the need for a new eclass here. Can you please instead
modify the subversion eclass and add support for what you want to do?

Best regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] webdav global use flag and default

2006-07-28 Thread Stefan Schweizer
Hi

we currently have both webdav and nowebdav ueflags, this is confusing:

# grep webdav /usr/portage/profiles/use.local.desc
dev-util/git:webdav - Adds support for push'ing to HTTP repositories via DAV
dev-util/subversion:nowebdav - Disables WebDAV support via neon library
net-misc/sitecopy:webdav - Enable WebDav (Web-based Distributed Authoring
and Versioning) support.  This system allows users to collaborate on
websites using a web based interface.  See the ebuild for an FAQ page. 
Enables neon as well to handle webdav support.
www-apps/open-xchange:webdav - Enable WebDav (Web-based Distributed
Authoring and Versioning) support.
www-servers/lighttpd:webdav - Enables webdev properties

The proposed solution is to make webdav a global useflag and set it as a
default use flag to have the same effect as the current nowebdav use flag
in subversion.

Comments?

Regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-28 Thread 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



[gentoo-dev] Re: webdav global use flag and default

2006-07-28 Thread Stefan Schweizer
Paul de Vrieze wrote:
 I'd like to explain why subversion has a nowebdav useflag. Basically one
 of the features of subversion is its ability to work over the http
 protocol. Many subversion installations use the apache module to serve
 subversion (even our own overlay project does). To disable webdav support
 would cripple the subversion client. It is something one should only do
 when aware of the consequences.

right you are. Putting the default useflag into base/make.defaults has the
same effect as a nowebdav useflag without being a no* useflag and confusing
with other useflags that do not have the no* bit.

If there are no objections and you agree with the solution I will make
webdav global and default after a week from now and you can remove the old
nowebdav useflag.

If there are any problems with putting it in base/ for example neon does not
work on hardened, embedded or anything else I would like to know about it.

Best regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: webdav global use flag and default

2006-07-28 Thread Stefan Schweizer
Danny van Dyk wrote:
 5 packages, and only one has nowebdav, and you want to make it a default
 USE flag? I strongly disagree here. Make it a plain useflag and notify
 users of subversion that the behaviour changed. Much better than
 informing users of the other 4 packages that the behaviour changed.

We have no statistics on this so I cannot prove but I can argue that
subversion is used most of all 4 packages. And I can also argue that having
webdav on by default will not cause any harm for the other packages,
because it just adds and does not remove functionality. It does no harm.
Thus having users informed is not crucial here

However doing the change in subversion will break current useage cases by
reducing functionality. Most users do not read elog messages and just will
get broken. 

I see your problem and maybe there are ways of solving the problem:
- change all other 4 useflags to nowebdav, then make the webdav useflag
default, then change them all back to webdav. Maybe you are more happy with
such a gradual change.

- leave everything as is: it does work but I do not particularly like the
nowebdav useflag tho it is better than having subversion broken.

Best regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Project Sunrise resumed

2006-07-27 Thread Stefan Schweizer
To my fellow Gentoo developers and users,

Sunrise is about contributing ebuilds and getting feedback and review while
doing so. The main resource this currently happens for is the Gentoo User
Overlay of Sunrise and second come ebuilds that get into portage afterwards

In last weeks council meeting [1] it was decided that the Sunrise project is
no longer suspended. I can give a short overview of the current status of
the overlay:

- we currently have 154 ebuilds in 58 categories in the overlay
  not counting the ebuilds that got into portage and were removed again

- we have 8 developers, 4 trusted committers who have taken the ebuild quiz
  and 26 users committing to the overlay

The basic project concept of creating a social workspace has been reached.
#gentoo-sunrise is an active IRC channel where users usually find help
quickly and it also forms a friendly community.

Best regards,
Stefan

[1] http://www.gentoo.org/proj/en/council/meeting-logs/20060720-summary.txt
http://www.gentoo.org/proj/en/council/meeting-logs/20060720.txt
Other useful resources:
Project page http://www.gentoo.org/proj/en/sunrise/
svn reviewed http://www.gentoo-sunrise.org/svn/reviewed/
cia page http://cia.navi.cx/stats/project/sunrise/

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Project Sunrise resumed

2006-07-27 Thread Stefan Schweizer
Stephen P. Becker wrote:
 Eso since when did we have the discussion where you actually
 addressed all of the numerous concerns brought forth right before this
 project was initially suspended?

Do you have any concrete concerns that have not been dealt with yet? I would
like to hear about them in that case.

I have so far as good as possible implemented suggestions and answered
concerns.

- Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Proposal for a global xinetd USE flag

2006-07-23 Thread Stefan Schweizer
Matthew Kennedy wrote:
 The following ebuilds installed xinetd configuration on my machine
 even though I don't have xinetd installed.
 
 [EMAIL PROTECTED]:~$ equery belongs /etc/xinetd.d
 [ Searching for file(s) /etc/xinetd.d in *... ]
 dev-util/subversion-1.3.2-r1 (/etc/xinetd.d)
 dev-util/cvs-1.12.12-r3 (/etc/xinetd.d)
 net-misc/netkit-fingerd-0.17-r2 (/etc/xinetd.d)
 net-print/cups-1.2.1-r2 (/etc/xinetd.d)

more:
# qfile /etc/xinetd.d/
net-fs/samba (/etc/xinetd.d)
net-misc/telnet-bsd (/etc/xinetd.d)
net-dialup/capi4k-utils (/etc/xinetd.d)


Yes, please go ahead and make xinetd a global use flag. It is incorrect to
have several local use flags for the same purpose. In /etc/xinetd.d only a
small file is installed, so probably making that file optional is not
obligatory. Nevertheless it would be cool to use the useflag whereever
possible.

- Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] New category: net-voip

2006-07-18 Thread Stefan Schweizer
Hi,

the herd of voip packages is constantly growing and according to
herdstat -p voip we already have 60 packages in the voip herd. Those are
currently in the categories net-misc, net-im, net-libs, dev-libs and 
media-libs. Most of them would fit perfectly into a new net-voip category.
Those are enough packages to allow the creation of a new category.

More important than the current packages I think it is to put new packages
into the more precise net-voip instead of net-misc/net-im. For example some
packages in my overlay [1] maintained by the fellow gentoo users peper and
fuoco. Also there is a lot of stuff waiting in stkn's private voip overlay

The 47 voip packages in net-misc and net-im should be moved over to the new
category definitely, you can get the list with:
herdstat -p voip | grep -e net-im -e net-misc
From the others I think dev-libs/ilbc-rfc3951 should be moved, too.

Any objections, problems with the plan, comments?


[1] http://overlays.gentoo.org/svn/dev/genstef/net-im

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: making the firefox USE flag a global one

2006-07-18 Thread Stefan Schweizer
Simon Stelling wrote:
 I just noticed that the USE flag 'firefox' is a local one. I think it
 should be global, though:

Good plan. I think it should also be a default use flag on supported
architectures in desktop profiles. Can we make it default at the same time?

Regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: New category: net-voip

2006-07-18 Thread Stefan Schweizer
Ned Ludd wrote:
 Creation of a new categories is fine. pkg moves are bad.
 See the countless other posting on this subject of why pkg
 moves are bad.
yeah new packages is my primary concern.

 Any objections, problems with the plan, comments?
 
 Sure I'll step up and say I object to the part of your plan which
 involves a shitton of pkgmoves. Moving pkgs from existing categories
 into another category causes numerous problems that portage can't solve
 as easy as the rest of us might think so please just don't do that
 part. I've got no objection to the creation of a new category for *new*
 packages.

I talked with you in IRC about this more. We will do the package moves only
when a bump occurs and will make sure that stable as well as ~arch get an
updated ebuild.

Best regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Removal: net-im/gnomemeeting

2006-07-18 Thread Stefan Schweizer
Hi,

net-im/gnomemeeting is obsoleted by net-im/ekiga and if no objections come
up I will remove the old gnomemeeting in 30 days. I package.masked the
package for now.

see bug 136615 [1] for the removal request. alpha and pcc64 are asked to add
their keywords to ekiga. Also the ppc64 keyword is needed to readd the
gnomemeeting/ekiga depend to kopete that I have commented out for the time
being.

Regards,
Stefan

[1] http://bugs.gentoo.org/136615

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: [gentoo dev]suggestion to distutils eclass

2006-07-16 Thread Stefan Schweizer
Zhang Le wrote:

 Some packages don't provide standard setup.py.
 Take a look at the attachment.
 This is a new ebuld.
 
 So my suggestion is to add a new variable to distutils.eclass, e.g.
 SETUP.PY, if it's set, then use it, otherwise let it defaults to
 setup.py.

what about making a simple symlink then? This will avoid more code in a
general eclass for only very few cases.

You can also report this upstream and get them to rename the setup script.

Best regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: pybugz - python command line interface to bugzilla

2006-07-16 Thread Stefan Schweizer
Alastair Tse wrote:
 I know there's gentoo-bugger, which is great, but it's in perl and I
 couldn't figure out how to modify the output to suit my needs.
yeah gentoo-bugger was interactive, this one is better :)

I really like it, thank you.

 Here's the README attached if you're interested in how it might work for
 you to become more efficient when dealing with Gentoo's Bugzilla.

I am sure it will make us all more productive! 

 You can get it either via my portage overlay in:
 http://overlays.gentoo.org/svn/dev/liquidx/app-admin/pybugz
 or as a python distutils compat tarball in
 http://media.liquidx.net/static/pybugz/pybugz-0.5.tar.gz

I would love to see this in the portage tree. If you need an ebuild
maintainer just tell me :)

Best regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: xpdf status

2006-07-12 Thread Stefan Schweizer
Sune Kloppenborg Jeppesen wrote:
 On Wednesday 12 July 2006 16:43, [EMAIL PROTECTED] wrote:
 I really would like to see back the upstream version, what do you think?
 The reason for this was security I believe. xpdf code is embedded in lots
 of other packages (see http://glsa.gentoo.org for some examples). By
 linking to poppler this is fixed in one place.

Right you are, the reason is security.
 
 Though if someone is willing to maintain a vanilla xpdf ebuild I'd have no
 complaints. Genstef?
 
I have no complaints either. If there is exg doing the security bumps and
taking care of the upstream version I am supporting it.

- Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Making dobin, doexe, doins, doman, dodoc die by default

2006-07-12 Thread Stefan Schweizer
Hi,

This came up in Bug 138792 [dobin etc. should automatically die on failure]
It needs more discussion on the mailing lists.
Some excerpts from the bug: The proposal from Paul Bredbury:
Hi, I propose that the following ebuild commands themselves *die* on
failure, because the vast majority of the time the emerge might as well be
considered a failure if such commands fail.
dobin, dosbin, doexe

Jason Stubbs called for consistency .. i.e making doman and dodoc also die
when nothing the file does not exist. A simple workaround in case an ebuild
is broken: [ -f xxx ]  dodoc xxx

SpanKY complained that he cannot set a custom die message then. But this is
not needed here, since every do* command can be clearly identified by the
argument and the directory it will be installed to.
Also as Paul suggested something like that would be possible for a custom
die message:
if [[ -n ${DIE_MSG} ]] ; then
echo !!! ${DIE_MSG}
fi

So, because we want no broken ebuilds and we want consistency I propose to
change this and fix possible problems. They are imo QA problems and should
be fixed.

So what do you think?

- Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Making dobin, doexe, doins, doman, dodoc die by default

2006-07-12 Thread Stefan Schweizer
Aron Griffis wrote:
 Stefan Schweizer wrote:  [Wed Jul 12 2006, 01:37:44PM EDT]
 This came up in Bug 138792 [dobin etc. should automatically die on
 failure]
 
 Since do* would become functions in this case, you'll have to fix the
 few ebuilds that use them on the RHS of xargs.
 
 grep -r --include \*.ebuild -E 'xargs do(bin|exe|ins|man|doc)' .

./local/layman/hanno-xgl/media-libs/mesa/mesa-6.5.1_pre20060620.ebuild: find
${S}/lib* -name '*_dri.so' | xargs doexe
./local/layman/hanno-xgl/media-libs/mesa/mesa-6.5.1_pre20060627.ebuild: find
${S}/lib* -name '*_dri.so' | xargs doexe
./media-libs/mesa/mesa-6.5-r3.ebuild:   find ${S}/lib* -name '*_dri.so' |
xargs doexe
./media-libs/mesa/mesa-6.4.2-r2.ebuild: find ${S}/lib* -name '*_dri.so' |
xargs doexe
./app-emulation/vmware-gsx-console/vmware-gsx-console-3.2.0.14497.ebuild:  
find man -name \*.\?.gz | xargs doman

 Assuming the list is relatively short, it should be acceptable to
 convert these to something like:
 
 doman $(find man -name '*.?.gz')

I just pinged MattM about vmware-gsx-console, and the x11 guys about mesa
and some minutes ago fixed timidity-eawpatches and speedtouch.

Thanks :)

- Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] New USE_EXPAND flag: FOO2ZJS_DEVICES

2006-07-11 Thread Stefan Schweizer
Hi,

As proposed in http://bugs.gentoo.org/show_bug.cgi?id=139987 I would like to
add a flag to the foo2zjs printer driver ebuild to select if everything is
downloaded or only parts. This makes sense to be done in a special
variable.

I want to use FOO2ZJS_DEVICES because that seems to be common, I have not
seen _DRIVERS somewhere yet and _CARDS does not fit.

Any objections?

Regards,
Stefan



-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Nominations open for the Gentoo Council 2007

2006-07-06 Thread Stefan Schweizer
Mike Frysinger wrote:
  - only Gentoo devs may be nominated

with that limitation in mind I want to propose some developers that are
doing a lot of work to improve gentoo:

AllanonJL for his gnome work
nichoj for the outstanding java-2 move
rl03 for his devdication to webapps
antarus for his treecleaners work
CHTEKK and sebastian for their php work

Thanks,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for July

2006-07-03 Thread Stefan Schweizer
Mike Frysinger wrote:
 On Monday 03 July 2006 15:41, Henrik Brix Andersen wrote:
 On Mon, Jul 03, 2006 at 03:04:55PM -0400, Mike Frysinger wrote:
  the entire point of these threads is to address developer concerns
  to that sunrise can be folded back into Gentoo

 Really? According to who?
 
 presumably the Sunrise guys considering they started the thread
 
Yeah, this is right. Sunrise is meant to be Gentoo.

 We only just had the userrel + sunrise meeting where the people behind
 Project Sunrise said they would continue the project as an unofficial
 project.
 
 Stefan would have to comment on this then
 
Yeah, we got frequent problems with offical/unofficial/suspended or not so
much suspended. Consequently to sort out this issue we came to the
conclusion to make it fully unofficial in the meeting. It works this way
but it is not how I wish Sunrise to operate. It needs to have approval and
that is why we discuss Sunrise and improve it constantly.

 Even if they have changed their minds about this, I think it is too
 early to re-evaluate the project for inclusion.
 
 maybe, but ignoring constant requests for feedback isnt helping anyone
 -mike

Agreed, and waiting does not help Sunrise either.

Best regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for July

2006-07-02 Thread Stefan Schweizer
Chris Gianelloni wrote:
 What exactly is there to discuss about this?
Evaluating our progress with hashing out the details etc.

 It is not an official 
 project anymore, so the council really has no bearing on it.  I'm
 guessing you would like for it to become an official project.
correct.

 If I were 
 asked, some of the things I would bring up are:

 What has the existence of Sunrise done for Gentoo?
- We have formed a #gentoo-sunrise channel with an atmosphere of help and
friendliness
- We are teaching many people how to write ebuilds correctly and how to use
repoman to check for QA problems, etc.

 What new packages 
 are now in the tree because of it?
For example I have added a fix for ftpd and libvc to the tree. I also bumped
media-video/dvd-slideshow. Markus Ullman added net-analyzer/wireshark from
a sunrise contributor, drchandra, to portage.

 What new developers have been 
 recruited because of it?
Recruiting is a long-term goal. We already have a two people that have done
the ebuild quiz, one other is working on it. It is like release work: they
will be released as developers when they are ready. I do not
want alpha-developers on the tree. And no, we will not reveal the release
date ;)

 What packages that were previously without 
 maintainers in the tree have found maintainers due to Sunrise?
I mentioned a few packages above where I fixed bugs because of sunrise
people, that does not mean they found maintainers, but people care about it
and I can commit their fixes if needed.

 I think you fail to see that for something like Sunrise to prove itself
 as a viable Gentoo project, it has to actually accomplish some of its
 stated goals.
Looking up the stated goals in the cvs log:
http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/sunrise/index.xml?hideattic=0view=markup
 encourage users to write ebuilds
 find new recruits
 make maintainer-wanted ebuild access and development easier
 work with users on new ebuilds and explain them what they can do better
We have only found potential recruits but at least those four have been
reached.

 That being said, if the council wants to discuss it, they're more than
 welcome to.  I just personally feel it wouldn't be time well spent.
Not discussing is not a solution either. The last userrel-meeting about
sunrise was very successfull. If you want we can make another meeting and
talk about it together before the council meeting? I would love that, to
hear some more about your ideas for the stated goals of Sunrise and get
issues sorted out without (perceivedly) offensive mails on the developer
mailing list.

Best regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Monthly Gentoo Council Reminder for July

2006-07-01 Thread Stefan Schweizer
Hi,

Can we have another Sunrise discussion please? I would love to have some
feedback about Sunrise, about our progress and where we are still lacking.

Thanks,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Re: [experiment] Sunrise try 2

2006-07-01 Thread Stefan Schweizer
Luca Barbato wrote:
 Add support for QA checkers clientside and serverside (there are
 precommit hooks you can use for that)
 
 That way we will avoid those smart problems as described in irc long ago.


Yeah this is now supported, the script has been greatly improved by
shillelagh, thanks go to him. It is now named sunrise-commit. We are always
working on improving it, so comments are welcome :)

Serverside checks are overkill imo since we check that later ourselves when
reviewing. It is also harder to implement in general and especially now
because the administrator of the server, jokey, has exams this week.

Best regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: [experiment] Sunrise try 2

2006-06-29 Thread Stefan Schweizer
Mike Frysinger wrote:
 after looking at some acl stuff i'm 99% sure this can be done ... so can
 we get this setup ?
 
 in fact, gentoo-wiki.com has a section on doing apache2/svn/dav/acls
 -mike

anonymous checkout is already disabled for some time now:

svn co http://gentoo-sunrise.org/svn/sunrise does not work whereas

svn co http://gentoo-sunrise.org/svn/reviewed works.

I do not know how jokey technically did it, but it was apparently easy :)

The website listing the content of the overlay and referring to the bugs and
herds probably has to wait after jokey's exams which will be next week.

I have made a small svncommit.sh script to make committing easier. But it is
probably not complete yet:
http://gentoo-sunrise.org/svn/reviewed/scripts/svncommit.sh

Need to work on that more with feedback from contributors.
Do you have anything else I can do?

Best regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: [experiment] Sunrise try 2

2006-06-25 Thread Stefan Schweizer
Luca Barbato wrote:

 Edward Catmur wrote:
 On Sat, 2006-06-24 at 13:05 +0200, Luca Barbato wrote:
 (from critics)
 - What is wrong with the model (each point 2 lines at least, 4 at most)
 - What you'd do as alternative as the criticized point ( 2 lines again)
 
 Let me reformat a bit

 
 Critic 1
 * Simplicity: The FAQ claims that Sunrise is simpler than Bugzilla. It
 is - for users. Contributing is a lot more involved than with Bugzilla;
 Sunrise is supposed to be about making contributing easier.
 
 Reply 1
 - Admit this in the FAQ. Where possible, write svn wrappers to make the
 contributing process easier.

I have added something to the answer in question, if it does not go far
enough I would appreciate a better rewording from you :)
But in contrast to that it requires more knowledge and tools to get
something into sunrise - more work for contributors. Also contributors have
to get their ebuilds reviewed before committing - bugzilla is easier here.

For wrappers: I am working on a svncommit.sh to generate the digest and svn
commit the ebuilds. This is certainly high on the TODO list :)

 Critic 2
 * Security (from malicious contributors): Glad to see layman will only
 track the reviewed/ tree; still, anyone who checks out the sunrise/ tree
 (and has it in PORTDIR_OVERLAY) is vulnerable.
 
 Reply 2a
 - Remove from the examples any suggestion that one should check out the
 whole tree when contributing.

A contributor needs the whole tree, because of the scripts/ and the
profiles/ directory as well as skel.ChangeLog. For 2b I have added an
explicit warning, I think it covers this as well.

 Reply 2b
 - Point out that one should not svn up sunrise/ as part of updating
 Portage.

right, I added the following:
The copy of the sunrise you will checkout here is '''not reviewed'''.
Handle with extreme care. Do not use this as your PORTDIR_OVERLAY! Keep
using your reviewed layman copy for PORTDIR_OVERLAY.
 
 Reply 2c
 - sunrise/playground won't let anonymous fetch.
Yeah, this is certainly easy to do and increases safety. I have been bugging
jokey about this already :)

 Critic 3
 * Conflicts between contributors (technical): Alice adds an ebuild; Bob
 makes a change; Alice makes another change and discovers it conflicts
 with Bob's change in the repo. Alice has not used subversion and doesn't
 know how to resolve conflicts.
 
 Reply 3a
 - People are supposed to learn svn in order to contribute.
since we use the IRC channel for contributing, I think this is a non-isssue
because devs in the IRC channel know subversion and can help out. Learning
by doing is preferred.

 Reply 3b
 - Tutorials will be provided about conflict resolution
see #3a, I do not want to write too many docs that are not often needed and
easily explained in IRC.

 Critic 4
 * Conflicts between contributors (social): Alice adds an ebuild; Bob
 makes a (maybe obvious) change; Alice thinks the change is incorrect,
 and, feeling that the ebuild is her property, reverts the change. A
 revert war erupts. Many casualties.
 
 Reply 4a
 - Create a social structure to enable Alice and Bob to communicate and
 resolve their differences of opinion. Forums? Wiki? IRC? Bugzilla? I
 would argue there should be One True location for this to occur; not
 bugzilla (bugspam); not IRC (impermanence).
IRC is certainly a good and direct way of doing this and it has worked in
the past for us, when we already had a similar conflict. Now you say that
IRC is impermanent, where do you see the problem, can you elaborate that a
bit for me, please? We are open here. Currently there is no forced way of
communication - everyone can chose how to communicate himself.

 Reply 4b
 - ban warmongers.
this can always be done, but it is a last resort that is hopefully not
needed. Of course when someone behaves badly action will be taken.

 Critic 5
 * More to keep track of: With bugzilla you have a single URL, from which
 you receive threaded email updates. Sunrise adds /two/ svn directories
 plus whatever is used for discussion.
 - Create a summary page that links to bugzilla and discussions, and
 tracks versions and changes, and all other relevant information. Allow
 (require?) contributors to subscribe to email updates from the summary
 page.
Yeah, this is also on our TODO list, currently we have a script for that:
scripts/create-stats.sh - it currently lists only bug entries and herds,
devs on CC for packages in the overlay. A more extensive version of that
needs to be put on a web page, right.
For updates:
Every ebuild-committer is required to CC to the bug, important ebuild
updates need to be mentioned on the bug, I think a second
update/notification system would be overkill here and leave out people that
only use bugzilla.

 Ed if you think this doesn't show your ideas please send another using
 this format.
I changed some things back where I wanted to answer Ed directly. Sorry to
differ a bit from the format, but I think it is important to explain and
get things sorted here. 

[gentoo-dev] documentation update: emake install instead of make install

2006-06-22 Thread Stefan Schweizer
Hi,

I am referring to this thread here, please make sure you read it in case you
have not already:
parallel fun in src_install - going beyond the serial monotony of 'make
install'
http://thread.gmane.org/gmane.linux.gentoo.devel/38901/focus=38901

Since nobody has objected there I would like to update the documentation to
reflect this change. I have attached a patch to do this for skel.ebuild and
sent a patch to plasmaroo for the devmanual. Is there any other
documentation that needs updating?

- Stefan Schweizer


--- /usr/portage/skel.ebuild2006-06-20 20:05:18.0 +0200
+++ skel.ebuild 2006-06-22 17:43:00.0 +0200
@@ -134,23 +134,27 @@
# anything outside of DESTDIR; do this by reading and
# understanding the install part of the Makefiles.
# This is the preferred way to install.
-   make DESTDIR=${D} install || die
+   emake DESTDIR=${D} install || die emake install failed
+
+   # when you hit a failure with emake, dont just use make. It is
+   # better to fix the Makefiles to allow proper parallelization.
+   # If you fail with that, use emake -j1, still better than make.
 
# For Makefiles that don't make proper use of DESTDIR, setting
# prefix is often an alternative.  However if you do this, then
# you also need to specify mandir and infodir, since they were
# passed to ./configure as absolute paths (overriding the prefix
# setting).
-   #make \
+   #emake \
#   prefix=${D}/usr \
#   mandir=${D}/usr/share/man \
#   infodir=${D}/usr/share/info \
#   libdir=${D}/usr/$(get_libdir) \
-   #   install || die
+   #   install || die emake install failed
# Again, verify the Makefiles!  We don't want anything falling
# outside of ${D}.
 
# The portage shortcut to the above command is simply:
#
-   #einstall || die
+   #einstall || die einstall failed
 }

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: [RFC] Useflags: qt, qt3, qt4?

2006-06-21 Thread Stefan Schweizer
Caleb Tennis wrote:
 I would personally like to stay with just the qt use flag.  The use flag
 will be for support of whichever version of Qt is supported (v3 or v4) for
 the particular emerge.
 
 In the cases where more than one version is supported, it should be for
 Qt4 only.  The Qt3 version should be a separate emerge.  For example, in
 the case of the poppler bindings, there should be a poppler-bindings-qt3
 package.

The problem here is that a user cannot just say at one point I do not want
any more qt3 packages on my system. He will need a
big /etc/portage/package.use list to do it. That is the same problem I
currently have with gtk1 - I would like to avoid it for qt.

Considering we only have 36 packages [1] with a qt useflag it will be fairly
easy to convert them to a qt3/qt4 version system that makes sense to
everyone and allows easy enabling/disabling of only qt3 or qt4.

[1] http://gentoo-portage.com/Search?search=use=qt

this scheme also allows some people to disable qt4 just with USE=-qt4 and
mask it. Any optional qt4 interfaces wont be built then. With only a qt
useflag this would require a package.use list again.

Can we think about it again? 36 packages is less than half what currently
still uses gtk1 in the tree. Doing it right for the users is better than
doing it easy for the package maintainers.

Thanks,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: [RFC] Useflags: qt, qt3, qt4?

2006-06-21 Thread Stefan Schweizer
Caleb Tennis wrote:

 On Tuesday 20 June 2006 12:40, Stefan Schweizer wrote:
 Hi,

 with kde4 approaching and the new Qt-4 being in the tree we suddenly see
 the same problems that gtk had with the gtk2 flag again.
 
 I think there's a lot of good thoughts surrounding how to handle this. 
 There are 2 categories of packages we need to concern ourselves with:
 
 1) A package can optionally add support for Qt3 or Qt4 (such as dbus).
 
qt3 and qt4 is being used there already and it is obvious

 2) A package requires either Qt3 or Qt4 (both not both?...such as
 x11-libs/qwt-5).


qt3 - enable optional qt3 support
qt4 - enable optional qt4 support

when both are possible its the maintainers decision, would look something
like this:

qt4? ( =x11-libs/qt-4* )
!qt4? ( qt3? ( =x11-libs/qt-3* )


Why you ask? Because a user does not care if packageX uses qt3 or qt4, he
just wants to use it.

But why do we have two useflags then?
Because the user should be able to disable optional support for either qt3
or qt4 or both for every package.

Disabling all optional qt4 support is only conveniently possible with a qt4
flag. Same for qt3.
We need separate flags here, otherwise you can just use one flag for
everything, it does not make sense to have two flags when one cannot be
used because the other is ambiguous.

 Solution: Build against qt4.  If you want to provide the same package for
 the qt3 version, add a new package to portage I suppose.

This add a new package to portage is not really the gentoo spirit of
following upstream tarballing, in my opinion.

 In the end, this is just merely suggestion.  I think each maintainer
 should come up with the best way to handle the situation unless someone is
 going to GLEP this.

We have 36 qt-use-packages, so we could have 36 different flags in the
end ;)
Trying to reach a consensus on the mailing list is a better idea imo.

 I think we should, however, do our best to avoid a situation where we have
 some ugly combination of USE=qt -qt3 or USE=qt4 -qt qt3...

right you are. And since we already have a qt3 and a qt4 useflag in the tree
it is a good move to do this right.

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] [RFC] Useflags: qt, qt3, qt4?

2006-06-20 Thread Stefan Schweizer
Hi,

with kde4 approaching and the new Qt-4 being in the tree we suddenly see the
same problems that gtk had with the gtk2 flag again.

I am currently using the flags that way:
[ebuild   R   ] app-text/poppler-bindings-0.5.3  USE=cairo gtk qt qt4 0 kB

so qt = qt3. Now that scheme will sure break when people start using the qt
useflag for applications that only use qt4. Now cardoe thinks a qt3 useflag
would make sense to disable qt3 support easily:

sys-apps/dbus-0.62  USE=X gtk mono python -qt3 qt4 -debug -doc 0 kB

I do not think it there should be different useages of the qt, qt3 and qt4
useflag all over the tree, so there are a few options:

1) enable qt4 and qt3 by default when both are possible, and merge the qt4
and qt3 useflags currently in the tree into one qt useflag. What we lose
here is use.masking qt4, I think this will only be an option when qt4 is
marked for all architectures that qt3 is marked for.

2) use qt for qt3 only and a special qt4 for qt4. This is what I did
originally and it makes sense if done right. However when paackages with
qt4 start using the qt4 useflag you can no longer do USE=-qt to disable
qt3 and the concept breaks.

3) split the qt flag into a qt3 and a qt4 flag. This allows users to
specifically pick qt3 or qt4 and the flag meanings are obvious - downsides
are it is a lot of work.

4) do nothing and happyly use the qt useflag for qt3 or qt4 as well as
sometimes a qt3 useflag or a qt4 useflag, just how the maintainer likes
it :) This is also not that bad since we do not need to set any rules here.
But it might be confusing and makes it impossible to disable all qt3 uses
or all qt4 uses

Currently we are at 4), should we change anything?

Regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Sunrise: way forward, semi-official, review

2006-06-17 Thread Stefan Schweizer
To my fellow developers and users,

with the council meeting not much has changed for Sunrise:
Sunrise is still suspended/closed in overlays until the details can be
hashed out

And that is what we are doing now. We have moved the overlay to
gentoo-sunrise.org to analyze, improve and hash out the details. So the
Sunrise project is now semi-official. While being an official Gentoo
Project run by Gentoo developers it is not currently hosted on gentoo.org.

We have also implemented review and added the overlay to layman. It works
like follows:
- users are only able to commit to sunrise/
- developers merge the commit to reviewed/ when they are happy with it
review/ is what is available in layman.

Adding ebuilds from bugzilla is regaining speed and we are looking for new
developers and users to help this project grow. Just drop by in
#gentoo-sunrise if you want to help reviewing or have comments and
suggestions.

Kind regards,
Stefan Schweizer

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] embedded overlay on overlays.gentoo.org

2006-06-17 Thread Stefan Schweizer
Hi,
solar has requested an account on overlays.gentoo.org for the embedded
overlay for you.
Your password: DX7wnSe40Y

Kind regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: embedded overlay on overlays.gentoo.org

2006-06-17 Thread Stefan Schweizer
Seemant Kulleen wrote:

 On Sat, 2006-06-17 at 18:04 +0200, Stefan Schweizer wrote:
 Hi,
 solar has requested an account on overlays.gentoo.org for the embedded
 overlay for you.
 Your password: DX7wnSe40Y
 
 Kind regards,
 Stefan
 
 
 Was the list the intended recipient of this?
 
no, of course not. I wonder how it ended up there - the password is changed
and mailed to the right recipient now :)

Probably we should move to a key-based system for committers that are
already developers?

- Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: embedded overlay on overlays.gentoo.org

2006-06-17 Thread Stefan Schweizer
Ned Ludd wrote:
 On Sat, 2006-06-17 at 18:04 +0200, Stefan Schweizer wrote:
 Hi,
 solar has requested an account on overlays.gentoo.org for the embedded
 overlay for you.
 Your password: DX7wnSe40Y
 think you can change my pw and lets do this offlist?

lol, you have not read accurately. The account was requested by you, it is
not your account :)

- Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Re: Re: Project Sunrise thread -- a try of clarification

2006-06-15 Thread Stefan Schweizer
Mike Frysinger wrote:

 On Friday 09 June 2006 15:01, Stefan Schweizer wrote:
 Chris Gianelloni wrote:
  Everyone that you happen to include as allowed to actually commit, you
  mean.  As opposed to everyone that can sign themselves up for
  bugzilla?
 
  It is designed to be more open and more easily fixable.
 
  Sure.  More open then a self-registering system.  Gotcha.

 We actually have a FAQ entry about that. See But there is access
 controls? Why is there access controls? on
 http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
 
 umm, that should of course read are instead of is ...
 -mike

I picked that up from wolf31o2, 08 Juni 2006 18:27:47:
.. Also, who is going to
control access to this resource?  Why is there access controls? ..

Seems I was wrong in thinking the native knows the language better ;)

Well, I will change it as soon as possible. Currently all the wiki and avn
are locked until the council meeting.

Thanks for the comment.

-Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Re: Project Sunrise -- Proposal

2006-06-12 Thread Stefan Schweizer
Thanks, I have worked in your ideas and made the +CC and bug-updates clear
in the HOWTO.

Kind regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Project Sunrise -- Proposal

2006-06-12 Thread Stefan Schweizer
Henrik Brix Andersen wrote:
 On Sun, Jun 11, 2006 at 06:53:51PM +0100, Stuart Herbert wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Henrik Brix Andersen wrote:
 | However, as has been pointed out several times in this thread already,
 | back when the devloper community agreed to the overlays project it was
 | also agreed that projects similar to what is now known as Project
 | Sunrise was not be present on overlays.gentoo.org.
 
 Can you provide a reference to this, please?  I've been through my -dev
 M/L archive several times, and cannot find an email where I agreed to
 this.
 
 Perhaps not in those exact words, I admit. But the general consensus
 in my eyes, and I'm not alone with this view according to other
 replies to this thread, was that the purpose of overlays.gentoo.org
 would be to provide a common place to host project and developer
 overlays - not a place to host Joe User's ebuild contributions (except
 for users regularly contributing to specific teams/herds and
 devs-in-spee). [1] [2] [3]
I think you misunderstand the Sunrise Project. I will tell you why the
Sunrise Project in fact complies to all these rules.

It only hosts ebuilds that have been reviewed by Gentoo developers or
directly committed by regular contributors that have taken the ebuild
quiz, we name them trusted committers. We have not yet fleshed out how it
works, but believe me we are watching the quality of the overlay and we
certainly will not let it rot.
You believe we do not have the manpower for this as you have stated in many
other threads. But currently we are coping well with the ebuild submissions
we get. Additionally #gentoo-dev-help is of big help for us.
All current contributors to the Sunrise overlay take effort to improve their
ebuild skills and listen to our words closely. I would consider them all as
devs-in-spee, I am personally planning to recruit some of them when they
have reached a certain level of ebuild writing. They are all around in IRC
(as noted in the [1]-mail by stuart you referenced).

 You could argue that Project Sunrise *is* a specific project. Fact is
 that nobody at that time could predict that a small group of
 developers would go ahead and create a project with the single goal of
 providing Joe User's bugzilla-contributed ebuilds to end-users through
 overlays.gentoo.org.

The Sunrise overlay hosts many ebuilds that do not have a herd in CC. It
also hosts ebuilds for herds that do not have their own overlay or are not
interested in recruiting new contributors. Herds who wish to work with the
contributor in a different way are already doing that, and we encourage
people to use existing herd/team-specfic infrastructure if there is one.

Quote from the FAQ
--Can I commit everything I like to the overlay?--
Herds could also have a better official overlay for herd related packages.
For example you should not add packages from the PHP overlay or concerning
PHP to the Sunrise overlay, rather ask for access to the PHP or Webapps
overlay and talk to those herds first, depending on where you feel your
package should go.
---
The Sunrise project catches all ebuilds that a specific herd does not have
the resources or interest in catching. We make sure that contributions have
a certain level of QA and are not ignored. As soon as a specific herd/team
wants to work on the ebuilds themselves we remove the ebuild from the
Sunrise overlay.

Our single goal is not to provide Joe User's ebuilds, we have more goals:
- provide a central home for contributed ebuilds that do not (yet) find a
place in the portage tree
- encourage users to write ebuilds
- find new recruits
- make maintainer-wanted ebuild access and development easier
- work with users on new ebuilds and explain them what they can do better
Those are also mentioned on our Project Page[1] 

 In my opinion, creating a new project with this purpose should not
 have been allowed. 
In what other form should we do something like this in your opinion. Should
we be recruiters or mentors? I think creating a project and listening to
and working in the many comments on the mailing lists was a good idea.

 I fear that perhaps creating the project was just 
 an attempt to circumvent the policy of overlays.gentoo.org, which
 states that only project teams and individual Gentoo developers can
 have an overlay on overlays.gentoo.org.
Sorry, how are we circumventing the policy? We want an overlay where more
than one person (me and jokey and the users) work together on improving
ebuilds. This is not sensible to do in a developer overlay. We need a
project overlay.

 It seems that the developers 
 who started Project Sunrise already planed to use overlays.gentoo.org
 as a free-for-all overlay with no QA and policy checks back when the
 idea of an official overlays project was discussed. [4] [5]

You are making two assumptions(free-for-all and no QA) that are no longer
true. Those may have been true with the initial announcement but we have
seen that the 

[gentoo-dev] Re: Project Sunrise -- Proposal

2006-06-12 Thread Stefan Schweizer
Daniel Ostrow wrote:
 3) a yes from herds required, keeping a timeout to avoid bugspam
 
 after a comment has been placed on a maintainer-wanted bug in bugzie,
 there's a grace time of two weeks for herds to either leave a comment on
 whether they're fine with take over or not. When this time is over and
 it is assigned to maintainer-wanted, then and only then it is implied as
 an OK to keep it also in the sunrise project.
 
 I'm 100% against implicit acceptance. If someone from the sunrise
 project wishes to add an ebuild to the overlay they should have to get
 an explicit OK from the team in question. 
we are not doing this, because we do not want to put more work on teams that
are overworked anyway. Everything that is assigned to maintainer-wanted in
bugzilla means that it wants a maintainer and has no maintainer. If not, it
would not have been assigned to maintainer-wanted. We are allowed to
maintain packages that want a maintainer without asking anyone. Especially
since we are removing the packages if any other herd shows interest.

 The sunrise project could of 
 course keep a list of teams that have given a blanket OK and of those
 that have totally opted out.
There are teams that have made very clear that they are not interested in
other people maintaining there packages. For example the games team does
not assign any bugs to maintainer-wanted. It is obvious to every
contributor that he cannot commit such packages, because they are not
assigned to maintainer-wanted. However it is still possible to ask the games
team to reassign the package to maintainer-wanted in order to get it into
the sunrise overlay. Alternatively we help the contirbutor then to get the
ebuild to quality so that the herd in question can commit it.

 For those teams in between an OK per 
 package sought by the sunrise project's team members is needed. 
Sorry, I think you are trying to kill our project with red tape. I do not
think it helps anyone to do more work.

 I'm 
 sorry but the leg work to track this stuff and get acceptance has to be
 100% on your projects head. 
Yes, it is currently. We are not requiring anyone else to take any action!
You are proposing to ask, that would generate a huge bugspam and require
many people to take action. We do not want that, sorry.

 Your proposal adds a need for me to actually 
 look at bugs for packages that I may have no interest in. 
no, absolutely not. You do not need to look at any bugs, in fact you are not
required to do anything for sunrise. We are just proposing it might be good
to give us a hint when you have a package that should be added to the
sunrise overlay.

 I don't pay 
 any attention to maintainer-wanted now I don't want to pay any attention
 to a subset of that ever.
That is good, and you do not need to. Why do you think that you would need
to do that?


 6) QA assurance
 
 Of course there are minor issues with the ebuilds, otherwise they could
 be committed straight forward. Important thing is that it only finds the
 way into overlaye if the trusted committers (project devs and users who
 are given permission explicitely, see above) are fine with it.
 Additional note on arch issues: initially, just ~x86 and ~amd64 may be
 set. The rest would need successful test reports for other ~arch
 keywords. Stable keywording isn't permitted at all, there will be some
 automated check to make sure no one does it (by accident) here.
 
 Additional note: we won't start adding this to layman and making it
 available easier until the QA checks have been implemented.
 
 Erm...no! See that is the thing about item #1 on my list...there is
 nothing preventing Joe User from checking out the overlay and adding say
 a ppc64 keyword or a mips keyword to ${random_ebuild} meaning that bugs
 *will* be generated for arch teams for packages that are not in the
 tree.
I still do not get why there will be bugs generated?
Nevertheless the overlay ebuilds are mainly from users, thus being
_unsupported_ and _experimental_

 Also note I'm not talking necessarily about the Hey, I installed
 ${package} and it broke. bugs because if ${package} isn't in the tree
 bug-wranglers can catch it and off you go...the arch teams aren't
 involved. What I am talking about is Hey, my ppc64 started doing weird
 things yesterday, ${daemons} are no longer working. having that bug
 assigned to the arch team, and then spending a long time only to track
 down that the user installed some random library from sunrise seven days
 ago and there just happened to be upgrades to programs that took
 advantage of said library in unexpected ways.
Sorry, I think you are drawing a very unlikely situation here. If such thing
ever happens (a library that can be used by in-tree ebuilds) we will of
course add that to the tree. It is not our nor anyone else's intention to
break the tree.
Also the same can happen for in-tree libraries that are not ppc64 and even
for libraries that are from a third party overlay not controlled by gentoo.
It 

[gentoo-dev] Re: Re: Project Sunrise -- Proposal

2006-06-12 Thread Stefan Schweizer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris Gianelloni wrote:
 On Mon, 2006-06-12 at 15:19 +0200, Stefan Schweizer wrote:
 You've broken this one before, so I just want to point it out to you
 again.
The bug was of course discussed in IRC with the games team and the lead in
advance. I wonder why no one of the recruiters insisted in this important
step and added the team lead to CC. Anyway, I am sorry for not adding the
team lead explicitly to CC, my excuses, this breach of policy was not
intended.

 Anyway, I'm just reminding you 
 to make sure that the team wants/needs help before you go recruiting
 people for a team you're not even a member.  It'll make things much
 smoother and you'll get much less resistance.
Thank you very much :)
But imo contributors who aim to join a specific team are usually recruited
within that team. Usually there are specific project overlays then.
Currently it looks like sunrise-users would join without becoming part of a
team.

Very valuable comment indeed, thanks. I will take that into account when I
file my next recruiting-bug.

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

iD8DBQFEjYdONJowsmZ/PzARAr01AKCE9DJPPfd65W4zCFjmXYUw1KGIqgCZATFg
5IoKFUahr3E+DHAyDGju9a0=
=aN5C
-END PGP SIGNATURE-

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Project Sunrise -- Proposal

2006-06-11 Thread Stefan Schweizer
Peter wrote:
 Um, there are numerous new not-in-portage-tree ebuilds submitted to bz
 which have been assigned to teams. However, they may still languish. They
 were assigned by the wranglers, and not improperly. Yet, for many reasons,
 the bugs wait. So, will there be a mechanism for a contributor to get an
 ebuild uploaded to sunrise in this circumstance?

You need to ask a team member then to move them to maintainer-wanted.
Usually the teams have no problem with moving bugs over to
maintainer-wanted because they know that they cannot maintain everything
themselves.


 I would also suggest having some sort of review process for inclusion of
 m-n/m-w bugs. Some may not have any relevance (i.e. the program is no
 longer supported, or the upstream project has been incorporated into a new
 one, or the version of dated). Doing a blanket import of m-w bugs could
 make quite a mess of things IMO.
This is volunteers work and usually volunteers are only moving over the
ebuilds they use themselves. We are not doing this in a general way, but on
a per-user per-package basis. We do not plan to run any importing scripts.
It will only be done if a user or developer is interested in it :)

 One of the terrific benefits of sunrise will be the cleaning out of
 bugzilla. Nuking open bugs is an especially satisfying experience!

Sorry, we are not doing this. We are assigning a bug to every sunrise ebuild
to make sure that it can be discussed there and is still easily searchable.
 
 Lastly, what about user contributions? Will users require some kind of
 sponsorship in order to have their ebuilds posted? What will the procedure
 be (or did I miss it in one of the hundreds of emails)?

see 5) from Markus' email. You just need to have a good ebuild contribution
that we can review with you, You will not gain full access but it is a
start.

- Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Project Sunrise -- Proposal

2006-06-11 Thread Stefan Schweizer
Dan Meltzer wrote:
 On 6/10/06, Markus Ullmann [EMAIL PROTECTED] wrote:
 2) Not one large tree but subdirs, one per herd

 to help herds better keeping track of which parts are alive in the
 overlay, each herd's ebuilds are grouped in a subdir, e.g. there will be
 a netmon/ dir with net-analyzer/specialapp below it.

 
 If its unofficially part of a herd, then isn't it no longer a m-w/m-n
 ebuild?

I think you are right, see my answer to the threadstarter to find a solution
that works without subdirs.


 I think this is a much improved//thought out version of the proposal.
 From the looks of things sunrise should never make it to layman
 however, because as we all know, anything that makes things more
 easily accessible to users is going to be (mis)used by more of them.
 From what I understand, you see Sunrise as an overlay for users to
 improve their ebuilds because they are insufficient quality to be in
 the main tree.  If they are of this poor quality, they should be no
 where near users hands, this doesn't make sense.

We will yet have to see if quality will be that bad. I want some more time
to see how the ebuild quality works out before we make it more publically
available.

 If on the other hand you saw sunrise as a way for more packages to be
 available to users due to there being a lack of maintainers, asking
 herds to check out ebuilds as part of the proposal seems
 counterproductive to the cause.

They do not have to. It is just nice to let us know that they would like to
see a package in sunrise.

 Maybe you should expand on the goal of the sunrise project, what
 exactly do you want it to do?
The Sunrise Project goals may change, it is not yet running long enough to
know about all the effects and the goals. Because of this, I cannot give
you an exact definition now, sorry.

our goals include for example:
- encourage users to write ebuilds
- get new recruits
- make maintainer-wanted ebuild access and development easier
- work with users on new ebuilds and explain them what they can do better

I think these are working out quite well currently, I hope it helps you.

Regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Project Sunrise -- Proposal

2006-06-10 Thread Stefan Schweizer
Markus Ullmann wrote:
 2) Not one large tree but subdirs, one per herd
 
 to help herds better keeping track of which parts are alive in the
 overlay, each herd's ebuilds are grouped in a subdir, e.g. there will be
 a netmon/ dir with net-analyzer/specialapp below it.

A better solution is mentioned in the FAQ

--snip--
I want to see all the ebuilds in sunrise that affect my herd, is that
possible?

Yes, we have hacked up a script in scripts/create-stats.sh for the moment,
that will give you all packages, bugs and CC:

sys-auth/pam_skey - bug 55279 - on CC: jakub pam-bugs taviso
maintainer-wanted

You might want to run it with your herd or maintainer as argument to get
filtered output:

scripts/create-stats.sh pam-bugs

--snap--

If there is real interest in subdirs for other reasons than listing packages
by herds I would like to hear them. For the moment we are still discussing
everything as mentioned on the wiki:

WARNING: This is currently under creation and review - fundamental changes
may still take place

Please work with us in IRC to make it please everyone.

- Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Project Sunrise -- Proposal

2006-06-10 Thread Stefan Schweizer
Marius Mauch wrote:

 On Sat, 10 Jun 2006 13:37:15 +0200
 Markus Ullmann [EMAIL PROTECTED] wrote:
 
 Okay, so after figuring out open problems (thanks to kloeri and
 various other people for help here), we now have a resolution that
 should satisfy all involved parties here. This should adress
 dostrow's demands as well.
 
 1) m-w / m-n requirement
 
 Only ebuilds that are reported to bugzie (valid bug#) and set to
 maintainer-wanted are allowed here as well as maintainer-needed ones.
 
 maintainer-needed are only allowed if they're removed from the tree
 and moved over to sunrise (and thus end up as maintainer-wanted
 again).
 
 5) commit access to the overlay
 
 We implement two levels of commit rights:
 
 1. As there are people out there who just want to maintain one app for
 start, the ebuild should reach a level that project devs are fine with
 it, then the user is given permission to commit on that single app. An
 automated check makes sure that he doesn't commit anywhere else. If
 violations arise, the access is revoked immediately.
 
 2. People who contribute good ebuilds over a certain period of time
 are allowed upon decision by project devs to actively help
 maintaining the project. They'll be given commit rights for the
 project then. Same frome above applies here: If we notice any abuse,
 we revoke access immediately.
 
 One more rule I'd like to see (should be obvious, but better to write
 it down):
 
 People who commit to a certain project/ebuild have to be on the CC
 list of the relevant bug report(s) and any important commits should be
 documented on the bugs (including the revision of/link to the commit).
I have not made it a rule yet to prevent whitespacing and updates for minor
changes, also I would like to leave things like that to the people to
decide to prevent that too many rules lock us in.
How far would you want to go? Update for I have removed some quotes for I
have made a version bump?
Currently it is written down as follows:

http://overlays.gentoo.org/proj/sunrise/wiki/HowToCommit, point 6
--snip--
6) For later updates to the package in the overlay it is still considered
good style to update the bug and link to the changes, for exmaple:

I added some sed calls, it should build with --as-needed now
http://overlays.gentoo.org/svn/proj/sunrise/sys-apps/openguru/openguru-1.ebuild 
--snap--
I think it should be at least changed from a suggestion to a you need to
for updates of ..
So,, my question, how far do you want them to go here?

- Stefan


-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Project Sunrise thread -- a try of clarification

2006-06-09 Thread Stefan Schweizer
Carsten Lohrke wrote:
 You should at least make it visible in bold letters on the overlay.g.o
 front page, what the conditions of each overlay are and which [EMAIL 
 PROTECTED]
 address bugs have to be assigned to. 


Please, do not assume our users being stupid. They know that they are using
an ebuild from the sunrise overlay with zero support. They deliberately
typed 

svn co http://overlays.gentoo.org/svn/proj/sunrise/category/application;
emerge application

And also there are only applications from maintainer-wanted or
maintainer-needed allowed in the overlay. Because packages are not supposed
to overwrite files from other ebuilds it is unlikely that they can cause
any damage to applications that have not been directly installed from the
overlay.

 Also some warning that an overlay may
 break the tree or fubar the users system 
That is not the intention of the overlay. Everyone can help fixing breakage,
it is not like with the current tree, where you have apps broken for a few
days, weeks or even months because the maintainer is unreachable. With
fixes (by users) spread all over bugzilla.
It is designed to be more open and more easily fixable.

-Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Project Sunrice: arch team perspective

2006-06-09 Thread Stefan Schweizer
Stephen P. Becker wrote:
 Starting a new thread here for a new angle...
 
 As Stuart mentioned, bugs for any ebuild on o.g.o would go through
 Gentoo bugzilla.  
Yeah, as there is usually a bug report for maintainer-wanted and
maintainer-needed bugs it wont hurt anyone.

 It seems like genstef and jokey have completely 
 ignored support from arch teams for this overlay.  What are you
 proposing with respect to arch keywords and package.mask? 
users are supported to do everything themselves in the sunrise overlay. We
are not trying to add any additional workload to your current one. We are
in fact trying to make life easier for everyone.

 Do you 
 actually expect us to do anything but close assigned bugs for sunrice
 ebuilds as WONTFIX? 
It is more like, explain the users how to fix it themselves, because they
can with the sunrise overlay.

 Where else would these bugs go except for arch 
 teams, seeing as we clearly can't assign them to end users who
 originally submitted the maintainer-wanted ebuilds?
These are not expected to be filed as bugs, they should be fixed by the
users in question.

- Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Sunrise Project -- Sunrise FAQ

2006-06-09 Thread Stefan Schweizer
Markus Ullmann wrote:
 Maybe that way we avoid any misunderstandings, nearly doubled posts and
 repeating ourselves over and over again.

The problem is that some questions and answers easily get lost in a mailing
list. To solve this shortcoming, I am starting to make a FAQ page in the
trac wiki:
http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq

We are adding new questions there, if you have some additions, please talk
to me and I will add them for you.

Thanks,
Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Re: Project Sunrise thread -- a try of clarification

2006-06-09 Thread Stefan Schweizer
Chris Gianelloni wrote:
 Everyone that you happen to include as allowed to actually commit, you
 mean.  As opposed to everyone that can sign themselves up for
 bugzilla?
 
 It is designed to be more open and more easily fixable.
 
 Sure.  More open then a self-registering system.  Gotcha.
 

We actually have a FAQ entry about that. See But there is access controls?
Why is there access controls? on
http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

2006-06-09 Thread Stefan Schweizer
Luis Francisco Araujo wrote:
 Fine. I highly agree on that, now my question is,
 why this needs to be officially supported?

See
Why does this have to be on official gentoo hardware?

http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Re: Sunrise Project -- Sunrise FAQ

2006-06-09 Thread Stefan Schweizer
James Potts wrote:
 I do have a question:  If you're allowing just anybody who asks to
 have commit access to the repo, what guarantees can you give me that
 they won't commit something deliberately malicious or which will break
 the entire overlay to the overlay?

I have added this to the FAQ:
http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq#Howareyouensuringthatthereisnob0rken/maliciuscodegettingintotheoverlay

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Re: Sunrise Project -- Sunrise FAQ

2006-06-09 Thread Stefan Schweizer
Wernfried Haas wrote:
 - Ebuild development questions should for example be discussed in
   #gentoo-dev-help and I have seen threads about it on
 forums.gentoo.org and even helped there. There is no reason why
 questions about ebuild writing for the Sunrise overlay should not be
 treated equally.
 --snip--
 
 Maybe i wasn't clear enough in my previous mail (which may be the
 reason why it was simply ignored), but while we were taken by surprise
 of a new project being announced and no one talking to us about where
 this may fit in on the forums, this FAQ entry completely ignores what
 i explicitely asked for in the mail above.
 If you want to use the forums, that's fine and they are here to help
 with problems, but deciding things without approaching us to find a
 solution that also fits into our forums structure makes me have
 reasonable doubts how this project will integrate into Gentoo.

I actually was trying to adress your issues with that FAQ entry, sorry if
you feel like I have decided something. Please give me a reasonable
rewording if you think my assumption is not correct that this will be
treated equally by forums users (I count me in here, that is why I made the
assumption).
I will of course explicitly forbid any forums activity in the FAQ when you
have a problem with that.

- Stefan

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Re: Re: Sunrise Project -- Sunrise FAQ

2006-06-09 Thread Stefan Schweizer
Anders Hellgren wrote:
 What the faq entry didn't say, and what amne asked for in his previous
 e-mail was that questions related to ebuilds not distributed as part of
 the official tree should be posted to the Unsupported Software forum [1].
Yes


 We have neither reason nor desire to treat sunrise ebuilds differently
 from other user contributed ebuilds.
Yeah, I was just taking ebuild related questions in account. Of course
useage questions are only valid in an Unsupported Software forum

I added:

- For useage questions the Unsupported Software forum on forums.gentoo.org
is the right place

- Stefan

-- 
gentoo-dev@gentoo.org mailing list



  1   2   >