Re: [gentoo-dev] [RFC] i18n project

[Peter Volkov (pva)]

On Сбт, 2006-06-10 at 15:11 +0200, Jan Kundrát wrote:
> a) Translation of metadata.xml stuff in our tree (Is there any method to
> keep them up-to-date when the English text changes? Something like
> "revision" attribute that gets bumped when the English text gets updated?)

While we do not have "version" or "revision" attribute, just drop all
translations whenever you update English.

> c) l10n for other packages and sending patches upstream
> d) Translation of manpages. man-pages-cs for example sucks :(.

Do we really need to do this inside Gentoo i18n project? This tasks are
common for many distributions and should be done outside Gentoo. So just
translate and send translations upstream.

> e) Translation of our documentation (that's the GDP's job, the intention
> is just to "share human resources" :) ) and GWN.
> 
> f) Translation/localization of w.g.o. Efforts were already started
> (meaning that "the technology is available on at least one experimental
> site).

Opposed to c) and d) this requires organization inside Gentoo and thus
requires i18n project. Fex, to increase the profit from translated GWN
translated versions should come out together with English one.

> e) Persuading people that having comments in configuration files
> *without* an equivalent somewhere on the web is evil. Good example might
> be baselayout. Why? Stuff on the web can be translated pretty easily,
> configuration files can't.

Personally I do not like idea to look at web for package documentation.
There already exist decision to put all example files somewhere
into /usr/share. I hope one day this happens and then all translated
configuration files also can be put there.

I think the main goal of i18n should be not translation but organization
(at least at first time). Untranslated staff will always remain because
devs have lack of time/interest and project can nothing to do with that.
But people post bugs with translated metadata, translated documentation
and to resolve them we need place to find the right devs for this. And
i18n project is the right place to look for them.

Peter.


signature.asc
Description: This is a digitally signed message part

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

[Luis Francisco Araujo]

Patrick Lauer wrote:

On Fri, 2006-06-09 at 16:14 -0400, Chris Gianelloni wrote:
  

How exactly is it easier to manage a large number of ebuilds versus a
small number?


It is easier to manage one large overlay than managing 35 small overlays.
Communication overhead, duplication of effort, ...

  
How many people will manage the big overlay? , How many ebuilds will 
this overlay have? ,
now compare that to the amount of people maintaining the small overlays 
and their number

of ebuilds.

Which one is easier now?

Note: And i am omitting all that part of who are maintaining the 
ebuilds?, how they are maintaining them?,
what kind of ebuilds they are maintaining?, and many many other details 
that probably immediately kill
the assumption of a big overlay being easier than 35, 40, 90, 500 
smaller overlays.



--
gentoo-dev@gentoo.org mailing list

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

[Kevin F. Quinn]

On Sat, 10 Jun 2006 10:27:29 -0400
Chris Gianelloni <[EMAIL PROTECTED]> wrote:

[lots of good stuff - +lots Chris]

> Not so many moons ago, new ebuilds were submitted to bugzilla.  The
> bug wranglers would assign the bugs to the team most likely to end up
> as the maintainers, and new ebuilds either made it into the tree, or
> sat in bugzilla until the interest was there for it to be added, if
> ever.  Some people felt that this process left lots of packages in
> bugzilla, with no one to watch over them.  Because of this, the
> maintainer-wanted, and maintainer-needed bugzilla accounts were
> created to assist in tracking these bugs/packages.  This was a good
> idea at the time, and worked fairly well so long as there were
> developers going through and actively searching for bugs, that were
> no longer assigned to the relevant teams, but instead, assigned into
> some big dumping ground for new package requests.

I think it's clear that the maintainer-wanted/maintainer-needed hasn't
actually solved the problem it was trying to address. While it has
improved on some counts, I think the fact that herd maintainers
are not watching those aliases means that new builds are not being
brought to the attention of the devs most likely to take them on.

Instead of having sunrise on gentoo.org, which I agree with Chris is
fundamentally a bad idea, could we simply go back to assigning new
builds to the most relevant herd alias, but also add
maintainer-wanted/needed to the CC:?  That way some responsibility is
assigned to the herd to deal with it one way or another. If the
herd does not have the manpower to deal with it they can just reassign
to maintainer-needed and CC the herd, indicating they need someone
to join the group of herd maintainers to take the package on. With
maintainer-* on CC the benefits accrued so far from having a bunch of
people helping to iron out early QA problems would remain, and at the
same time the group of people most likely to pick up the package would
also be aware of it.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] i18n project

[Peter Volkov (pva)]

On Вск, 2006-06-11 at 02:16 +0200, Marius Mauch wrote:
> On Sat, 10 Jun 2006 15:11:50 +0200
> Jan Kundrát <[EMAIL PROTECTED]> wrote:
> > b) Localization of Gentoo-developed applications (portage,
> > gentoolkit,...) including their manpages
> 
> I don't really like this one. Documentation, sure, but for the tools
> themselves I think it could cause more problems than actually help.

IIUYC there are tree problems with localized portage tools: 1) for users
such bug reports are hard to search 2) for devs it's hard to read
localized bug reports 3) "Overtranslation" for all it's hard to
understand. Right?

1,2): While generally I agree that output of build process should be in
"C" locale at least the following line should be translated on all
possible languages:
!!! If you need support, post the topmost build error, and the call
stack if relevant.

Everybody will benefit from translation of this message. ;)

3) Bad translation is "just another bug" that should be fixed. Nothing
in reality can be done without errors. But have this stoped anybody?

Peter.


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] i18n project

[Nguyễn Thái Ngọc Duy]

On 6/10/06, Jan Kundrát <[EMAIL PROTECTED]> wrote:

So, let's rephrase it a bit. The following items represent my view about
the i18n team's responsibilities:

a) Translation of metadata.xml stuff in our tree (Is there any method to
keep them up-to-date when the English text changes? Something like
"revision" attribute that gets bumped when the English text gets updated?)

Keep only English in metadata.xml. Using tools such as intltool or
xml2po to extract strings and let i18n translate/maintain .po files
themselves. Generated .mo files will be included in metadata directory
when rsycing. Another portage hack to use .mo files in metadata
directory instead of plain English if locale variables is not C.

But that's just part of the problem. What about strings inside ebuild?
--
Bi Cờ Lao

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Dealing with /var/cache on unmerge

[Jakub Moc]

Daniel Drake wrote:
> Mike Frysinger wrote:
>> maybe give ebuilds a way to maintain a list of files that portage
>> should nuke when unmerging the package ...
> 
> Something similar to this would be useful for kernel ebuilds, as simply
> unmerging kernel source will leave a load of temporary and object files
> on the filesystem.
> 
> Daniel

Already been there and got removed, because it broke emerge -e world for
ebuilds that need configured kernel to compile.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Perforce packages have been removed from the tree

[Stuart Herbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Just a note that no-one took over maintainership of the perforce packages,
so I've removed them from the tree.

I've archived a copy in my personal overlay, just in case there are any
Gentoo users out there who'd like to help maintain them.  If you want to
help with them, come and talk to me on #gentoo-php or #gentoo-overlays.

Best regards,
Stu
- --
Stuart Herbert  [EMAIL PROTECTED]
Gentoo Developer   http://www.gentoo.org/
~   http://blog.stuartherbert.com/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
- --
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEi+F1DC+AuvmvxXwRAgfTAKCglAXMlsbnmmiyoB1jZziYTveg7gCdGrWk
T/fX2xvlaygsJVtPUKpoNyg=
=w1ZG
-END PGP SIGNATURE-

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] virtual/x11-7* hides real bugs and breaks good ebuilds

[Jakub Moc]

