Luca Barbato wrote:
> May I point you that ~10 people were the majority of what was FFmpeg,
> thus 10 people were enough to demote democratically the so called Leader
> and that guy got the name from Fabrice as his personal decision?
There was probably a reason for Fabrice to do that, and majority
Luca Barbato wrote:
> > Users will never be satisfied. But I guess you agree that API
> > compatibility will certainly avoid extra problems for users.
>
> It is not related to users,
I was trying to come back on topic. :)
> is related to me being called as swine a traitor and having death
> thr
Diego Elio Pettenò wrote:
> People who don't need the firmware can deal with disabling it themselves.
I don't like the binary distribution argument of include everything
to cover as many possible use cases as possible in one go.
I very much like the high resolution of Gentoo packages. I'd hate to
Diego Elio Pettenò wrote:
> > I don't like the binary distribution argument of include everything
> > to cover as many possible use cases as possible in one go.
> >
> > I very much like the high resolution of Gentoo packages. I'd hate to
> > enter a slippery slope toward lower resolution.
>
> Are
Agostino Sarubbo wrote:
> I'm using ssh -A to forward the key and I'm interested to find a
> way to do it for the gpg key.
>
> I found an how-to that uses socat ( http://superuser.com/questions/161973/how-
> can-i-forward-a-gpg-key-via-ssh-agent ) but does not work as expected.
Did you debug?
Ra
Michael Weber wrote:
> > Rather than creating a TCP socket I would look into using the ssh -W
> > option.
> gpg agent works with unix domain sockets.
I know. It would look something like socat + ssh -W socat
//Peter
Diego Elio Pettenò wrote:
> > Ah, I always thought of overlays as places where apps tend to reside,
> > but of course you could have glibc in there for all we know... Good
> > point...
>
> Welcome to the life of your average Gentoo ebuild maintainer.
Stop complaining (and with foul language! com
Diego Elio Pettenò wrote:
> > Stop complaining (and with foul language! come on, you sound like
> > an idiot, which seems unneccessary) and let's think about solutions.
>
> Your laziness makes you sound like an idiot too, thank you very much.
Send me constructive criticism in an email and I'll of
Diego Elio Pettenò wrote:
> > sys-firmware/iwl3945-ucode
I want this installed on my system.
> > sys-firmware/iwl4965-ucode
But not this.
> could we just remove them
Please don't. I think it would suck to lose the higher resolution.
On the plus side it seems that these particular packages w
Diego Elio Pettenò wrote:
> > Please don't. I think it would suck to lose the higher resolution.
>
> Use savedconfig
linux-firmware is okey but not great. The high resolution is there,
which was my main concern, but it's not so easy to know how to create
a savedconfig without installing the packa
Diego Elio Pettenò wrote:
> > So because we did things badly in the past, that is an excuse to
> > do things badly in the future? :)
>
> No. I still argue that this is NOT doing things badly.
> Masking a package will NOT cause it to get unmerged by default.
Hm, can you expand on "by default" ?
W
Leho Kraav wrote:
> I'm taking a look at etherpad-lite ebuild at
> https://bugs.gentoo.org/show_bug.cgi?id=328897
>
> It's a pretty big of a mess, but as I'm searching around, I can't really
> find any guidelines on how nodejs / npm stuff is supposed fit in with
> Portage. dev-nodejs/ doesn't ev
Duncan wrote:
> Is it possible to tell git to only clone/pull specific files in a repo?
No.
//Peter
Diego Elio Pettenò wrote:
> The policy is also because any ebuild relying on a network service
> to work cannot be assured to work at any point in time
While noble, I think it is a bit naïve. Reality is that many if not
most ebuilds *anyway* rely on temporal things - such as a current
enough versi
Greg KH wrote:
> > If there really are firmware blobs that are only available via git and
> > which cannot be redistributed we might consider whether it makes sense
> > to not support them entirely, or to force them to be masked.
>
> Did anyone actually consider the fact that there should not be
>
Alexander Berntsen wrote:
> > I would like to announce you a new try to 'revive' the Bugday
> > event.
>
> I don't have anything to add. I just wanted to express my support.
Yeah! Me too! :)
//Peter
Ryan Hill wrote:
> I think I see a lot of our upstream bug reports being closed as
> invalid/unsupported. I think that if upstreams wanted to use
> jemalloc they would just do so. If they don't then obviously
> what they have is working fine for them.
It can make sense to try further discussion,
Pavlos Ratis wrote:
> Unfortunately I didn't have much time to 'refresh' the website. As
> Theo said, he gave me the code of the site but I think it would be
> great to have something new. If anyone wants to join, ping me on irc.
> We could create a new repo at our Github and start developing.
Do
Tom Wijsman wrote:
> > > We could create a new repo at our Github and start developing.
> >
> > Don't start developing, plz work on bugs instead.
>
> Then who will develop useful tools to handle bugs more efficiently?
Don't get me wrong: I am not hating on useful tools!
I am saying that working
Tom Wijsman wrote:
> I am saying that working on tools that help you work on open bugs is
> not orthogonal to fixing open bugs, it helps you fix them efficiently.
Sure, but on the bugday itself it sounds on the name like the idea is
to work on bugs with currently available tools, rather than work
Markos Chandras wrote:
> it just feels strange
I hear they call it "getting stuff done"..
//Peter
Markos Chandras wrote:
> > > it just feels strange
> >
> > I hear they call it "getting stuff done"..
>
> good thing you are not a dev then.
> Thanks for the heads up in case you ever want to become one
I explain to you what happened and you, a recruiter, proceed to
threaten me in case I want to
Markos Chandras wrote:
> > I explain to you what happened
>
> "getting stuff done" is not an answer. I still don't understand why
> stable keywords had to be added directly. Do you understand why Mike
> did that or just playing smart here?
To me it's obvious that he did it because it made somethi
Markos Chandras wrote:
> >> "getting stuff done" is not an answer.
> >
> > it made something easier for him
>
> I asked why he did it, and you keep telling me because he had to.
I'm guessing that it didn't have much to do with Gentoo. Maybe he'll
fill in.
> I am reviewing commits from time to t
Andreas K. Huettel wrote:
> Starting as a developer or aspiring to become one with that
> attitude is not acceptable.
That doesn't make sense to me.
If the reason is good, surely it does not matter who is doing the breaking?
//Peter
pgpvkacjjiVYz.pgp
Description: PGP signature
Carlos Silva wrote:
> If one wants to create a key himself, it's also possible to use this
> key, he just has to name it signing_key.priv and siging_key.x509 and
> put it under /usr/src/linux.
Do you know if this is a sane default?
Where do most users of signed modules store keys so far?
//Pete
Carlos Silva wrote:
> > > If one wants to create a key himself, it's also possible to use this
> > > key, he just has to name it signing_key.priv and siging_key.x509 and
> > > put it under /usr/src/linux.
> >
> > Do you know if this is a sane default?
> >
> > Where do most users of signed modules s
Ulrich Mueller wrote:
> Should we make it a global flag?
Sure.
> What description is better:
>
>inotify - Enable inotify filesystem monitoring support
>inotify - Enable inotify file change notification support
The former is more correct, because inotify provides notifications
for more t
Samuli Suominen wrote:
>> Samuli Suominen wrote:
>>> it should always be enabled with 'kernel_linux' and let the
>>> application itself do a runtime check if inotify is available or not
>>
>> I think it's great if you are working on such patches for upstreams!
>
> no, i'm talking from experience --
Samuli Suominen wrote:
>>> i'm referring to the mistakes done by maintainers by adding
>>> unnecessarily the flag
>>
>> That was not at all clear, but that's great! Then you could fix those
>> ebuilds.
>
> Yes, I could, or I could just let other maintainers know about it, like
> on the ML, wait...
Nuno Silva wrote:
> mplayer *can* play it, but tuning is a different story.
mplayer is not really an alternative. tvtime looks and feels
significantly better.
A lot like saying that Fiat is an alternative to Ferrari.
I'm also curious if there are more known bugs than those noted in the
mask. I l
Alec Warner wrote:
> > MC> The package is going away unless someone fixes the bugs and
> > MC> properly maintains the package
> >
> > Again, that is an irresponsible mistake. It is better to just leave it
> > as is than to kick it. Dropping important packages can only harm the
> > community and i
Markos Chandras wrote:
> The masks are sort of announcements as you have 30 days to revert that
> decision.
You don't seem to recognize the quite significant psychological
impact of you having already made the decision, compared to, say,
having an actually inclusive package removal process.
Bugzi
Rich Freeman wrote:
> something is bound to break for good sooner or later if things don't change.
Certainly.
But consider the chain of events:
* user is happily using outdated, but working, software without
knowing how behind the times upstream really is, because it works
* gentoo masks and r
Rich Freeman wrote:
> > A per-ebuild bug metric would be cool. A kind of health indicator
> > for individual ebuilds, alerting users when some of our installed
> > ebuilds go yellow, so that we have perhaps on the order of six
> > months before the package goes red, at which point it would be fine
Alan McKinnon wrote:
> Masking already accomplishes everything you propose, which is to
> communicate "there is something wrong with this package and it is in
> danger of leaving the tree. To get it out of this state, you need to
> take action".
I disagree strongly that this is what masking commun
Markos Chandras wrote:
> You keep complaining about everything
I keep complaining about things that I think can be improved, while
I don't generally praise things that I think are already good enough.
There are so many problems to fix that I basically feel that time is
better spent on problems th
Markos Chandras wrote:
> > A per-ebuild bug metric would be cool. A kind of health indicator
> > for individual ebuilds, alerting users when some of our installed
> > ebuilds go yellow, so that we have perhaps on the order of six
> > months before the package goes red, at which point it would be
Samuli Suominen wrote:
> imho,
..
> we should stick to the "latest stable is the stable" mantra
> (i'm not sure if this is even documented anywhere? and propably
> should not be? keep it as maintainer specific decision like it's now?)
If it's the agreen-upon way then why not document it?
//Peter
Michał Górny wrote:
> Your thoughts?
+1
pgp1yo32f0xoD.pgp
Description: PGP signature
Michał Górny wrote:
> Any thoughts?
If doing this at all I think it should take an -r option to enable
the new recursion, for symmetry with the do* functions and for
backwards compatibility.
//Peter
Michał Górny wrote:
> > > Any thoughts?
> >
> > If doing this at all I think it should take an -r option to enable
> > the new recursion, for symmetry with the do* functions and for
> > backwards compatibility.
>
> Backwards compatibility with what?
With the old non-recursive behavior of edos2un
Jeroen,
Jeroen Roovers wrote:
> On Sun, 14 Apr 2013 14:51:28 -0700 "Gregory M. Turner" wrote:
>
> > Open source seems to arrive at consensus by means of a process
> > something like:
> >
> > whiny trolling ->
>
> Could you please take the obvious trolling elsewhere
Consider that it wasn't t
Tom Wijsman wrote:
> > > No, just a line in my vimrc that removes trailing whitespace.
> >
> > You should probably disable it or remove trailing whitespaces in a
> > separate commit though.
I agree strongly with this.
> > Having functional changes mixed with whitespace/cosmetics in a
> > single
Tom Wijsman wrote:
> > > You should just convert the commit diff to not include space
> > > changes.
> >
> > Tom, I don't understand what you mean here? Who should do the convert
> > and why?
>
> It's a human error for both ends, it can thus be done on both sides.
Hm, I'm not sure I follow.
Whe
Jeroen Roovers wrote:
> Er, you can't be seriously suggesting we will drop repoman checks
> with the migration to git? I don't see how that would benefit anyone.
I would argue that repoman and/or corresponding checks should be run
by a CI system hooked up to the Gerrit instance that developers pus
Peter Stuge wrote:
> Jeroen Roovers wrote:
> > Er, you can't be seriously suggesting we will drop repoman checks
> > with the migration to git? I don't see how that would benefit anyone.
>
> I would argue that repoman and/or corresponding checks should be run
&g
Michael Mol wrote:
> > I would argue that repoman and/or corresponding checks should be run
> > by a CI system hooked up to the Gerrit instance that developers push to.
>
> I was thinking something similar, actually, except you'd need
> something like this:
>
> 1. dev pushes to Gerrit
> 2. Gerrit
René Neumann wrote:
> * Is there a real difference between them? As far as I can see XSL
> is a superset of XSLT, but it's somewhat fuzzy.
XSL is the Extensible Stylesheet Language, one way to think of this
is as the file format. XSL is a subset of XML.
XSLT means XSL Transform, which is the proc
Carlos Silva wrote:
> Care to explain how will the installation be done if "networking"
> isn't requirement?
I build a stage4 tarball on a build host, and unpack that tarball
onto the media that I want to run the target system on.
That's just one way. The point is that nothing fundamentally requi
Carlos Silva wrote:
> > > Care to explain how will the installation be done if "networking"
> > > isn't requirement?
> >
> > I build a stage4 tarball on a build host, and unpack that tarball
> > onto the media that I want to run the target system on.
>
> And from where comes this build host exactl
Carlos Silva wrote:
> John Doe
..runs Windows.
> is it a safe default meaning that 99% or more of the people will
> use or *need* it?
Nobody suggested that networking should be disabled or excluded by default.
//Peter
Ulrich Mueller wrote:
> Is there any package where the files in SRC_URI cannot be mirrored
> (i.e., redistributed), but where the built package can be distributed?
All of them, when distributing binaries within a legal entity.
//Peter
Jörg Schaible wrote:
> icu. The ebuild happily removes any trace of the old shared libs
> with the result that half of the stuff that is *required* to build
> kdelibs is now broken. The build aborts and leaves behind a broken
> system. And this happened now not for the first time!
Tom Wijsman wrot
Peter Stuge wrote:
> Jörg Schaible wrote:
> > icu. The ebuild happily removes any trace of the old shared libs
> > with the result that half of the stuff that is *required* to build
> > kdelibs is now broken. The build aborts and leaves behind a broken
> > system. And th
Fabio, I think you're doing awesome work!
Steven, I think you can behave a lot better on the internet. kthx.
Steven J. Long wrote:
> > It looks like there is some consensus on the effort of making systemd
> > more accessible,
>
> Sure there is: there's also consensus that this approach is wrong
Ryan Hill wrote:
> If you're fixing one of these bugs by silencing the warning be sure
> to remove the flag also.
How about sending the fix upstream instead?
Thanks, from an upstream
//Peter
pgpHGm3ZpE6z3.pgp
Description: PGP signature
Michael Mol wrote:
> obviously you have an interesting position as a dev in a distribution,
> and you might make your change there, but that certainly shouldn't be
> your default course of action.
+1 and not just for unit files.
//Peter
pgpQGx9XaD1PC.pgp
Description: PGP signature
Rich Freeman wrote:
> > The devmanual git repository[1] moved to github[2].
>
> The only thing that isn't FOSS is github itself. Not sure if
> others feel strongly about it.
I feel strongly against github.
Making something like github the primary point of contact
communicates many negative thin
Markos Chandras wrote:
> The repository is still accessible in http://git.overlays.gentoo.org
> and read-only access is still available. However, the write access
> removed because of potential conflicts between g.o.g.o and github.
> If you can guarantee me that people will not mess things up and n
Rich Freeman wrote:
> Gerrit
> ..
> I've never used it myself but I'm tempted to install it just to
> start messing with it personally.
Go for it! It's a few steps to set up, but it's not too bad.
Michael Palimaka wrote:
> I believe Gerrit has been suggested before and rejected because it
> reli
Theo Chatzimichos wrote:
> > > Another option that looks nice is GitLab.
> >
> > How does it work? The screenshots look exactly like github.
>
> Don't ask, just go for it!
That's not very helpful?
I'm happy to expand on my experience with Gerrit, and I'll gladly
answer specific questions if I c
Michael Palimaka wrote:
>> I agree that Java is sucky, but I don't think that rejecting Gerrit
>> for that reason alone makes sense. Look at what the application does
>> and how it works, to determine if it fits the project or not.
>
> I agree, but if infra is not willing to maintain something jav
Alexander Berntsen wrote:
> > [GitHub] enforces some particular workflow
>
> You keep saying this. What do you mean?
I'll clarify!
> A lot of projects (including Linux) just use GitHub for hosting and
> nothing else. I don't see the problem.
There is no problem if github is only used for hosti
Alexander Berntsen wrote:
> > There is no problem if github is only used for hosting, but if it
> > is the primary point of contact, or if pull requests are accepted,
> > then github is also writing to repositories, and merge commits are
> > enforced for all external contributions. That does not sc
Rich Freeman wrote:
> Gerrit also requires letting the public push, but those pushes go
> to a contained area and each commit is isolated.
Hm, how do you mean isolated?
Gerrit introduces the convention to create a unique identifier for a
change the first time a commit is created. If later iterati
J. Roeleveld wrote:
> I don't see how this will avoid the issue of a limited amount of
> inodes.
> That is what I usually run out of before the disk is full when
> storing lots of smaller files.
I guess the number of unit files is on the order of hundreds, as long
as you haven't configured an INST
Luca Barbato wrote:
> - init gets effectively switched only at boot/reboot
Please not on reboot, because an unclean shutdown shouldn't leave the
system in limbo.
On boot could work, except that it does add more steps (= more
fragility) to the boot process, which I think everyone wants to
avoid.
Tom Wijsman wrote:
> > I would actually expect the change to take effect immediately.
>
> Then how would you be able to shutdown / reboot your system in a clean
> way? The premise here is that when you boot with an init system you
> must shutdown with that same init system, you can't just start on
Pavlos Ratis wrote:
> On Mon, Jun 24, 2013 at 1:04 AM, Diego Elio Pettenò
> wrote:
> > Please, let's not try to make this something either mandated or recommended.
>
> It is absolutely optional and it's just a proposal.
> However, I think it's worth a try.
I think it would be a wonderfully valu
Diego Elio Pettenò wrote:
> just opening a webcam and talking is just going to give an amateurish feeling
..as opposed to the very professional mailing list.
//Peter
Diego,
hasufell wrote:
> > I would object... 10 games are wa too few for a new category and
> > especially pkg moves..
>
> 1 app-antivirus/
> 3 net-zope/
> 5 x11-base/
> 7 gpe-utils/
> 8 app-officeext/
> 11net-voip/
> 12games-kids/
> 12gnustep-libs/
> 13mai
Rich Freeman wrote:
> Just what do wumpus (talk about a blast from the past), a game "in the
> spirit of nethack," and a Leisure Suit Larry spinoff have in common?
I'd say it's that they focus on exploration.
> I imagine most games have some kind of adventure sense to them.
Puzzles and 52-card
Matt Turner wrote:
> >> And? Two wrongs don't make a right.
> >
> > What do you mean by "And?" - it doesn't make much sense as a reply. :\
>
> He means that none of those provide justification.
It seemed that the main argument was that there are too few packages
and then then I do think that othe
Diego Elio Pettenò wrote:
> > I don't think anyone can dispute that there exists a genre called
> > adventure games..
>
> How comes scummvm is not in the list then? Just saying.
Yep, it could also be included! OTOH the VM itself isn't technically
a game.
> Seriously, a category for 10 games is
Diego Elio Pettenò wrote:
> > I bet you a tasty beverage that it will grow over time! :)
>
> I don't believe in the future until I can see it.
Huh - what does that mean?
Obviously neither of us can say with certainty what will happen in
the future and that's also not the point - making a friendl
Mike Pagano wrote:
> Team members working alongside upstream (and downstream) developer Greg k-h
> have decided to no longer request stabilization of the vanilla sources
> kernel.
> Team members and arch teams (understandably) are unable to keep up with the
> 1-2 weekly kernel releases, and th
Alex Xu wrote:
> > Maybe it would make sense to automatically stabilize every v-s kernel
> > right away?
>
> As has been stated, this implies that Gentoo QA has tested the packages
> and found them to be reasonably safe for use.
..
> Although stable kernels *have* been tested by many people before
Rich Freeman wrote:
> > As has been stated, this implies that Gentoo QA has tested the packages
> > and found them to be reasonably safe for use.
>
> ++
While good in theory, it seems that newer v-s are actually more
"reasonably safe" than any g-s.
> Stable should mean something
For users, sta
Alex Xu wrote:
> >>> Maybe it would make sense to automatically stabilize every v-s kernel
> >>> right away?
> >>
> >> As has been stated, this implies that Gentoo QA has tested the packages
> >> and found them to be reasonably safe for use.
> > ..
> >> Although stable kernels *have* been tested by
Rich Freeman wrote:
> >> Stable should mean something
> >
> > For users, stable means "older" in practice. Always did, always will.
>
> Don't change the meaning of stable, however, for those who find it useful.
This is a good point, but the original post suggested to me that
actually every new re
Ben Kohler wrote:
> > I am suggesting that the latest available upstream kernel should
> > perhaps be the default for Gentoo users.
>
> You seem to be ignoring the regressions that often come with new kernel
> releases, the very common breakage caused in stable "genkernel all", and
> other various
Tom Wijsman wrote:
> what if hell breaks loose next time?
We fix it.
//Peter
pgpoxOD8NPi7O.pgp
Description: PGP signature
Tom Wijsman wrote:
> > Besides, who does an emerge -u world without first checking to see
> > what will be updated?
>
> Some people do
They deserve a broken system.
//Peter
pgp8bIGEpU77h.pgp
Description: PGP signature
Greg KH wrote:
> See above for why it is not easy at all, and, why even if we do know
> some fixes are security ones, we would not tag them as such anyway.
I think this supports the argument that the better kernel is always
the one with the most fixes.
Rather than separating "bug fixes" from "sec
Greg KH wrote:
> > > See above for why it is not easy at all, and, why even if we do know
> > > some fixes are security ones, we would not tag them as such anyway.
> >
> > I think this supports the argument that the better kernel is always
> > the one with the most fixes.
>
> That's what us kerne
Samuli Suominen wrote:
>> +++ b/Makefile.am2013-08-11 23:31:55.429404471 +0200
> [ ... ]
>> if UDEV_RULES
>> -udevrulesdir=$(sysconfdir)/udev/rules.d
>> +udevrulesdir=$(shell pkg-config --variable=udevdir udev)/rules.d
>
> Calling `pkg-config` directly from Makefile.am doesn't work for cross
Luca Barbato wrote:
> > [3] https://wiki.documentfoundation.org/Development/gerrit
>
> And all boils down to the fact gerrit needs to be fixed to take
> patches from a mailing list
Usually Gerrit just needs an OpenID in order to accept git push via SSH.
That seems significantly better to me than
Ryan Hill wrote:
> I don't like creating more work for people, so I want to be sure
> there is consensus on this first. So far it sounds like there is.
I think there will come enough objections, but only down the road,
and only from people who don't want to care about quality.
Don't let that sto
Markos Chandras wrote:
> the whole eclass is inside the " if [[ ! ${_GIT_R3} ]] " block.
Rather than putting the whole eclass inside a block like that maybe
it's possible to test for that condition and "exit" early?
//Peter
Michał Górny wrote:
> > > the whole eclass is inside the " if [[ ! ${_GIT_R3} ]] " block.
> >
> > Rather than putting the whole eclass inside a block like that maybe
> > it's possible to test for that condition and "exit" early?
>
> exiting ebuild process in middle of inheritance chain is *not* a
"Paweł Hajdan, Jr." wrote:
> Also, it may be easier to change now when we only have two headers,
> than later. And you may even add compatibility symlinks or copies in
> /usr/include to give people more time to update.
I think you should rip off the band-aid quickly.
Move the files and update the
Michał Górny wrote:
> Putting another includedir is even worse kind of band-aid.
By using the expression band-aid I wasn't commenting on the virtues
of having the include file in /usr/include.
The expression "rip off the band-aid" is an idiom in english which
refers to minimizing the duration of
"Paweł Hajdan, Jr." wrote:
> "compiling with versions of v8 other than what is included is not
> currently supported."
..
> For now V8 upstream gives no guarantees about API/ABI stability and
> actually breaks it very often
I agree that it isn't worth the effort to try to offer V8 as a
library the
hasufell wrote:
> No bump is better than a shitty bump imo.
I agree, but I think the problem is basically that many people
consider it impossible for "newer" to ever be shitty.
Even if they are intimately familiar with the details of a package
upstream they may still not be capable of determining
Michał Górny wrote:
> My laptop is broken and I no longer have any hardware that would use
> this. It fails to compile with the current kernel [1] and upstream is
> not really active.
I forward-ported the driver in 2011 but probably that's obsolete too.
http://git.stuge.se/stk11-driver.git
//Pe
Markos,
Markos Chandras wrote:
> This is not a great way to invite more users to participate. If you
> intend to make the game overlay and team a developer-only thing you
> are doing a great work.
Everything in the Gentoo project is per definition strictly
developer-only. I suppose that it's a fu
Tom Wijsman wrote:
> There is an alternative solution here; and that is to bring reviewed
> versions of them to the Portage tree or official games repository, and
> honor their contributions. That is a win-win situation for both of you.
I'm afraid that's too naive. :\
I have significant experienc
Rich Freeman wrote:
> >> This is not a great way to invite more users to participate. If you
> >> intend to make the game overlay and team a developer-only thing you
> >> are doing a great work.
> >
> > Everything in the Gentoo project is per definition strictly
> > developer-only. I suppose that i
Rich Freeman wrote:
> If a package has a responsive maintainer, then pinging them isn't
> really much of a hurdle.
I'm not so sure. Waiting for a human round trip which due merely to
time zones might occupy my attention for 24 hours (even if I
obviously do other things meanwhile) is IMO quite sign
201 - 300 of 549 matches
Mail list logo
