Ciaran McCreesh wrote:
..and it means we can't change name or version rules.
Why? Just parse the EAPI out of the file before you interpret the
version and name from the filename. Indeed - you could have a future
EAPI remove the name and version from the filename entirely. If a
package
Petteri Räty wrote:
3) EAPI in locked down place in the ebuild
- Allows changing global scope
- EAPI can't be changed in an existing ebuild so the PM can trust
the value in the cache
I don't see how this follows. The PM can compare the mtime on the file
with the time the cache was
Duncan wrote:
So putting it in the manifest but generated from the ebuild info really
doesn't change the problem, leaving us precisely where we were before,
except that it may be useful as a component of one of the other
solutions, and has been proposed as such in a few of the suggested
Donnie Berkholz wrote:
On 14:05 Fri 13 Mar , Michael Higgins wrote:
Even if they are, an IRC log is a *terrible* way to document an issue.
I agree. So is a mailing-list archive that is also never summarized.
It's not the location that makes it a problem, it's the volume of
information
Andrew D Kirch wrote:
I reject the premise that war should always be prevented. I am however
concerned that criticism where criticism is due is flame baiting.
The original post did not contain any constructive criticism of paludis
at all. It simply stated that under no circumstances should
Ciaran McCreesh wrote:
Most packages that have tests have working tests. For those that don't,
the tests have to be restricted. All this proposal does is ensures that
that happens in a progressive, incremental and safe way.
I agree with this point - failing tests are more the exception than
Ciaran McCreesh wrote:
This isn't a usability request. Making the use paludis --info cat/pkg
text stand out more was a usability request, and I was happy to make
that change. This is a few noxious trolls whining in an attempt to cause
trouble.
For those who have concerns with the paludis
Mart Raudsepp wrote:
So my point is that the whole of the council should consider the
objections of an individual council member, so that potentially bad
things don't end up accepted based on some kind of an uninformed
majority vote or concensus.
Probably the best way to accomplish something
Markos Chandras wrote:
I am sure that you know them. But those problems are the reasons why more and
more developers are demotivated and leaving Gentoo. 'Fixing' those problems
should be a N1 priority on every gentoo council meeting until they are gone.
There is absolutely no point in trying
Arun Raghavan wrote:
As for the songs, does it make sense to put that in a separate package
that the code package depends on? The package can have the restrictive
license it is distributed under and RESTRICT=mirror bindist.
That was my first thought as well - just split out the songs and
Markos Chandras wrote:
Even a volunteer-driven organization needs some standard rules in order to
survive. From time to time this volunteer moto is what some people consider
as anarchy
As far as survival goes - I think the rumors of Gentoo's death are
greatly exaggerated. I certainly
Thomas Anderson wrote:
It seems to me you're on a irc-hate rampage. There are many devs who
rarely, if ever, go on irc. The _only_ requirement is that you conduct
a real-time interview with a recruiter.
I have to agree with this sentiment - I have nothing against IRC but it
is a bit too
Duncan wrote:
But no matter, the practical fact of the matter is that for someone who
would otherwise not do IRC, it's just one more hurdle in the process.
Whether it's useful or not, trivial or vital, no longer matters, it's
defined by the gatekeepers as a requirement, therefore, by said
AllenJB wrote:
All that's going to happen is Gentoo will have many many buggy and out
of date packages in the MAIN TREE. Exactly where they shouldn't be. You
claim quality won't be sacrificed, but I simply can't see this without
any attempt to solve the manpower issues first.
Isn't the
Mart Raudsepp wrote:
Liking and using the package yourself shouldn't be a prerequisite for a
package getting to be in-tree by the maintainer-wanted team.
How about actually maintaining the package?
For example, user contributes ebuild for foo-1.0. I don't use it or
like it, but I go ahead
Thilo Bangert wrote:
AFAIK, we have never explicitly made this distinction clear. if we had, we
would have to remove stuff from portage which doesnt live up to the
standards.
I'm all for that. In reality we tend to leave them alone until a
security issue actually comes up, which is
Ciaran McCreesh wrote:
On Thu, 14 May 2009 20:06:51 +0200
Patrick Lauer patr...@gentoo.org wrote:
Let EAPI be defined as (the part behind the = of) the first line of
the ebuild starting with EAPI=
Uh, so horribly utterly and obviously wrong.
inherit foo
EAPI=4
where foo is both a
Ciaran McCreesh wrote:
You've missed the point. The point is, the EAPI process can't avoid the
huge wait before we can use it for certain types of change that
would be extremely useful. GLEP 55 fixes this limitation, and it's the
*only* thing that fixes this limitation.
Except that if we had
Nirbheek Chauhan wrote:
Let's not blatantly ignore our REAL problems. We can no longer afford
to maintain the status-quo of pedantic masturbatory discussions on the
finer points of ebuild formats. We cannot AFFORD to look the other way
while the distro rots away.
What exactly is your
Ciaran McCreesh wrote:
Had we gone with any of the other proposals a year ago, we'd be waiting
a year every time a new change came along.
Only if that change prevented obtaining EAPI from wherever it was
placed. If you want to make the rule EAPI=foo appears at the start of
a new line at
Ravi Pinjala wrote:
Nick Fortino wrote:
Such a transformation is possible, given the restrictions on arg, as
well as ebuild format.
Isn't this a bit circular? The whole point of wanting to change the
extension is to get rid of exactly these restrictions; if you assume the
restrictions, then
Duncan wrote:
So I believe the cost to be quite reasonably managed, after all.
Benchmarks would of course be needed to demonstrate that, but I believe
it worth pursuing.
Agreed. Perhaps I'm just spoiled by RDBMS's at work or something, but
it seems like we're trying to squeeze every
Ciaran McCreesh wrote:
The only way it'll be in the next ten years rather than in the next
two years is if Gentoo continues its current approach of making
changes require every single person to agree...
Frankly, I won't be at all surprised if this thread (in some form) is
still going on in
Alistair Bush wrote:
Is it really necessary to convince the entire community for every GLEP?
I thought that the reason we have the council is so they can make
decisions. You know specialization of decision making. If the council
is going to expect anyone else, besides themselves, to
Disclaimer - I too am not a lawyer.
Mounir Lamouri wrote:
I'm not a lawyer so I can't say for sure some software _need_ explicit
license acceptance to be used. However, I'm quite sure using a software
means accept the license.
Someone experienced in this area is welcome for clarifications.
Ryan Hill wrote:
I'm tired of playing, as I'm sure you are. So please,
let's be quiet now, and let the big people talk.
This is a public list designed to facilitate discussion of gentoo
software development. Anybody with something constructive to say is
more than welcome to speak up -
Duncan wrote:
A team can have the best rhetoric in the world, but if they don't
actually show up and field a team on game day, they lose by default.
Fortunately or unfortunately, that looks to be where this is headed.
Agreed, there is definitely something to be said for offering solutions.
Patrick Lauer wrote:
If I should have forgotten any approach or misrepresented one I'd
appreciate an updated or rephrased section so it can be easily
updated.
This keeps coming up for some reason:
parsers: It enforces some minor limitations, for example EAPI needs to
be unique and cannot be
Mounir Lamouri wrote:
I would like to get ACCEPT_LICENSE default value [1] discussed in the
next Council. If I can even get it widely discussed in gentoo-dev before
the council, a vote will be great. But it looks like it is not
interesting so much people out there.
Why not make a definitive
Marijn Schouten (hkBst) wrote:
Richard Freeman wrote:
Without actually intending to open a new debate on that issue cringes,
I'm actually a fan of NOT obtaining PN and PV from the filename. I've
seen an approach like this used in various systems and I happen to like it:
In which systems did
Denis Dupeyron wrote:
In my manifesto [1] I have proposed something significantly different
which simply consists in spinning the long discussions off the
council meetings using more focused groups
++
I've seen this used to good effect on projects at work. The only
challenge might be the
Doug Goldstein wrote:
The amount of time spent
debating something over the pretty look and not over technical merits
creates terrible signal-to-noise ratios (where I consider the pretty
debates as noise and the technical merits as signal).
I'm not sure that much time on this list is spent
Ulrich Mueller wrote:
Let's assume for the moment that we change from .ebuild to .eb.
Then we obviously cannot change all ebuilds in the tree to .eb,
otherwise old Portage versions would see an empty tree and there would
be no upgrade path.
Or am I missing something?
That is a good point.
Patrick Lauer wrote:
And if you really absolutely have to do that you can change the sync
location on every disruptive change, but (imo) that should be
avoided.
If mirroring and other practical concerns weren't an issue what you're
essentially describing is just moving to a CVS/git/etc
Nirbheek Chauhan wrote:
Please, do not waste everyone's time and bandwidth with thoughts that
do not belong on this list, and hence they do not care about.
Let's be nice. Somehow I don't think Duncan's goal was to get the
mailing lists to be as flame-filled as he perceives IRC to be... :)
Ben de Groot wrote:
In my opinion it is in the best interest of Gentoo at this point to
ignore Exherbo and to silence those people involved with Exherbo that
have been so divisive and generated so much conflict in Gentoo channels.
Nobody needs to be silenced (unless they're litereally
Doug Goldstein wrote:
On Wed, Jul 1, 2009 at 9:33 PM, Ned Luddso...@gentoo.org wrote:
Meetings will likely go back to one time per month and be +m with +v be
handed out per request with open chat pre/post meetings. The reason for
this is to keep the meetings on-track. I won't engage in endless
Luca Barbato wrote:
Jorge Manuel B. S. Vicetto wrote:
I have a few ideas about this that I'll have to put in writing and share
later, but let me start by proposing that for such a change we require
the support of at least 2/3 of the devs that vote *and* a minimum of 1/3
of all devs.
I'd use
Jesús Guerrero wrote:
Most Gentoo users will have no problem to use overlays as they need
them. If we had more developers we could as maintain more packages,
as simple as that.
I actually tend to agree with this position, however to use overlays as
a valid solution for end-users we need to
Jesús Guerrero wrote:
Yeah, devs for that as well.
Yup - I think we're actually on the same page. Ultimately quality
matters more than quantity and everybody does what they can given the
resources we have.
Right now it is at least a little painful to get set up with an overlay.
No,
Olivier Crête wrote:
~arch is for testing ebuilds, not the upstream package
I'm pretty sure this isn't the case - at least not as cleanly as you
suggest. Certainly testing the ebuilds themselves is part of the reason
for having ~arch, but upstream readiness is part of it as well. If a
Ryan Hill wrote:
So, should we always keep a working EAPI 0 version around? If not, when can
we drop support for old EAPIs? Your opinions please.
You might want to define what you mean by dropping support for old
EAPIs? Do you mean:
1. No longer ensuring that users who have pre-EAPI
Rémi Cardona wrote:
May I request a faster commit time since I didn't expect Samuli to
stabilize everything so quickly?
Yup - I wouldn't be surprised if within a few hours 80% of the concerned
users will have already installed it. Even if you send out the news now
anybody who synced
Joshua Saddler wrote:
On Sat, 3 Oct 2009 20:45:21 +0300 Markos Chandras
hwoar...@gentoo.org wrote:
This is actually true. Maybe all devs should have access on docs
since the docs teams are dead. I would suggest to let all
developers contribute to documentation whether they belong to docs
team
Jesús Guerrero wrote:
In my opinion, if we really want to speak about a way to implement that
kind of snapshoting, we should start thinking about providing a better
integration with lvm, from the root. lvm can take care of the snapshots on
a non-expensive way, and it would be relatively easy to
Duncan wrote:
Actually, yes. Gentoo has never been a hand-holding distribution. We
try to provide documentation and reasonable defaults for any apps the
user chooses to install, and let the user configure what they will.
Gentoo is about choice. Well, except for the choice to not have to
Mart Raudsepp wrote:
Is it stated in any documentation that 30 days is a policy?
Not that I'm aware of - it is a guideline as you indicate. However,
don't expect anybody to actually take action on a STABLEREQ if there
isn't some kind of rationale for going stable so quickly.
The whole
Petteri Räty wrote:
#SRC_URI=mirror://sourceforge/${PN}/${P}.tar.gz
# starting to hate sf.net ...
SRC_URI=http://foremost.sourceforge.net/pkg/foremost-1.5.6.tar.gz;
The filename that violates our policies hasn't changed between the new
and old SRC_URI.
Is this policy actually written down
Peter Volkov wrote:
1. Our good non-formal policy if developer touched anything he becames
responsible for that ebuild and should fix issues noticed is sometimes
ignored. We see people reacting: you've noticed - you fix. I think such
attitude is unacceptable.
Keep in mind the downside to such
Antoni Grzymala wrote:
How about getting back to GLEP-57 [1]? Robin Hugh Johnson made an effort
a year ago to summarize the then-current state of things regarding tree
and package signing, however the matter seems to have lain idle and
untouched for more than a year since.
One concern I have
On 12/13/2009 02:49 PM, Robin H. Johnson wrote:
On Sun, Dec 13, 2009 at 10:44:05PM +1100, Daniel Black wrote:
Recently this got produced as a draft license for parties distributing
CAcert's root certificate(s) (like us).
On 12/14/2009 03:10 PM, Robin H. Johnson wrote:
1.4 Vendor's Agreement with End-User
Vendor agrees
1. to distribute both the NRP-DaL and this present agreement to end-user,
Ah, this was my mistake. I read that as to distribute both the NRP-DaL
and present this agreement to [the]
On 12/15/2009 01:46 AM, Daniel Black wrote:
I did email the debian maintainer too. no response yet. They have interactive
builds though and I guess we do too now. Will be a royal pain if every
CA/software did the same thing.
The last thing gentoo needs is interactive builds. XFree86 was
On 12/21/2009 02:54 AM, Fabian Groffen wrote:
If all mail that would go to -dev-announce would guaranteed be sent to
-dev as well, I didn't have to check -dev-announce, and archives.g.o
would also have the original January 2010 meeting date mail in the
thread on -dev.
Or you could just
On 12/20/2009 01:04 PM, Jeremy Olexa wrote:
Flattered, but I decline. I don't agree with the way the Council works
and don't have motivation to attempt to change it.
Out of curiosity, would you care to elaborate? I don't have much of a
political axe to grind so I guess I tend to stay out of
On 12/21/2009 06:33 AM, Richard Freeman wrote:
On 12/20/2009 01:04 PM, Jeremy Olexa wrote:
Flattered, but I decline. I don't agree with the way the Council works
and don't have motivation to attempt to change it.
Out of curiosity, would you care to elaborate? I don't have much of a
political
On 12/23/2009 01:36 PM, Paul de Vrieze wrote:
Perhaps we should create a schema to validate the file. XMLSchema (or
any of the other standards) allows for much more flexibility in
specifying these things. Btw. I did not design the metadata DTD for
order to be significant. The only priority is
Started new subject since this is only tangentially related to the election.
On 12/27/2009 06:16 PM, Tomáš Chvátal wrote:
Anyway, i wont write huge manifesto but these things i would like spent
my time:
QA propagation (motivating people, explaining why we are doing stuff and
so on)
Could
On 12/28/2009 06:23 AM, Tomáš Chvátal wrote:
we should ENFORCE it, not just fill bugs about it, because mostly people
tend to ignore that things.
Agreed, although some presumption of innocence should be assumed. If a
dev is ignoring repoman output that is a fairly big violation, but if a
On 12/28/2009 01:56 PM, Robin H. Johnson wrote:
Actually, this is a case where the license on the ebuild is wrong, not
the license group. The kernel ebuilds should have GPL-2 and something
else, and by definition should not pass @FSF-APPROVED alone.
Is this appropriate? The kernel sources
On 12/28/2009 05:53 PM, Robin H. Johnson wrote:
You're wrong there. The kernel does contain additional licenses, and
EXPLICITLY mentions them. Go and read 'firmware/WHENCE'.
The licenses listed therein range from use-permitted only
no-modification, to GPL-compliant and BSD-like.
I stand
On 12/29/2009 07:52 PM, Greg KH wrote:
No, the readme/copying is correct, it covers all of the code that runs
on the processor as one body of work. Firmware blobs are different in
that they do not run in the same processor, and can be of a different
license.
Yes, but they don't cover
On 12/30/2009 05:18 AM, Petteri Räty wrote:
You need to understand what the world set means. The world set is the
packages in /var/lib/portage/world and the sets from
/var/lib/portage/world_sets . From this follows that we can't change the
content of the world set as it's a user specific
On 12/30/2009 11:48 PM, Greg KH wrote:
Heh, no, it does not, unless your BIOS, and your keyboard firmware, and
your mouse firmware are all under a free license. The only thing
close to this type of machine is the OLPC, and even then, I don't think
all the microcode for the box was ever
On 12/30/2009 12:14 PM, Ben de Groot wrote:
2010-01-21:
* Qt team meeting: discuss actions to be taken regarding remaining
pkgs that use qt:3
2010-02-21:
* mask qt:3 and depending ebuilds, pending removal
30 days isn't a long time. How about filing bugs against anything that
currently
On 12/31/2009 08:24 AM, Samuli Suominen wrote:
On 12/31/2009 03:13 PM, Christian Faulhammer wrote:
Hi,
Samuli Suominenssuomi...@gentoo.org:
Just saying...
Please track progress somehow. I know it is a lot of work, but makes
understanding the process easier.
V-Li
It's been done in,
On 12/31/2009 07:51 AM, Samuli Suominen wrote:
Stable MythTV has more issues than just Qt3, as the current stable
doesn't compile anymore, http://bugs.gentoo.org/show_bug.cgi?id=280303
which is about to get masked tomorrow with kdelibs-3...
Those of us who run it wouldn't mind seeing a
On 01/05/2010 01:07 PM, Duncan wrote:
Periodically there's talk of adding + versions of at least the FSF
licenses, but while it would probably be quite a good thing, it'd be a
LOT of VERY boring work poring thru all those packages and either
updating to the + version, or leaving comments in each
On 01/07/2010 01:19 AM, Vincent Launchbury wrote:
All I'm asking for is that users who care about this will be shown an
accurate license,
I think that this really sums this whole thing up. Can you run a
computer with ONLY FOSS on it (firmware to ROMs to hard drive
controlers) - probably
On 01/07/2010 05:46 AM, Hanno Böck wrote:
I think the GPL-compatible set makes barely sense.
++
Difference between OSI and FSF approved: ... I think the definitions
of FSF and OSI are pretty much the same, ... So I'd like it much more
to have one big This is free and open source software
On 01/08/2010 12:26 AM, Greg KH wrote:
If the kernel loads a firmware
file that is not free, or if the device itself has a firmware in it that
you can not change so easily, has _nothing_ to do with the license of
the kernel,
I don't think anybody is concerned about the license of the kernel,
On 01/11/2010 06:30 PM, Arnaud Launay wrote:
As a newsmaster, I'm a bit concerned by this.
Yeah, inn seems like a really high-profile package to mask for removal.
It would be conspicuous in its absence.
Would it make sense to post on -dev BEFORE masking packages like this?
I'm sure there
On 01/11/2010 10:43 PM, Jeremy Olexa wrote:
(A general reply, not targeted towards you, Rich)
No prob - my post wasn't really directed personally at anybody.
Speaking on behalf of the treecleaners:
The fact is, some of us have never heard of inn and until Gentoo has
some sort of popularity
On 01/12/2010 01:30 PM, Markos Chandras wrote:
IMHO ( this is not a treecleaners@ opinion, i m just talking for my
self ), announcing and masking a package is a good way to inform and wake up
everybody to take care of this package if they really really want to stay on
portage.
I agree with the
On 01/13/2010 09:24 AM, Mike Frysinger wrote:
On Tuesday 12 January 2010 15:51:28 Tomáš Chvátal wrote:
And since WE want to enable as-needed as default at some time we need to
work on the bugs
which isnt going to happen
This isn't really intended to point fingers at anybody in particular -
On 01/13/2010 10:06 AM, Arnaud Launay wrote:
which kind of explain what is a proxy maintainer (more or less),
but does not explain how to become one...
We don't really have any official process around this. Things like
sunrise and proxy-maintainers are good ways to get new blood into the
On 01/17/2010 03:20 PM, Thilo Bangert wrote:
Ben de Grootyng...@gentoo.org said:
I think we have a bigger problem with packages that have a maintainer,
at least nominally, but said maintainer does not actually maintain the
package anymore.
full ack. i was thinking that maybe we need an
On 01/17/2010 08:23 PM, Ben de Groot wrote:
What about something like: if a bug has been open for 2 months without
any apparent maintainer activity, anyone can step in and commit a fix?
How about - anybody at any time can at their discretion post a comment
in a bug asking if there are
On 01/24/2010 01:20 PM, Ben de Groot wrote:
2010/1/24 Petteri Rätybetelge...@gentoo.org:
On 01/24/2010 03:02 PM, Ben de Groot wrote:
Why should we keep redundant information in the list?
How is that redundant?
Well, I doubt we'll get away from python in the system set anytime soon,
but
On 01/24/2010 07:02 PM, Dale wrote:
Is there something that I am missing here? For me, system should
include the things needed for booting and for the package manager to
work.
It should include the programs directly involved in booting, and the
package manager. I'm not sure that it should
On 02/20/2010 09:23 PM, Robin H. Johnson wrote:
The MySQL 5.1 news item with all updates is now commited, and 5.1.x have
been unblocked in package.mask.
It looks like that news item is visible to users running stable as well.
When 5.1 eventually goes stable we might want to re-announce it
item (I can commit if there are no
objections - and be gentle as I just parsed the GLEP - also posted to
the bug 299222):
Title: MythTV 0.22 Upgrade Database Corruption
Author: Richard Freeman ri...@gentoo.org
Content-Type: text/plain
Posted: date
Revision: 1
News-Item-Format: 1.0
Display
suspect the other arch teams feel
similarly - nobody wants to just commit something like this without
testing and good documentation.
How about this revised news item:
Title: MythTV 0.22 Upgrade Database Corruption
Author: Richard Freeman ri...@gentoo.org
Content-Type: text/plain
Posted: date
On 02/26/2010 07:06 AM, Ben de Groot wrote:
Is there a simple way for users to determine what client versions they may have?
Forwarding my reply:
Well, they can always just ask the package manager what version is
installed. The news item is targeted only at users who do not already
have
On 03/01/2010 09:24 AM, Ben de Groot wrote:
The 72 hours have passed, so I take it we are ready to officially
publish this. Richard, are you going to commit this?
I will do so today.
On 03/03/2010 09:41 PM, Dale wrote:
So in the situation above, removing cups doesn't help any? The user
would still have to work around the dependency problem. Is there not a
better way to handle this?
Agreed that there should be better ways of handling things.
However, at the very least if
On 03/04/2010 08:57 PM, Patrick Nagel wrote:
Obviously, users who re-install Gentoo the way you do will have less
difficulties resolving a circular dependency than those who are just following
the guide and getting their first Gentoo experience.
I think that the cups issue is probably worth
On 03/05/2010 08:06 AM, Ben de Groot wrote:
On 5 March 2010 04:18, Graham Murraygra...@gmurray.org.uk wrote:
3. Include one or both of the packages in the stage tarball.
None of the packages involved (gtk+, cups and poppler) is in any
shape or form essential, so you will have a very hard
On 03/10/2010 04:42 PM, Duncan wrote:
So a gmail account is now considered mandatory for Gentoo devs, at least
if they want calendar access?
What about those who might think that Google knows enough about them with
search and the web crawling and database correlation Google does, and
whatever
On 03/11/2010 03:53 PM, Alec Warner wrote:
however if it becomes some kind of integral part of Gentoo
(which I doubt it will) we will have to look at switching to something
else (which is easy given the many export formats of Google Calendar
:))
I think you hit the nail on the head. Right
On 03/18/2010 04:34 PM, Ben de Groot wrote:
Recruitment being the bottleneck that it is (with candidates
waiting many months), it is good to have another option
for people who want to contribute.
If we do have a list of people waiting to get in, could we maybe publish
this list somewhere, or
On 03/24/2010 02:28 PM, Joshua Saddler wrote:
On Wed, 24 Mar 2010 19:04:51 +0100 Arfrever Frehtes Taifersar
Arahesisarfre...@gentoo.org wrote:
People, don't want Python 3, probably have already masked it. There
is no reason to waste Council's time for decision on what sentence
should be
On 03/24/2010 11:47 PM, Joshua Saddler wrote:
Even then, it'll likely get
installed first, as users will probably learn about p.masking it only
*after* they install it.
I don't have strong feelings on whether having v3 installed by default
is a big problem, but the last bit here probably
On 03/28/2010 06:04 AM, Tomáš Chvátal wrote:
Basically you are saying that NONE tested that package on the arch until
the stablerequest. That's quite wrong and it should mean that the arch
should be ~ only, since they are stabling packages that they first
tested the day they stable them.
On 03/28/2010 10:27 AM, Duncan wrote:
The point being, perhaps I'm wrong and openrc does have a broader
distribution basis than I'm aware of, but in practice, it seems all of
these tend to be used /almost/ exclusively with Gentoo and Gentoo based
distributions. If openrc's usage is rather wider
On 04/03/2010 06:19 AM, Tobias Scherbaum wrote:
And still, when someone tries to fix things in such an understaffed herd
people go all territorial and are like omg u touched my package.
Right now I'm quite confused what our project strategy seems to be, as
far as I can tell there's one group
On 04/05/2010 03:48 AM, Ciaran McCreesh wrote:
On Mon, 05 Apr 2010 03:33:52 +0200
Tobias Heinleinkeytoas...@gentoo.org wrote:
3) Questions that aren't that important at all and would just be nice
to know.
[snip]
Examples for these:
5. What is wrong with using $(somecommand) or `somecommand`
On 04/04/2010 02:09 PM, Denis Dupeyron wrote:
All ideas regarding improving recruitment are welcome, thanks. However
if, during your review, you were not given the impression that your
maturity and other social skills were being assessed then you were
being blissfully naive. :o)
That
On 04/05/2010 10:13 PM, Nirbheek Chauhan wrote:
* Proposed is to generate ChangeLogs from git commits on the rsync
server side when metadata generation is done
- Scripts to do this already exist[1]
I haven't seen this discussed, so I'm going to toss this out there and duck:
Why not just
On 04/07/2010 05:58 AM, Angelo Arrifano wrote:
3*) With git, one would just branch (lets call it embedded branch) the
package. Apply the patches there and let people using embedded profiles
to emerge from that branch instead of master.
Benefits? I think they are pretty obvious - people can start
1 - 100 of 212 matches
Mail list logo