Donnie Berkholz wrote:
> Jakub Moc wrote:
>> Olivier Crete wrote:
>>> Is there a recent list of non-ported packages ? Maybe we should do a
>>> last effort to port everything for a week or two and then package.mask
>>> the packages that no one cares enough about to port them.
>> Hmmm, not a up2date one, AFAIK... There's a tracker bug
>>
>> http://bugs.gentoo.org/show_bug.cgi?id=112675
>>
>> and below is the most recent list from spyderous I was able to find (no
>> idea how much relevant it still is).
>>
>> http://dev.gentoo.org/~spyderous/broken_modular/broken_modular.txt.20060315
> 
> I can probably generate one tonight. Need to dig up the scripts, and
> I've got an emerge -e world running in the background.
> 
> Thanks,
> Donnie

Donnie, pingy! ;) Just a friendly reminder to run the script again, so
that we can do a last attempt on fixing the remaining stuff before
resorting to more drastic solutions...

Thanks. ;)

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Dealing with /var/cache on unmerge

[Mike Frysinger]

On Sunday 11 June 2006 05:01, Jakub Moc wrote:
> Daniel Drake wrote:
> > Mike Frysinger wrote:
> >> maybe give ebuilds a way to maintain a list of files that portage
> >> should nuke when unmerging the package ...
> >
> > Something similar to this would be useful for kernel ebuilds, as simply
> > unmerging kernel source will leave a load of temporary and object files
> > on the filesystem.
>
> Already been there and got removed, because it broke emerge -e world for
> ebuilds that need configured kernel to compile.

that isnt a bug

you cant assume the kernel sources that were just dropped into place match 
exactly the compiled objects in the same tree
-mike


pgpJwABwgWcmr.pgp
Description: PGP signature

Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

[Henrik Brix Andersen]

On Sat, Jun 10, 2006 at 11:37:42AM -0400, Alec Warner wrote:
> Have the GWN posted to -core in a sane time period prior to it's 
> release.  I seriously doubt anyone cares about whether the publication 
> is always "on time" (whatever that may be).  If it's a bi-weekly 
> publication it doesn't always have to go out on the same day, as long as 
> you get it out in the general time period.  I sometimes respond with 
> corrections/additions but they never make it because it is released 
> before my mail is sent.  Often when I see the core mail I don't even 
> bother reading it since by looking at the timestamp I can guess it's 
> already been mailed.

That's one of he things that keeps me away from contributing anything
to the GWN. Whenever I've sent something to the feedback address or
replied to a draft GWN with corrections, I've never heard back nor
have my corrections been made or rejected with a reason.

If the GWN wants to be that "independent" I wont stand in their
way. But I do agree with Christel that the GWN today is only a shadow
of what it used to be.

Regards,
Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


pgpw7Y85R8IH7.pgp
Description: PGP signature

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

[Henrik Brix Andersen]

On Sat, Jun 10, 2006 at 01:37:15PM +0200, Markus Ullmann 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.

While I do think this proposal is much better than the previous
non-existing proposal, it still doesn't address the problem of having
the sunrise overlay hosted on a non *.gentoo.org address to make it
100% clear to the public that it is unsupported.

Regards,
Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


pgpf03IBTNUlw.pgp
Description: PGP signature

Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

[Josh Saddler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marius Mauch wrote:
> On Sun, 11 Jun 2006 01:00:43 +0200
> Patrick Lauer <[EMAIL PROTECTED]> wrote:
> 
>> On Sat, 2006-06-10 at 11:37 -0400, Alec Warner wrote:
>>> Have the GWN posted to -core in a sane time period prior to it's 
>>> release.  I seriously doubt anyone cares about whether the
>>> publication is always "on time" (whatever that may be). 
>> So what would a sane time period be? 12h? 24h?
>> The problem with that is that you need an editor who is available
>> during this period to add corrections, but with the new influx of
>> helpers I think we can manage.
> 
> It should be sent *at least* 24 hours in advance IMO so everyone gets
> a chance to check it. Better to send news that's a few days old than to
> send incorrect news.

Agreed. A full day in advance helps ensure that any needed corrections or
additions can make it in.

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

iD8DBQFEi/aQrsJQqN81j74RAu9PAKCFkXjY1/u1s4Xk2y2z8m0RdTwHwACcCm4W
RRtsFocJpavIee8jaZpnnWM=
=vBld
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

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

[Jakub Moc]

Henrik Brix Andersen wrote:
> On Sat, Jun 10, 2006 at 01:37:15PM +0200, Markus Ullmann 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.
> 
> While I do think this proposal is much better than the previous
> non-existing proposal, it still doesn't address the problem of having
> the sunrise overlay hosted on a non *.gentoo.org address to make it
> 100% clear to the public that it is unsupported.
> 
> Regards,
> Brix

So, move it to this.is.unsupported.and.will.blow.your.box.gentoo.org if
you feel it will help anybody. I feel it's completely irrelevant, but
that's just me.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)



signature.asc
Description: OpenPGP digital signature

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

[Josh Saddler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris Gianelloni wrote:
> [. . .]

Right on! :)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEi/j4rsJQqN81j74RAsRHAKCJsN09KKGlLq5CD4Bh/7r9QYJ12QCgnFx1
lRWrDI1euePCP0MrwoP/Emg=
=G9qu
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] i18n project

[Jan Kundrát]

Marius Mauch wrote:
>  and my point is that users often don't even realize that
> their post contains non-english text

Make Portage add a line with "Some of the previous errors were reported
in non-English language. If you want to get support from official
channel, please run `LC_ALL=C command`." when it detects a non-English
locale.

> Basically I don't think the benefit is rather dubious or maybe it's
> just that I had some rather bad experiences with translated versions of
> FOSS applications, but I'm quite opposed to this part of the project
> unless you have a way to remove my concerns.

Sure, translating GCC output is *not* good, but why don't provide
localized version of Portage messages like, for example, those when
Portage complains about unsatisfied dependency?

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] i18n project

[Jan Kundrát]

Peter Volkov (pva) wrote:
> On Сбт, 2006-06-10 at 15:11 +0200, Jan Kundrát wrote:
>> a) Translation of metadata.xml stuff in our tree (Is there any method to
>> keep them up-to-date when the English text changes? Something like
>> "revision" attribute that gets bumped when the English text gets updated?)
> 
> While we do not have "version" or "revision" attribute, just drop all
> translations whenever you update English.

Re-adding them again and checking RCS history seems like unnecessary
work to me.

>> c) l10n for other packages and sending patches upstream
>> d) Translation of manpages. man-pages-cs for example sucks :(.
> 
> Do we really need to do this inside Gentoo i18n project? This tasks are
> common for many distributions and should be done outside Gentoo. So just
> translate and send translations upstream.

Nope, that wouldn't be the primary job of the i18n team, just some kind
of task that they might do when they'd be idling otherwise :)

> Fex, to increase the profit from translated GWN
> translated versions should come out together with English one.

Tricky or even impossible one, considering the current time schedule.

> Personally I do not like idea to look at web for package documentation.
> There already exist decision to put all example files somewhere
> into /usr/share. I hope one day this happens and then all translated
> configuration files also can be put there.

While the comments in configuration files are certainly very useful, I
am persuaded that they shouldn't contain more information than the docs
available somewhere else. It's quite common for an administrator to work
on a remote box, possibly with a crappy network connection, and browsing
some doc over web is easier than launching yet another links session
under screen.

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] i18n project

[Jan Kundrát]

Nguyễn Thái Ngọc Duy wrote:
> Keep only English in metadata.xml. Using tools such as intltool or
> xml2po to extract strings and let i18n translate/maintain .po files
> themselves. Generated .mo files will be included in metadata directory
> when rsycing. Another portage hack to use .mo files in metadata
> directory instead of plain English if locale variables is not C.

That would require external tools to support Yet Another Method of
Retrieving Metadata which is a Bad Thing (tm).

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth



signature.asc
Description: OpenPGP digital signature

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

[Peter]

On Sat, 10 Jun 2006 13:37:15 +0200, Markus Ullmann wrote:

> 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).
> 

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?

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.

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

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)?

-- 
Peter


-- 
gentoo-dev@gentoo.org mailing list

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

[Christian Birchinger]

On Fri, Jun 09, 2006 at 02:04:57PM +0200, Stefan Schweizer wrote:
>
> "svn co http://overlays.gentoo.org/svn/proj/sunrise/category/application";
> "emerge application"
> 

As long as it's made for pulling single ebuilds (and their
support files), i think it's really helpfull.

It's exactly the same as downloading single ebuilds from
Bugzilla just without the pain of using bugzilla for it.
While Bugzilla is fine for handling bugs, i think it's
annoying to use for maintaining and downloading ebuilds.

The "danger" of people breaking something is exactly the
same though. I don't see a difference between downloading
an ebuild with bugzilla and fetching them with svn.

What i would fear is a full overlay with eclasses and many
other things the user didn't cherry pick.

I would mostly like a method to easily add external ebuilds
to my own overlay.
When that source allows people to maintain their ebuilds in
a simple way, it's also better. Raising the annoyance bar
for handling ebuilds doesn't increase their quality.


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

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

[Kevin F. Quinn]

On Sun, 11 Jun 2006 07:33:19 -0400
Peter <[EMAIL PROTECTED]> wrote:

> On Sat, 10 Jun 2006 13:37:15 +0200, Markus Ullmann wrote:
> 
> > 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).
> > 
> 
> 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?

What those bugs are waiting for is a dev to step up and agree to
maintain it.  I don't see how sunrise improves that situation.  The
only way such a bug will be resolved if no dev is interested, is if
someone who wants the package in the tree decides to become a dev - and
that means demonstrating technical ability, and sticking around (not
just dumping it in the tree then disappearing - in which case the
package would likely get removed after a while anyway due to lack of
maintenance).

> 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.
> 
> One of the terrific benefits of sunrise will be the cleaning out of
> bugzilla. Nuking open bugs is an especially satisfying experience!

Sorry, I don't buy that.  Having m-w/m-n packages in the sunrise
overlay cannot be sufficient to close the bugs in bugzilla.  The bugs
get closed when the package gets maintenance support from a dev and is
put into the tree.  Sunrise doesn't do anything to make that more
likely.

I also don't think that having large numbers of bugs open in bugzilla
is a problem.  The search facilities are quite capable of giving you
focused lists of open bugs.  If you don't want to see the bugs about
m-w/m-n ebuilds, filter them out of your search.

> 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)?

This reflects back on the primary objection to sunrise on gentoo.org.
Your question is essentially, "who will take responsibility for it and
put it in the tree?".  Sunrise might help in getting ebuilds to a decent
standard, and it might help some users to contribute, but it won't help
if no dev wants to take on maintainership of the package.  That last
point is the only reason why m-w/m-n packages are not in the tree.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature

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

[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

Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

[Christel Dahlskjaer]

After waiting for my replies for 24+ hours I presume they disappeared
into a blackhole while we were lacking lists, so I'm resending.


 Forwarded Message 
> From: Christel Dahlskjaer <[EMAIL PROTECTED]>
> To: gentoo-dev@lists.gentoo.org
> Subject: Re: [gentoo-dev] July Council Meeting: Requested Agenda Item
> Date: Sat, 10 Jun 2006 13:13:37 +0100
> 
> On Sat, 2006-06-10 at 09:27 +0200, Wernfried Haas wrote:
> > On Sat, Jun 10, 2006 at 04:28:36AM +0100, Christel Dahlskjaer wrote:
> > > I would like to ask that the Council discuss the current state and
> > > future of the GWN at their next meeting.
> > 
> > Council? Why escalate things? Have you talked to Ulrich about the
> > problems mentioned below? Isn't the GWN somehow a userrel issue? ;-)
> 
> I have attempted, but as it happens I have never ever spoken to Ulrich
> as he does not respond to my e-mails and does not frequent IRC and I
> don't have his telephone number or address. And the GWN doesn't come
> under Userrel, although they do have a representative within Userrel,
> one whom I understand to be wanting to make some improvements to the
> GWN.  
> 
> As for why the Council, because thats what people suggested when I asked
> which route to take when he was unresponsive. 
> 
> > > 1. Reliability. The GWN claims to be a weekly publication, yet it
> > > frequently fails to publish without prior warning. There was no edition
> > > this week, and Patrick Lauer says that it is "unknown" whether there
> > > will be an edition next week as Ulrich Plate is AWOL.
> > 
> > I agree there are problems due to Ulrich being awol every now and
> > then, but what can the council do about it? Fire him so the GWN is
> > unmaintained? ;-)
> 
> No. I don't want anyone fired. However, I believe that the other GWN guy
> could be provided with sufficient access to make sure it goes out, and I
> believe that Ulrich could give some warning when possible so that
> Patrick or whomever can get it out regardless of whether Ulrich is
> around or not. 
> 
> > > 2. Permissions. Although it could be considered flattering that the GWN
> > > should choose a developer's blog as inspiration for an article, they
> > > should ensure that they have the developer / author's permission before
> > > quoting them (see previous complaints by brix, ciaranm and others).
> > 
> > Why? What makes blog posts different to mailing list/forum threads,
> > new versions being released etc? Do you want to ask people for
> > permission then, too?
> 
> If you re-read what I said I don't have an issue with the GWN or anyone
> else using someones blog post as inspiration, I do however believe that
> when quoting someone and writing the article in such a way that the
> 'quotee' appears to have spoken to the publication you need to get some
> consensus before printing. 
> 
> > > I also believe that when posting an article or interview, a copy should
> > > be sent to the relevant people to ensure that they are ok with what is
> > > being posted (my dev of the week interview, for example, was rather
> > > screwed up and misrepresentative). When someone contacts GWN to have
> > > something corrected, it would be appreciated were the GWN staff to at
> > > least deign to acknowledge receipt, even if for some reason they choose
> > > not to honour the corrections or post a retraction (although refusing to
> > > publish corrections is extremely insulting to those wronged).
> > 
> > Considering Ulrich is appearently still/again awol, could that be the
> > reason? I have requested small fixes (like wrong email addresses in
> > stuff i submitted) every now and than and got what i asked for.
> 
> He wasn't awol at the time of my writing my first few e-mails. 
> 
> > > 3. Misinformation, misquotations and outright fabrications. Sure,
> > > there's freedom of the press, but that shouldn't be used as an excuse
> > > for deliberately making up quotes and printing intentional
> > > misinformation.
> > 
> > Huh? Can you back that statement up?
> 
> To take an example, there were made up quotes in my GWN interview,
> however, nothing of great harm. I believe that time it was a case of
> attempting to make it more fun, it is however a worrying trend.
> 
> > > From a PR perspective, Gentoo could benefit greatly by better
> > > utilisation of the GWN. I believe that as it stands, however, the GWN is
> > > discouraging people from contributing and damaging Gentoo's credibility.
> > 
> > I have submitted a bunch of articles to the GWN, and it has always
> > worked fine for me. Yes, Ulrich is awol at times and sometimes there
> > are smaller corrections to make in the final article, but i never felt
> > discouraged to submit my stuff. Worst case it takes a few extra days
> > to get published.
> 
> Ok. I am very glad to hear that not everyone shares the same experiences
> when it comes to contributing to the GWN. 
> 
> > > Another thing that concerns me is the way the articles are written. It
> > > is blatanly obvious 

Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

[Christel Dahlskjaer]

The reply appears to have disappeared into a black hole.

 Forwarded Message 
> From: Christel Dahlskjaer <[EMAIL PROTECTED]>
> To: gentoo-dev@lists.gentoo.org
> Subject: Re: [gentoo-dev] July Council Meeting: Requested Agenda Item
> Date: Sat, 10 Jun 2006 13:26:31 +0100
> 
> On Sat, 2006-06-10 at 10:07 +0200, Lars Weiler wrote:
> > Congratulations.  I just unsubscribed from the
> > gwn-feedback-alias after reading your mail.
> > 
> > * Christel Dahlskjaer <[EMAIL PROTECTED]> [06/06/10 04:28 +0100]:
> > > 1. Reliability. The GWN claims to be a weekly publication, yet it
> > > frequently fails to publish without prior warning. There was no edition
> > > this week, and Patrick Lauer says that it is "unknown" whether there
> > > will be an edition next week as Ulrich Plate is AWOL.
> > 
> > Several times Kurt or I took over the job of publicing the
> > GWN when Ulrich asked us.  So, there is a backup, but he
> > didn't asked for this week.
> 
> I am glad to hear that backup has been used in the past, and I hope that
> it will be again.
> 
> > > 2. Permissions. Although it could be considered flattering that the GWN
> > > should choose a developer's blog as inspiration for an article, they
> > > should ensure that they have the developer / author's permission before
> > > quoting them (see previous complaints by brix, ciaranm and others).
> > > 
> > > I also believe that when posting an article or interview, a copy should
> > > be sent to the relevant people to ensure that they are ok with what is
> > > being posted (my dev of the week interview, for example, was rather
> > > screwed up and misrepresentative). When someone contacts GWN to have
> > > something corrected, it would be appreciated were the GWN staff to at
> > > least deign to acknowledge receipt, even if for some reason they choose
> > > not to honour the corrections or post a retraction (although refusing to
> > > publish corrections is extremely insulting to those wronged).
> > 
> > And I expect the same from you.  You should ask the affected
> > people first before starting a discussion about them on our
> > public mailing lists.  This is a device I can give you for
> > further userrelations-activities.
> 
> I have actually contacted Ulrich on several occasions, he chose not to
> get back to me. And I have spoken a fair bit with Patrick, and from
> speaking with Patrick it is quite obvious that the GWN could do with
> some help, and I am hoping that my addressing the problems we can pool
> together and find ways of helping them.
> 
> > > 4. Credit. Care should be taken to ensure that crrect credit is given.
> > 
> > It is.  Either as "Author" or "Contributor".
> 
> Or it is totally lacking, like in the above mentioned blog scenario. 
> 
> > > Another thing that concerns me is the way the articles are written. It
> > > is blatanly obvious that the GWN writers are not native English speakers
> > > as both the grammar and the flow of the articles is far from attractive.
> > > Having read through the archives, I notice that there was once a time
> > > when the GWN was a great publication, and I would like to think that it
> > > could become great yet again; in its current state, though, it is doing
> > > more harm than good.
> > 
> > It's quite interesting to see, that the GWN and also
> > Debian's Weekly Newsletter is run by Germans mostly.  Is
> > there a problem with native speakers to run a periodically
> > newsletter for a long time (> 3 years)?
> 
> No, there isn't a problem with it. However, as I understand it the GWN
> is translated into N languages, and I would presume the german version
> to be the one which reads better. Could it be an idea to have someone
> whos first language is English look over and improve upon the English
> version? I know we already dot the i's and cross the t's, maybe it would
> be of benefit if someone worked a bit on how it flows.
> 
> > > Lack of content and poorly written or incorrect articles are often
> > > justified by the GWN team on grounds of overwork and insufficient
> > > manpower. When I asked why they were not recruiting, I was informed that
> > > no-one has any interest in contributing. Upon speaking with others,
> > > however, I find that this is not the case -- people are interested, but
> > > fear (and rightly so) that their work will be edited in such a way that
> > > it is no longer something with which they want to be associated.
> > 
> > Subscribe to the gwn-feedback-alias and read or comment the
> > submissions to the GWN.  Make sure that every user will
> > receive and answer.  And forward questions to the
> > arch-teams.  Isn't that userrel's job?  I didn't saw your
> > contributions there yet.
> 
> I wasn't aware the gwn-feedback alias was public, if it is then I would
> be more than happy to subscribe to it and read and comment to every
> user. Would I be stepping on anyones toes by doing so? And if the GWN
> would like to off-load some stuff onto Userrel, then userrel wo

Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

[Christel Dahlskjaer]

Another vanishing reply from yesterday.


 Forwarded Message 
> From: Christel Dahlskjaer <[EMAIL PROTECTED]>
> To: gentoo-dev@lists.gentoo.org
> Subject: Re: [gentoo-dev] July Council Meeting: Requested Agenda Item
> Date: Sat, 10 Jun 2006 13:44:02 +0100
> 
> On Sat, 2006-06-10 at 10:56 +0200, Patrick Lauer wrote:
> > On Sat, 2006-06-10 at 03:28 +0100, Christel Dahlskjaer wrote:
> > > I would like to ask that the Council discuss the current state and
> > > future of the GWN at their next meeting.
> > I don't think you have to escalate that far. We should be able to discuss 
> > things without the thermonuclear option ;-)
> 
> I have no idea, I asked people, they suggested the Council. It may be
> the wrong place :)
> 
> > > 1. Reliability. The GWN claims to be a weekly publication, yet it
> > > frequently fails to publish without prior warning. There was no edition
> > > this week, and Patrick Lauer says that it is "unknown" whether there
> > > will be an edition next week as Ulrich Plate is AWOL.
> > We have tried to get a backup structure working, Halcy0n for example 
> > offered to help. Ulrich never responded to these offers. He usually has 
> > a good reason for not doing the GWN (like no Internet access, broken 
> > notebook etc), but I also find this quite unsatisfactory.
> 
> I am sure his reasons are good, and I agree there should be a backup
> structure in place. 
> 
> > > 2. Permissions. Although it could be considered flattering that the GWN
> > > should choose a developer's blog as inspiration for an article, they
> > > should ensure that they have the developer / author's permission before
> > > quoting them (see previous complaints by brix, ciaranm and others).
> > As far as I'm aware this has been taken care of. But with the GWN quite 
> > understaffed it is not easy to get everything done well.
> > I'd appreciate some more support from others, but sadly my recruiting
> > experiments usually ended after one contribution (for example summary of
> > the -user ML).
> 
> Which is why I am hoping that by bringing it up elsewhere, someone may
> have some ideas of how to recruit people, or just attract people enough
> for them to make the occasional contribution. 
> 
> > > I also believe that when posting an article or interview, a copy should
> > > be sent to the relevant people to ensure that they are ok with what is
> > > being posted (my dev of the week interview, for example, was rather
> > > screwed up and misrepresentative).
> > My fault. 
> 
> Ok, thank you.
> 
> > >  When someone contacts GWN to have
> > > something corrected, it would be appreciated were the GWN staff to at
> > > least deign to acknowledge receipt, even if for some reason they choose
> > > not to honour the corrections or post a retraction (although refusing to
> > > publish corrections is extremely insulting to those wronged).
> > The reason for that is that the GWN is mostly sent out by mail. This 
> > makes corrections a bit more difficult, but I think having a sane policy 
> > for that would be helpful.
> > 
> > > 3. Misinformation, misquotations and outright fabrications. Sure,
> > > there's freedom of the press, but that shouldn't be used as an excuse
> > > for deliberately making up quotes and printing intentional
> > > misinformation.
> > I don't know what exactly you are talking about here. But it shouldn't 
> > happen.
> > 
> > > 4. Credit. Care should be taken to ensure that crrect credit is given.
> > Yes. 
> > 
> > > From a PR perspective, Gentoo could benefit greatly by better
> > > utilisation of the GWN. I believe that as it stands, however, the GWN is
> > > discouraging people from contributing and damaging Gentoo's credibility.
> > The problem with the GWN is the lack of reliable useful contributions.
> > There was a time when the GWN was ~80% written by me, but that took more
> > time than I could afford in the last weeks.
> 
> See, if you spent less time arguing with that elitist bastard Chri...
> er, no :P Yes, I think what the GWN needs the most is more hands at the
> deck. 
> 
> > > Another thing that concerns me is the way the articles are written. It
> > > is blatanly obvious that the GWN writers are not native English speakers
> > > as both the grammar and the flow of the articles is far from attractive.
> > Help is appreciated :-)
> > The GWN has become a german thing, we have jokingly discussed writing it
> > in german and letting someone translate it to english.
> 
> I don't think thats a bad bad idea, that is, maybe someone could atleast
> vamp it up a bit before it goes live. 
> 
> > > Having read through the archives, I notice that there was once a time
> > > when the GWN was a great publication, and I would like to think that it
> > > could become great yet again; in its current state, though, it is doing
> > > more harm than good.
> > Agreed.
> > 
> > > Lack of content and poorly written or incorrect articles are often
> > > justified by the GWN team on grounds of overwo

Re: [gentoo-dev] virtual/x11-7* hides real bugs and breaks good ebuilds

[Donnie Berkholz]

Jakub Moc wrote:
> Donnie, pingy! ;) Just a friendly reminder to run the script again, so
> that we can do a last attempt on fixing the remaining stuff before
> resorting to more drastic solutions...

Yeah, it's on my list, but I've got family here all weekend so no time
to work on stuff.

Thanks,
Donnie



signature.asc
Description: OpenPGP digital signature

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

[Donnie Berkholz]

Henrik Brix Andersen wrote:
> While I do think this proposal is much better than the previous
> non-existing proposal, it still doesn't address the problem of having
> the sunrise overlay hosted on a non *.gentoo.org address to make it
> 100% clear to the public that it is unsupported.

It's no more or less supported than anything else on
overlays.gentoo.org. The word "overlays" ought to be enough. I suppose
you oppose the whole concept, anyhow?

Thanks,
Donnie



signature.asc
Description: OpenPGP digital signature

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

[Henrik Brix Andersen]

On Sun, Jun 11, 2006 at 03:42:19PM +0200, Christian Birchinger wrote:
> On Fri, Jun 09, 2006 at 02:04:57PM +0200, Stefan Schweizer wrote:
> >
> > "svn co http://overlays.gentoo.org/svn/proj/sunrise/category/application";
> > "emerge application"
> > 
> 
> As long as it's made for pulling single ebuilds (and their
> support files), i think it's really helpfull.

The way SVN works you can just as easily do "svn co
http://overlays.gentoo.org/svn/proj/sunrise/"; and get the full
repository - so no, this is not limited to pulling single ebuilds.

./Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


pgpdMipiLWjnS.pgp
Description: PGP signature

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

[Henrik Brix Andersen]

On Sun, Jun 11, 2006 at 04:01:50PM +0200, Stefan Schweizer wrote:
> 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.

But Project Sunrise can? I'm sorry, but I believe you are
overestimating yourself...

Regards,
Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


pgpKiMpk5C9m9.pgp
Description: PGP signature

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

[Henrik Brix Andersen]

On Sun, Jun 11, 2006 at 09:43:01AM -0700, Donnie Berkholz wrote:
> It's no more or less supported than anything else on
> overlays.gentoo.org. The word "overlays" ought to be enough. I suppose
> you oppose the whole concept, anyhow?

No, I am certainly not opposed to overlays in general. I even maintain
my own public overlay of packages I work on in portage, an overlay I
consider moving to overlays.g.o when I have more time.

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. I believe this was
why many developers agreed to having the overlays project in the first
place. The idea was to have a central repository for the team and
developer specific overlays that already are available on
e.g. dev.gentoo.org. Overlays that are far more limited in contents
and where the ebuilds are written and reviewed by people who actually
know the packages in question.

Instead of following this consensus, the people behind Project Sunrise
choose to ignore this and went ahead and implemented the project -
without even presenting the idea to the developer community before
announcing it's presence to the world; perhaps thinking it would be
easier to get pardon than permission.

As I see it we have already agreed that an overlay of this type should
not be hosted on the overlays project back when the overlays project
was agreed upon. Yet a small number of developers ignored this and
implemented it anyhow behind the back of the rest of the developers,
disregarding their public stated oppinion. As this is a project that
has the potential of affecting the entire project I find this very
problematic.

Regards,
Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


pgpml7nyTSUpF.pgp
Description: PGP signature

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

[Stuart Herbert]

-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.

Best regards,
Stu
- --
Stuart Herbert  [EMAIL PROTECTED]
Gentoo Developer   http://www.gentoo.org/
~   http://blog.stuartherbert.com/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
- --
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEjFivDC+AuvmvxXwRAungAKCejd72YGbpZ5bzFjtg2ezAu8XwswCeK2PP
GwYPr/RE79+j4iiZMbcA3zM=
=ZOKP
-END PGP SIGNATURE-

--
gentoo-dev@gentoo.org mailing list

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

[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

Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

[Wernfried Haas]

On Sun, Jun 11, 2006 at 05:50:05PM +0100, Christel Dahlskjaer wrote:
> > As for why the Council, because thats what people suggested when I asked
> > which route to take when he was unresponsive. 

I see, and that puts your suggestion of conctacting the council in a
different angle.

[some stuff skipped as it seems to be cleared up]

> > > > 3. Misinformation, misquotations and outright fabrications. Sure,
> > > > there's freedom of the press, but that shouldn't be used as an excuse
> > > > for deliberately making up quotes and printing intentional
> > > > misinformation.
> > > 
> > > Huh? Can you back that statement up?
> > 
> > To take an example, there were made up quotes in my GWN interview,
> > however, nothing of great harm. I believe that time it was a case of
> > attempting to make it more fun, it is however a worrying trend.

Agreed, that shouldn't happen.

> > > > Another complaint is that the GWN rejects any writing style which has
> > > > any degree of character or levity. Any attempt at dececnt writing (the
> > > > kind that would make it into publication in English newspapers or
> > > > magazines, for example), is met with the claim that "the GWN is not a
> > > > humorous publication".
> > > 
> > > http://www.gentoo.org/news/en/gwn/20060522-newsletter.xml#doc_chap3
> > > Look at the picture and tell me it's not at least a tiny bit
> > > humorous. Agreed, the joke is a bit obvious.
> > 
> > I can't quite see how your picture has anything to do with writing style
> > and character of writing.

It's something a not humorous publication probably wouldn't print -
but whatever. ;-)

> > I am not entirely sure why the council wouldn't be a good place to start
> > a discussion about this. I believe that the council members will wish to
> > help the GWN help themselves sufficiently to solve their problems,
> > whether that be attempting to help them think of new ways to attract
> > contributors or make any other changes. 

I'm not sure how the council can do something here either, i think
discussing it here on the list may probably help solve some issues.

cheers,
Wernfried

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org


pgpRTcoRFpF9b.pgp
Description: PGP signature

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

[Markus Ullmann]

Ryan Hill wrote:
>> 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.
> 
> Would they be considered Gentoo staff, with everything that involves (quiz, 
> etc)?

No, they are only given permission for the project. Becoming a gentoo
developer is a separate step and involves a full recruiting.
However, they need to do the normal ebuild quiz with one of the project
devs to be allowed to commit to the project overlay on their own.

>> 7) tag on bugs
>>
>> All ebuilds that are made available on sunrise get an InOverlay KEYWORDS
>> entry on bugs.g.o so that everyone, who looks at the bug, knows about it.
> 
> Would it also be useful to also have a keyword to indicate that the Sunrise
> ebuild has reached the point where it could be migrated to the gentoo repo if 
> a
> maintainer for it steps up?  I'm thinking that would make it easy to get a 
> list
> of all m-w ebuilds that are ready for the tree.  Maybe a page listing these
> packages would also be a good idea.

Okay so leave a comment on the bug for now and later on we can follow
your idea here and provide a "ready to move over list" as well, which
seems quite a good idea :)

Greetz,
Jokey



signature.asc
Description: OpenPGP digital signature

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

[Henrik Brix Andersen]

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]

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.

In my opinion, creating a new project with this purpose should not
have been allowed. 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. 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]

The security issues of having an official overlay of unsupported
ebuilds was also raised back then. [6] [7] [8] [9] [10] As was the
concerns about potential damage to the reputation of Gentoo as a
whole. [11] [12]

On the other hand, having team/herd specific overlays with commit
access from a select few end-users (as was written in the original
proposal) was seen as a good idea. [13] [14]

I've spent tonight reading through the entire thread that let to the
creation of the overlays project, and I still come out in the end with
the feeling that a consensus of having overlays.gentoo.org for hosting
the already existing developer and herd/team overlays in a central
place was reached. It also looks to me like the idea of having a
"free-for-all" or a user-contrib overlay hosted there would not be
acceptable due to security issues and risk of damaging the reputation
of Gentoo as a whole.

I know this doesn't provide solid evidence that this is how it was,
but truth is - we hardly ever see an email on the developers list
stating "This is what we agreed on". Due to the nature of the media we
tend to have a lot of input and discussion back and forth after which
a general consensus is found. This consensus, as I see it, is
reflected in the policy for overlays.gentoo.org. [15]

I urge people to read through the initial thread that fostered
overlays.gentoo.org as well - if only to refresh peoples memory on the
stuff that was discussed back then. You can start at
http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09877.html

Sincerely,
Brix

[1]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09913.html
[2]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09921.html
[3]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09983.html

[4]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09962.html
[5]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09966.html

[6]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09918.html
[7]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09959.html
[8]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09884.html
[9]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09964.html
[10]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09963.html
[11]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09910.html
[12]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09946.html

[13]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09948.html
[14]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09972.html

[15]: http://www.gentoo.org/proj/en/overlays/policy.xml
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


pgp3PFucKP198.pgp
Description: PGP signature

Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

[Christel Dahlskjaer]

On Sat, 2006-06-10 at 09:27 +0200, Wernfried Haas wrote:
> On Sat, Jun 10, 2006 at 04:28:36AM +0100, Christel Dahlskjaer wrote:
> > I would like to ask that the Council discuss the current state and
> > future of the GWN at their next meeting.
> 
> Council? Why escalate things? Have you talked to Ulrich about the
> problems mentioned below? Isn't the GWN somehow a userrel issue? ;-)

I have attempted, but as it happens I have never ever spoken to Ulrich
as he does not respond to my e-mails and does not frequent IRC and I
don't have his telephone number or address. And the GWN doesn't come
under Userrel, although they do have a representative within Userrel,
one whom I understand to be wanting to make some improvements to the
GWN.  

As for why the Council, because thats what people suggested when I asked
which route to take when he was unresponsive. 

> > 1. Reliability. The GWN claims to be a weekly publication, yet it
> > frequently fails to publish without prior warning. There was no edition
> > this week, and Patrick Lauer says that it is "unknown" whether there
> > will be an edition next week as Ulrich Plate is AWOL.
> 
> I agree there are problems due to Ulrich being awol every now and
> then, but what can the council do about it? Fire him so the GWN is
> unmaintained? ;-)

No. I don't want anyone fired. However, I believe that the other GWN guy
could be provided with sufficient access to make sure it goes out, and I
believe that Ulrich could give some warning when possible so that
Patrick or whomever can get it out regardless of whether Ulrich is
around or not. 

> > 2. Permissions. Although it could be considered flattering that the GWN
> > should choose a developer's blog as inspiration for an article, they
> > should ensure that they have the developer / author's permission before
> > quoting them (see previous complaints by brix, ciaranm and others).
> 
> Why? What makes blog posts different to mailing list/forum threads,
> new versions being released etc? Do you want to ask people for
> permission then, too?

If you re-read what I said I don't have an issue with the GWN or anyone
else using someones blog post as inspiration, I do however believe that
when quoting someone and writing the article in such a way that the
'quotee' appears to have spoken to the publication you need to get some
consensus before printing. 

> > I also believe that when posting an article or interview, a copy should
> > be sent to the relevant people to ensure that they are ok with what is
> > being posted (my dev of the week interview, for example, was rather
> > screwed up and misrepresentative). When someone contacts GWN to have
> > something corrected, it would be appreciated were the GWN staff to at
> > least deign to acknowledge receipt, even if for some reason they choose
> > not to honour the corrections or post a retraction (although refusing to
> > publish corrections is extremely insulting to those wronged).
> 
> Considering Ulrich is appearently still/again awol, could that be the
> reason? I have requested small fixes (like wrong email addresses in
> stuff i submitted) every now and than and got what i asked for.

He wasn't awol at the time of my writing my first few e-mails. 

> > 3. Misinformation, misquotations and outright fabrications. Sure,
> > there's freedom of the press, but that shouldn't be used as an excuse
> > for deliberately making up quotes and printing intentional
> > misinformation.
> 
> Huh? Can you back that statement up?

To take an example, there were made up quotes in my GWN interview,
however, nothing of great harm. I believe that time it was a case of
attempting to make it more fun, it is however a worrying trend.

> > From a PR perspective, Gentoo could benefit greatly by better
> > utilisation of the GWN. I believe that as it stands, however, the GWN is
> > discouraging people from contributing and damaging Gentoo's credibility.
> 
> I have submitted a bunch of articles to the GWN, and it has always
> worked fine for me. Yes, Ulrich is awol at times and sometimes there
> are smaller corrections to make in the final article, but i never felt
> discouraged to submit my stuff. Worst case it takes a few extra days
> to get published.

Ok. I am very glad to hear that not everyone shares the same experiences
when it comes to contributing to the GWN. 

> > Another thing that concerns me is the way the articles are written. It
> > is blatanly obvious that the GWN writers are not native English speakers
> > as both the grammar and the flow of the articles is far from attractive.
> > Having read through the archives, I notice that there was once a time
> > when the GWN was a great publication, and I would like to think that it
> > could become great yet again; in its current state, though, it is doing
> > more harm than good.
> 
> I disagree. GWN could use some more manpower to improve this and that,
> but i don't see the harm - at least i could easily come up with lots
> of stuff happenin

Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

[Christel Dahlskjaer]

On Sat, 2006-06-10 at 10:07 +0200, Lars Weiler wrote:
> Congratulations.  I just unsubscribed from the
> gwn-feedback-alias after reading your mail.
> 
> * Christel Dahlskjaer <[EMAIL PROTECTED]> [06/06/10 04:28 +0100]:
> > 1. Reliability. The GWN claims to be a weekly publication, yet it
> > frequently fails to publish without prior warning. There was no edition
> > this week, and Patrick Lauer says that it is "unknown" whether there
> > will be an edition next week as Ulrich Plate is AWOL.
> 
> Several times Kurt or I took over the job of publicing the
> GWN when Ulrich asked us.  So, there is a backup, but he
> didn't asked for this week.

I am glad to hear that backup has been used in the past, and I hope that
it will be again.

> > 2. Permissions. Although it could be considered flattering that the GWN
> > should choose a developer's blog as inspiration for an article, they
> > should ensure that they have the developer / author's permission before
> > quoting them (see previous complaints by brix, ciaranm and others).
> > 
> > I also believe that when posting an article or interview, a copy should
> > be sent to the relevant people to ensure that they are ok with what is
> > being posted (my dev of the week interview, for example, was rather
> > screwed up and misrepresentative). When someone contacts GWN to have
> > something corrected, it would be appreciated were the GWN staff to at
> > least deign to acknowledge receipt, even if for some reason they choose
> > not to honour the corrections or post a retraction (although refusing to
> > publish corrections is extremely insulting to those wronged).
> 
> And I expect the same from you.  You should ask the affected
> people first before starting a discussion about them on our
> public mailing lists.  This is a device I can give you for
> further userrelations-activities.

I have actually contacted Ulrich on several occasions, he chose not to
get back to me. And I have spoken a fair bit with Patrick, and from
speaking with Patrick it is quite obvious that the GWN could do with
some help, and I am hoping that my addressing the problems we can pool
together and find ways of helping them.

> > 4. Credit. Care should be taken to ensure that crrect credit is given.
> 
> It is.  Either as "Author" or "Contributor".

Or it is totally lacking, like in the above mentioned blog scenario. 

> > Another thing that concerns me is the way the articles are written. It
> > is blatanly obvious that the GWN writers are not native English speakers
> > as both the grammar and the flow of the articles is far from attractive.
> > Having read through the archives, I notice that there was once a time
> > when the GWN was a great publication, and I would like to think that it
> > could become great yet again; in its current state, though, it is doing
> > more harm than good.
> 
> It's quite interesting to see, that the GWN and also
> Debian's Weekly Newsletter is run by Germans mostly.  Is
> there a problem with native speakers to run a periodically
> newsletter for a long time (> 3 years)?

No, there isn't a problem with it. However, as I understand it the GWN
is translated into N languages, and I would presume the german version
to be the one which reads better. Could it be an idea to have someone
whos first language is English look over and improve upon the English
version? I know we already dot the i's and cross the t's, maybe it would
be of benefit if someone worked a bit on how it flows.

> > Lack of content and poorly written or incorrect articles are often
> > justified by the GWN team on grounds of overwork and insufficient
> > manpower. When I asked why they were not recruiting, I was informed that
> > no-one has any interest in contributing. Upon speaking with others,
> > however, I find that this is not the case -- people are interested, but
> > fear (and rightly so) that their work will be edited in such a way that
> > it is no longer something with which they want to be associated.
> 
> Subscribe to the gwn-feedback-alias and read or comment the
> submissions to the GWN.  Make sure that every user will
> receive and answer.  And forward questions to the
> arch-teams.  Isn't that userrel's job?  I didn't saw your
> contributions there yet.

I wasn't aware the gwn-feedback alias was public, if it is then I would
be more than happy to subscribe to it and read and comment to every
user. Would I be stepping on anyones toes by doing so? And if the GWN
would like to off-load some stuff onto Userrel, then userrel would be
more than happy to help. We already have a GWN representative and he
knows that several of the userrel team would jump at the chance to help
out with various GWN related bits.


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] A Small Clarification

[Christel Dahlskjaer]

An erroneous idea seems generally to prevail, and has lately found
expression on the mailing lists, that I have some sort of personal
problem with the GWN authors; that is, that I think them unsuitable for
the job and would like them removed. This idea cannot be too explicitly
contradicted.

I would like to assure people that, quite to the contrary, I have no
issue with Ulrich; I have merely observed that he frequently seems
unable to respond to emails, and I believe that given the nature of the
GWN this is a potential problem for someone in his position as editor.
The points raised in my email I still stand by, though I do not hold
these to be the fault of any individual person. My intention was not,
and has never been, to have Ulrich removed from the team; it is better
viewed as an unconventional way of trying to stimulate other
contributors to the GWN and help resolve some of its staffing issues,
since the more normal methods seem thus far to have failed. It should
also be noted that while I stand by points noted in my initial email, I
do so purely as myself, and that they do in no way reflect the opinions
of any projects of which I may be a part.

I would also like to thank Danny van Dyk (Kugelfang) and Tobias
Scherbaum (dertobi123) for taking the time and effort to discuss the
issues raised and to try to resolve them, and for allowing me to try to
help the situation. To those who were upset by my email, I would like
to say that this was not my intention, but I do believe that
constructive criticism is a positive thing, and I am ever grateful for
the opportunity to improve things. It perhaps did not occur to me that
it would be taken as a personal affront.

It has also been mentioned that perhaps the Council was not the best
way to bring this up. I can see how this may be the case, but at the
time I was unsure of the proper way to go about these things, and a
mail to the Council and gentoo-dev was the best suggestion I received
when asking people with more experience than myself.

I hope this clears up some of the confusion,
Christel.


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

[Christel Dahlskjaer]

On Sat, 2006-06-10 at 10:56 +0200, Patrick Lauer wrote:
> On Sat, 2006-06-10 at 03:28 +0100, Christel Dahlskjaer wrote:
> > I would like to ask that the Council discuss the current state and
> > future of the GWN at their next meeting.
> I don't think you have to escalate that far. We should be able to discuss 
> things without the thermonuclear option ;-)

I have no idea, I asked people, they suggested the Council. It may be
the wrong place :)

> > 1. Reliability. The GWN claims to be a weekly publication, yet it
> > frequently fails to publish without prior warning. There was no edition
> > this week, and Patrick Lauer says that it is "unknown" whether there
> > will be an edition next week as Ulrich Plate is AWOL.
> We have tried to get a backup structure working, Halcy0n for example 
> offered to help. Ulrich never responded to these offers. He usually has 
> a good reason for not doing the GWN (like no Internet access, broken notebook 
> etc), but I also find this quite unsatisfactory.

I am sure his reasons are good, and I agree there should be a backup
structure in place. 

> > 2. Permissions. Although it could be considered flattering that the GWN
> > should choose a developer's blog as inspiration for an article, they
> > should ensure that they have the developer / author's permission before
> > quoting them (see previous complaints by brix, ciaranm and others).
> As far as I'm aware this has been taken care of. But with the GWN quite 
> understaffed it is not easy to get everything done well.
> I'd appreciate some more support from others, but sadly my recruiting
> experiments usually ended after one contribution (for example summary of
> the -user ML).

Which is why I am hoping that by bringing it up elsewhere, someone may
have some ideas of how to recruit people, or just attract people enough
for them to make the occasional contribution. 

> > I also believe that when posting an article or interview, a copy should
> > be sent to the relevant people to ensure that they are ok with what is
> > being posted (my dev of the week interview, for example, was rather
> > screwed up and misrepresentative).
> My fault. 

Ok, thank you.

> >  When someone contacts GWN to have
> > something corrected, it would be appreciated were the GWN staff to at
> > least deign to acknowledge receipt, even if for some reason they choose
> > not to honour the corrections or post a retraction (although refusing to
> > publish corrections is extremely insulting to those wronged).
> The reason for that is that the GWN is mostly sent out by mail. This 
> makes corrections a bit more difficult, but I think having a sane policy 
> for that would be helpful.
> 
> > 3. Misinformation, misquotations and outright fabrications. Sure,
> > there's freedom of the press, but that shouldn't be used as an excuse
> > for deliberately making up quotes and printing intentional
> > misinformation.
> I don't know what exactly you are talking about here. But it shouldn't happen.
> 
> > 4. Credit. Care should be taken to ensure that crrect credit is given.
> Yes. 
> 
> > From a PR perspective, Gentoo could benefit greatly by better
> > utilisation of the GWN. I believe that as it stands, however, the GWN is
> > discouraging people from contributing and damaging Gentoo's credibility.
> The problem with the GWN is the lack of reliable useful contributions.
> There was a time when the GWN was ~80% written by me, but that took more
> time than I could afford in the last weeks.

See, if you spent less time arguing with that elitist bastard Chri...
er, no :P Yes, I think what the GWN needs the most is more hands at the
deck. 

> > Another thing that concerns me is the way the articles are written. It
> > is blatanly obvious that the GWN writers are not native English speakers
> > as both the grammar and the flow of the articles is far from attractive.
> Help is appreciated :-)
> The GWN has become a german thing, we have jokingly discussed writing it
> in german and letting someone translate it to english.

I don't think thats a bad bad idea, that is, maybe someone could atleast
vamp it up a bit before it goes live. 

> > Having read through the archives, I notice that there was once a time
> > when the GWN was a great publication, and I would like to think that it
> > could become great yet again; in its current state, though, it is doing
> > more harm than good.
> Agreed.
> 
> > Lack of content and poorly written or incorrect articles are often
> > justified by the GWN team on grounds of overwork and insufficient
> > manpower. When I asked why they were not recruiting, I was informed that
> > no-one has any interest in contributing.
> There's a big difference between one-off articles and continuous
> contribution. Also those that I found most willing to contribute had the
> biggest language problems - what we need is support from the native
> speakers.

Nod. I presume for some contributing weekly is rather difficult (finding
something to write abo

Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

[Ciaran McCreesh]

On Sat, 10 Jun 2006 10:56:48 +0200 Patrick Lauer <[EMAIL PROTECTED]>
wrote:
| > I also believe that when posting an article or interview, a copy
| > should be sent to the relevant people to ensure that they are ok
| > with what is being posted (my dev of the week interview, for
| > example, was rather screwed up and misrepresentative).
| My fault. 

Good start. Now, are you going to post corrections?

| >  When someone contacts GWN to have
| > something corrected, it would be appreciated were the GWN staff to
| > at least deign to acknowledge receipt, even if for some reason they
| > choose not to honour the corrections or post a retraction (although
| > refusing to publish corrections is extremely insulting to those
| > wronged).
| The reason for that is that the GWN is mostly sent out by mail. This 
| makes corrections a bit more difficult, but I think having a sane
| policy for that would be helpful.

Publish a 'corrections' section in the next edition?

| > Having read through the archives, I notice that there was once a
| > time when the GWN was a great publication, and I would like to
| > think that it could become great yet again; in its current state,
| > though, it is doing more harm than good.
|
| Agreed.

Given that it is doing more harm than good, should it be discontinued
until a solution is found?

| > Another complaint is that the GWN rejects any writing style which
| > has any degree of character or levity. Any attempt at dececnt
| > writing (the kind that would make it into publication in English
| > newspapers or magazines, for example), is met with the claim that
| > "the GWN is not a humorous publication".
|
| Blame the flamefests of the past. Whenever attempts were made to give
| the GWN more dynamic it was flamed down (because ze german humor is
| not funny! Nein! ;-) )
| So the consensus was to keep the silly jokes out of the GWN since
| always someone misunderstands or complains. I'd like to have it a bit
| more open, funny, enjoyable ... but there's only so much I can do. 

Christel did not talk about "silly jokes". She spoke about "decent
writing (the kind that would make it into publication in newspapers or
magazines, for example)". There's a rather large difference (well, if
you assume she means *respectable* newspapers and magazines -- good
examples for anyone wanting examples are the Times, the Guardian or the
Scotsman). I'd imagine the distinction could be not too obvious for
some non-native speakers, but it is a large and very important
distinction.

You don't have to be silly or boring to be considered respectable. Take
Jeremy Clarkson, for example. He's frequently rather outrageous, very
very funny, prone to using extremely colourful metaphors and writes for
the highly respectable Sunday Times, which has such a good reputation
not despite having such writers but because of it.

-- 
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

[Henrik Brix Andersen]

On Sat, Jun 10, 2006 at 01:13:36PM +0100, Christel Dahlskjaer wrote:
> To take an example, there were made up quotes in my GWN interview,
> however, nothing of great harm. I believe that time it was a case of
> attempting to make it more fun, it is however a worrying trend.

One of my blog entries was also over-interpreted and included in the
GWN without consulting me first, causing a mail storm in my inbox from
angry users of xsupplicant:

http://planet.gentoo.org/developers/brix/2005/11/25/wpa_supplicant_vs_xsupplicant

Regards,
Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


pgpYZmxDaOU68.pgp
Description: PGP signature

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

[Marius Mauch]

Stefan Schweizer schrieb:

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"?


Functional changes, bugfixes, etc. Let people use common sense there. 
The intention is simply that people watching the bug don't have to track 
the overlay as well to get notifications of important changes (like a 
bugfix that prevented them from using the ebuild previously).
Certainly you wouldn't consider whitespace changes or coding style 
updates as an *important*, would you?


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

Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

[Donnie Berkholz]

Henrik Brix Andersen wrote:
> On Sat, Jun 10, 2006 at 01:13:36PM +0100, Christel Dahlskjaer wrote:
>> To take an example, there were made up quotes in my GWN interview,
>> however, nothing of great harm. I believe that time it was a case of
>> attempting to make it more fun, it is however a worrying trend.
> 
> One of my blog entries was also over-interpreted and included in the
> GWN without consulting me first, causing a mail storm in my inbox from
> angry users of xsupplicant:

If errors in the GWN result in large numbers of emails directly to you
rather than to the GWN, maybe the developer's email link shouldn't be
included in articles and feedback should instead be linked to gwn-feedback.

The GWN is a fairly independent publication, so I think it should be
free to make its own mistakes as long as it retains journalistic
integrity. But perhaps it could benefit from some sort of advisory board
of Gentoo developers/staff?

Thanks,
Donnie



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

[Alec Warner]

Donnie Berkholz wrote:

Henrik Brix Andersen wrote:


On Sat, Jun 10, 2006 at 01:13:36PM +0100, Christel Dahlskjaer wrote:


To take an example, there were made up quotes in my GWN interview,
however, nothing of great harm. I believe that time it was a case of
attempting to make it more fun, it is however a worrying trend.


One of my blog entries was also over-interpreted and included in the
GWN without consulting me first, causing a mail storm in my inbox from
angry users of xsupplicant:



If errors in the GWN result in large numbers of emails directly to you
rather than to the GWN, maybe the developer's email link shouldn't be
included in articles and feedback should instead be linked to gwn-feedback.

The GWN is a fairly independent publication, so I think it should be
free to make its own mistakes as long as it retains journalistic
integrity. But perhaps it could benefit from some sort of advisory board
of Gentoo developers/staff?


Er the GWN is currently a Gentoo Project.

http://www.gentoo.org/proj/en/pr/gwn.xml

Although apparently the project page needs updating ;)



Thanks,
Donnie



--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] aging ebuilds with unstable keywords

[Daniel Ahlberg]

Hi,

This is an automatically created email message.
http://gentoo.tamperd.net/stable has just been updated with 15545 ebuilds.

The page shows results from a number of tests that are run against the ebuilds. 
The tests are:
* if a version has been masked for 30 days or more.
* if an arch was in KEYWORDS in an older ebuild, but not in the newer ones.
* if SRC_URI contains hosts specified in thirdpartymirrors.
* if ebuild uses patch instead of epatch.
* if ebuild sets S to ${WORKDIR}/${P}.
* if ebuild redefines P, PV, PN or PF.
* if ebuild doesn't inherit eutils when it uses functions from eutils.
* if ebuild doesn't inherit flag-o-matic when it uses functions from 
flag-o-matic.
* if ebuild has $HOMEPAGE in SRC_URI (cosmetic).
* if ebuild has $PN in SRC_URI (cosmetic).
* if ebuild forces -fPIC flag to CFLAGS.
* if ebuild has deprecated WANT_AUTO(CONF|MAKE)_?_?.
* if ebuild uses is-flag -fPIC, should be changed to has_fpic.
* if ebuild appends $RDEPEND or $DEPEND to $RDEPEND or $DEPEND to $DEPEND.
* if ebuild has arch keyword(s) in iuse.
* if ebuild overrides MAKEOPTS.
* if ebuild has automake, autoconf or libtool in RDEPEND.
* if ebuild exists in ChangeLog.
* if ebuild installs COPYING and/or INSTALL into doc.

The database is updated once a day and this email is sent once a week.
Questions and comments may be directed to [EMAIL PROTECTED]

Script has been running for 218 minutes.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] i18n project

[Flammie Pirinen]

2006-06-10, Diego 'Flameeyes' Pettenò sanoi, jotta:

> I'm actually going to work to add to Portage (will-be-2.2) i18n
> capabilities next week, and I'll be doing for sure the Italian
> translation.

Would this be a fix to Portage NLS bug
? If so, have you
considered what I have said in the bug? If the translation possibility
is going to concern the static Portage messages only, I fear that it
will be slight waste of time. Users will generally find partial
translations more harmful than no translations at all, and in Portage's
case I think that the ebuild/eclass messages will often contain the more
important parts of information, which will surely cause more annoyance
than be useful. Imagine that for fetch restrictions, you get first
generic note about fetch restriction in your native language, then n+1
lines of lengthy information how to fetch in English, not nice.
Similarly for post package install instructions, or conflicting USE
flag instructions etc. etc.

-- 
Flammie, Gentoo Linux Documentation’s Finnish head translator
and FlameEyes’ bot .


signature.asc
Description: PGP signature