Re: [gentoo-dev] *DEVELOPMENT* mail list, right?

2007-04-10 Thread Robin H. Johnson
On Thu, Apr 05, 2007 at 07:03:45PM -0400, Michael Cummings wrote:
> So, fellow devs, what's new with development?
Over in the council, we've been doing some status updates of this
similar nature, mainly so we all know where we are at (for all the core
things that each of the council members are doing, not just limited to
council business). The last two meetings have been packed with other
stuff, so we've missed that then, but I'm hoping to get back on them
with the meeting later this week.

Various Gentoo things I'm working on presently, outside of the regular
everyday work of ebuild work and infra work:

- GLEP on bug-wrangling process (nailing down the good and the bad of what
our wranglers like Jakub are doing, so would-be wranglers can have a
good idea of what to do).

- Series of GLEPS on signing the tree/Manifests. So far it's 5 GLEPs in
the set (the series working title is 'Security of distribution of Gentoo
software'):
  00 - Overview and Background Information
  01 - Infrastructure to User distribution - MetaManifest
  02 - Developer processes
  03 - Handling of GnuPG for developers and keymasters
  04 - Manifest2 hash policies and security implications
Of this series, 00, 01 and 04 are pretty much complete, but 02 and 03
need a lot more work still.

- Infra work for inbound SMTP servers (two of our older boxes being
repurposed) since the existing box is overload with mail processing.

- Slightly outside of Gentoo, but still relevant, I've been working on
some things with Git so that it's closer to a working solution for CVS
migration (the history slicing feature that we require is completed, and
subtree slicing is in progress).

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Council Member
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpVB0K6CXr2u.pgp
Description: PGP signature


[gentoo-dev] Re: RFC: extending project xml to have stuff that the project is working on and collect them as Gentoo current goals

2007-04-10 Thread Duncan
Petteri Räty <[EMAIL PROTECTED]> posted [EMAIL PROTECTED],
excerpted below, on  Tue, 10 Apr 2007 23:34:25 +0300:

> As the recent thread showed there is a lot going on in Gentoo land
> although it doesn't always seem so. I propose we extend project xml to
> describe current stuff going on in the project in question and their
> estimated completion date. Then we require this file to be updated
> monthly. What do you think?

I think proposals such as this have come up before. (No offense 
intended.  In fact, probably you and enough others it's time to outline 
the reasons again, simply weren't around at the time.)  I think they went 
nowhere, in part because it was thought to be just more bureaucracy 
forced (the term you used was required) on the team leads, to little 
ultimate effect (see kloeri's cron remarks).  

Remember, Gentoo's all volunteers.  You can't force them to do it as part 
of their job (for their paycheck).  What's the penalty going to be?  
Suspension of the team lead, throwing a monkey wrench in the progress 
that was being made?  Dissolving the project?  From what I've observed 
here and elsewhere over the years, a "requirement" that can't be enforced 
is a very unhealthy thing.

Thus, it's not a very practical idea, or at least no one was able to 
figure out how to make it such in previous rounds.

Instead, what tends to happen is somewhat less frequently and more 
informally, but perhaps more effectively as it's not forced. 
Periodically, perhaps twice a year or so, someone starts a thread like 
the one you referred to.  Often it's prompted by year-end or mid-year, 
and someone posts an impromptu summary of where their project is.  Other 
times, it's as this one, started for other reasons.  However, once one 
person posts a summary, another does and another, and pretty soon most of 
the projects have... and everybody did it impromptu, nothing "required" 
about it. =8^)

Of course, in more specific cases, the council notices and ultimately 
meetings often bring about discussion of projects of particular interest 
at the moment.

In any case, it may not get to the project's web page, but anyone (dev, 
user, journalist, or simply curious public) caring enough to follow this 
list ends up seeing the updates as I said, perhaps twice a year or so.  
If one were suitably devious, one could even scheme to generate such a 
thread starter every few months (cron /that/ reminder =8^), just to get 
the pile-on effect and see where everyone was, again without "requiring" 
reports of anyone. =8^)

Of course, often these threads get mentioned in GWN and thus features not 
only there, but as a result on the Gentoo home page and on community 
sites such as LWN as well, so one doesn't even have to follow this list 
to know about it, only make /some/ effort to be keeping up with general 
things Gentoo, and they'll probably see coverage of the thread.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Why don't you just ...

2007-04-10 Thread Luca Barbato
Christopher Sawtell wrote:
> On Wednesday 11 April 2007 10:56:40 Benedikt Boehm wrote:
>> ... don't care about an uber-vision or direction and just keep your
>> friggin packages alive and working?
> Indeed!!
> 
> Doing an   emerge --deep --update world   last week b0rked updating about a 
> couple of dozen packages. Evenutally I realized that the problem was 
> gcc-4.1.2 had a supposedly executable file filled with zeros in its 
> file-set.

Did you fill a bug about it? I have 4.1.2 in most of my systems and they
are working fine. Sounds a quite local problem, can you reproduce it?

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Why don't you just ...

2007-04-10 Thread Alec Warner
Matthias Langer wrote:
> 
> Well, I don't know what your problem really is about; I'm running x86,
> and if something breaks on my system, it's mostly not because of broken
> packages, but because I should have been informed about possible issues
> that could have been caused by an upgrade, and how to avoid them. Often,
> ebuilds contain very important information that are brought to the user
> via elog, ewarn and friends. The problem with this approach is, that I
> won't read these messages if I'm doing a world update while I'm asleep.
> This is, why I think, that it should be one of Gentoos highest
> priorities to implement Glep 42 and make heavy use of it.
> 
> Matthias

Your post brings up an interesting concept; that Gentoo is both a
repository of ebuilds and is also a distribution of packages.

Providing ebuilds for X number of packages is a nice thing and if you
complain about Gentoo being too large and too undivided you could devide
the work there.  Maintaining a set of packages involves writing ebuilds.

Maintaining a distribution involves much more work; I think for some
it's not exactly the work they are interested in and it is the place
where most of thefriction? lies.

Random-dev doesn't care about 'gentoo' so much as he cares that his
packages are working/(up to date) and 'gentoo' more or less works ok
given his knowledge of it's internals.

Or am I way off here?

There are many devs that have all kinds of opinions about a distro and
how it is set up; but I think there are very few people who have
thoughts about how to create and maintain a meta-distro.

PS: If there is a better list for this please point me there.

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



Re: [gentoo-dev] Why don't you just ...

2007-04-10 Thread Matthias Langer
On Wed, 2007-04-11 at 13:26 +1200, Christopher Sawtell wrote:
> On Wednesday 11 April 2007 10:56:40 Benedikt Boehm wrote:
> > ... don't care about an uber-vision or direction and just keep your
> > friggin packages alive and working?
> Indeed!!
> 
> Doing an   emerge --deep --update world   last week b0rked updating about a 
> couple of dozen packages. Evenutally I realized that the problem was 
> gcc-4.1.2 had a supposedly executable file filled with zeros in its 
> file-set. Masking gcc-4.1.2 and reverting to the 4.1.1 series has nearly 
> got me going again.There is still one package which won't compile.
> OK I'm running ~x86 so I suppose I shouldn't complain, but 
> This whole exercise, combined with the flame fests in here, has left me, a 
> Gentoo user for many years, since version 1.2, feeling very upset and 
> distinctly fiesty. Until the QA is a bit better I honestly feel I can't 
> wholeheartedly recommend Gentoo anymore.
> 

Well, I don't know what your problem really is about; I'm running x86,
and if something breaks on my system, it's mostly not because of broken
packages, but because I should have been informed about possible issues
that could have been caused by an upgrade, and how to avoid them. Often,
ebuilds contain very important information that are brought to the user
via elog, ewarn and friends. The problem with this approach is, that I
won't read these messages if I'm doing a world update while I'm asleep.
This is, why I think, that it should be one of Gentoos highest
priorities to implement Glep 42 and make heavy use of it.

Matthias



-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Why don't you just ...

2007-04-10 Thread Andy Dalton

On 4/10/07, Christopher Sawtell <[EMAIL PROTECTED]> wrote:

Evenutally I realized that the problem was
gcc-4.1.2 had a supposedly executable file filled with zeros in its
file-set. Masking gcc-4.1.2 and reverting to the 4.1.1 series has nearly
got me going again.There is still one package which won't compile.
OK I'm running ~x86 so I suppose I shouldn't complain, ...


You're right, you shouldn't complain.
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Why don't you just ...

2007-04-10 Thread Christopher Sawtell
On Wednesday 11 April 2007 10:56:40 Benedikt Boehm wrote:
> ... don't care about an uber-vision or direction and just keep your
> friggin packages alive and working?
Indeed!!

Doing an   emerge --deep --update world   last week b0rked updating about a 
couple of dozen packages. Evenutally I realized that the problem was 
gcc-4.1.2 had a supposedly executable file filled with zeros in its 
file-set. Masking gcc-4.1.2 and reverting to the 4.1.1 series has nearly 
got me going again.There is still one package which won't compile.
OK I'm running ~x86 so I suppose I shouldn't complain, but 
This whole exercise, combined with the flame fests in here, has left me, a 
Gentoo user for many years, since version 1.2, feeling very upset and 
distinctly fiesty. Until the QA is a bit better I honestly feel I can't 
wholeheartedly recommend Gentoo anymore.

> I'm so sick to hear people crying that noone is around to tell them what
> to do.. 

Well I'm sick of seeing people wasting their precious time playing politics, 
misunderstanding eachother and flaming as a consequence.

> So here is my proposal:
>
> ABSTAIN!
>
> That's it for now :)
Absolutely

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



Re: [gentoo-dev] [RFC] New metastructure proposal

2007-04-10 Thread Charlie Shepherd

On 10/04/07, Alexandre Buisse <[EMAIL PROTECTED]> wrote:

Hi everyone,

as everyone probably noticed, there is a current atmosphere of sinking ship,
with quite a lot of people leaving and many agreeing that gentoo is no fun
working on anymore. Before it's too late, I'd like to propose a big reformation
that would help solve some of the issues we are currently having and,
hopefully, bring back some of the fun we all had developing and using this
distribution.


I can't see any great advantage of this new structure, and indeed I
think it will lead to more chaos and anarchy than there is already.


The basic idea is to make gentoo a lot more meta than it already is. Something
that is said quite often is that gentoo lacks a direction. Some people want it
to be a business-oriented distribution,


I think the idea with this was of "freezing" the tree, and then only
adding bugfixes to the frozen tree to provide enterprise level QA.


some want it to be bleeding-edge


I think you'd struggle to get Gentoo to stop being on the bleeding edge :)


, some
a multimedia, development platform, you name it.


Don't these relate more to the packages we provide than our structure?


Obviously, arbitrarily
choosing one of those directions would mean losing a lot of developers, and
this is something we can't afford to do.


We could of course move in several directions at once...


The solution, of course, is to go
meta: provide a set of tools that allow people to build the distribution of
their dreams.


Don't we already provide most of these tools?


This is something that we are already trying to do, but my opinion is that we
are not going far enough.


How does this proposal help to bring us forward in this respect?


This structure has many advantages, one of those being that since projects are
autonomous, they handle their own recruitment,


Will this decrease QA?


which helps the dev/user
distinction fade away.


I'm not convinced of this distinction. While many people cite the
interactions on the forums, mailing lists or bugzilla as evidence of
it, if you look at IRC I think you see a quite different picture. I
know several users who I get on well with, and who participate


It concentrates development in small areas where people
will know each other well and be able to interact efficiently.  By
decentralizing, we remove the need for a big authority and give everyone the
freedom they want.


Just because people want freedom doesn't mean they won't abuse it.


The current devrel authority is reduced to only the core
project


I don't think this is a good idea. Most projects are short on people
already, without having to have their members wasting time policing
themselves.


By having everything as modular as possible, we also allow an easy fork of a
single project, for whatever reason. So if enough people think that mozilla is
being badly maintained by the current project and that people in it don't want
or can't apply their fixes, they can easily provide their own overlay with
better ebuilds.


People can already do this anyway, they just need to put up a tarball
and pop into #gentoo-overlays and ask it be added to the overlay list
for layman.


And if their version is indeed better, over time it will get
the official status and have superseeded smoothly the first project. Think of
paludis and pkgcore vs portage.


This is hardly a good example. Pkgcore and paludis both have totally
different codebases to portage, heck, paludis is written in a
different language. What you talk about above is different _ebuilds_,
and I have yet to see a serious dispute over ebuilds that has not been
settled in tree. The only existing ones I can think of are new
unstable or live ebuilds for packages that the maintainer will not
accept.


So far, I've come up with two main disadvantages to this reformation. The first
is that dependencies between different projects could become a problem if not
handled carefully.


I think this is the least of your worries.


For one thing, they would require a change to ebuild
syntax, along the lines of DEPEND="dev.perl.libs:libfoo", and of course
support from package managers. Pulling single ebuilds when required instead of
a full overlay would be a nice thing to have as well.


The extended atom syntax allows a repo-id to be included in the atom,
in the form category/package::repo (versions, slots etc can be
included too). You could have kde-base/kde::kde for the kde package
from the kde repo for example. This would at least make this proposal
slightly less chaotic were it actually to take place.


Another idea to simplify
this would be to have a central DB with every known ebuild in it
(including
non-official, bad QA ones)


Who would put in this information? Wouldn't it be easier to fix the QA
problems rather than listing them? Unless the ebuilds are in a
different overlay, oh wait they are(!). This is a problem with the
whole "lets split the tree up into overlays" idea. People act as
though devs b

Re: [gentoo-dev] [RFC] New metastructure proposal

2007-04-10 Thread Marius Mauch
On Tue, 10 Apr 2007 21:32:49 +0200
Alexandre Buisse <[EMAIL PROTECTED]> wrote:

[snip]
> Please criticize this with everything constructive you > can think of.

This idea of putting almost everything into its own repo/overlay will IMO end 
up in the same mess that several other distros have with tons of 3rd party 
repos that don't play nice with each other. In case you don't know, the "one 
stop" philosophy with one central repo is what attracts a lot of people to 
Gentoo.
And no, inter-repo deps won't solve that problem.

Also you said you're trying to solve the "lack of goals" problem (which I don't 
think is a real problem in the first place) which wouldn't really solved by 
this proposal either, not without duplicating a lot of work at least.

I like the part about projects being self-organizing, but splitting up the tree 
is a no go from my POV.

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



[gentoo-dev] Why don't you just ...

2007-04-10 Thread Benedikt Boehm
... don't care about an uber-vision or direction and just keep your
friggin packages alive and working?

I'm so sick to hear people crying that noone is around to tell them what
to do..

So here is my proposal:

ABSTAIN!

That's it for now :)
-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Re: base packages up for grabs

2007-04-10 Thread Steve Long
Raúl Porcel wrote:
> Peter Weller wrote:
>> On Sun, 08 Apr 2007 20:19:23 -0600
>> Ryan Hill <[EMAIL PROTECTED]> wrote:
>> 
>>> Mike Frysinger wrote:
 working here is no longer fun
>>> * HUGZ *
>> 
>> Hoi! Giving hugs is a right reserved by me and me only! :P
>> 
>> /me hugs Mike
> 
> /me stabs welp

Miaow! There's plenty of room in Minnesota y'know.. ;)


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: extending project xml to have stuff that the project is working on and collect them as Gentoo current goals

2007-04-10 Thread Stephen Bennett
On Tue, 10 Apr 2007 23:34:25 +0300
Petteri Räty <[EMAIL PROTECTED]> wrote:

> As the recent thread showed there is a lot going on in Gentoo land
> although it doesn't always seem so. I propose we extend project xml to
> describe current stuff going on in the project in question and their
> estimated completion date. Then we require this file to be updated
> monthly. What do you think?

I'm going to echo Mike here -- the additions are good, the forced
update schedule not so good. However, there's something in the subject
line not in the body which I also like:

> and collect them as Gentoo current goals

I wouldn't have chosen those words, but a list somewhere of all the new,
shiny and/or important stuff people are working on could be nice if it
can be done well. The GWN's future zone was a step in this direction
but seems to have died off lately and never really (IMO) got enough
material to realise the potential. Of course, this relies upon people
in Gentoo actually doing new, shiny and/or important things first,
before telling people about them.
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: extending project xml to have stuff that the project is working on and collect them as Gentoo current goals

2007-04-10 Thread Marius Mauch
On Tue, 10 Apr 2007 23:34:25 +0300
Petteri Räty <[EMAIL PROTECTED]> wrote:

> As the recent thread showed there is a lot going on in Gentoo land
> although it doesn't always seem so. I propose we extend project xml to
> describe current stuff going on in the project in question and their
> estimated completion date. Then we require this file to be updated
> monthly. What do you think?

Assuming we'd go with this, what would happen if a project doesn't update it's 
file?
Realistic answer: nothing. So any such requirement is just a recommendation 
anyway.
Besides there already is the  tag that can be used for that (though the 
layout is extremely crappy).
Counter proposal: Extend planet.g.o with project feeds, e.g. 
planet.g.o/projects/foo collecting news from all members of project foo 
(identified by category or so). That's where most people are posting/looking 
for news anyway these days.

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



Re: [gentoo-dev] Re: doenvd vs. insinto /etc/env.d

2007-04-10 Thread Petteri Räty
Steve Long kirjoitti:
> Doug Goldstein wrote:
>>> Stupid question... what's the diff between doconfd and newconfd?
>> Ha.. I remember now... Thanks robbat2 for kicking me in the head to jog
>> my memory...
>>
> Care to share? ;)
> 

man 5 ebuild. Use #gentoo-dev-help next time.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: doenvd vs. insinto /etc/env.d

2007-04-10 Thread Steve Long
Doug Goldstein wrote:
>> Stupid question... what's the diff between doconfd and newconfd?
> 
> Ha.. I remember now... Thanks robbat2 for kicking me in the head to jog
> my memory...
> 
Care to share? ;)

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: [gentoo-core] [RFC] New metastructure proposal

2007-04-10 Thread Rémi Cardona

Alexandre Buisse a écrit :
[snip]

My experience is limited to the gnome packages and just based on those, 
your proposal is already not doable.


Gnome deps on :
- core glib/gtk packages, used by many other packages, including 
"server" packages, but "owned" by the gnome herd

- dbus/hal, handled by gentopia
- fd.o packages, some handled by us, some by the x11 herd, some by 
individual devs

- mozilla, ...

I could go on for a while ...

While some change in Gentoo could bring some fresh air, your proposal 
would be impossible for us, and possibly worse for other teams/herds.


The current status quo for the gnome team is to work with all the other 
herds on an as-needed basis, with some devs being proxies for the rest 
of the team based on who gets along with whoever.


So far it seems to be working fine.

Hope my 0.02€ worth of explanations weren't too braindead :)

Rémi
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [RFC] New metastructure proposal

2007-04-10 Thread Petteri Räty
Chris Gianelloni kirjoitti:
> On Tue, 2007-04-10 at 22:50 +0200, [EMAIL PROTECTED] wrote:
>> it's just so easy to step on other
>> ppls feet these days ;)
> 
> I tend to agree that this is a problem, but only insofar as we've become
> too territorial.  Many times I see bugs filed with seemingly minor
> changes being asked for.  A good example is bug #173884 which is a
> completely valid request.  The change is simple, removing
> "insinto /etc/env.d ; doins $somefile" and replacing it with "doenvd
> $somefile" instead.  

Or it's plain boring to fix that stuff and if you make people fix their
own packages first, the boring part is distributed. I for example would
fix the ChangeLog syntax problem for all ChangeLogs in the tree but I
know that it's damn boring so I just prefer to get the check into
repoman and let time deal with it. If I ever get to writing an automatic
fixer, I still you need to check the changes or otherwise I could be
committing broken fixes because of false positives.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: extending project xml to have stuff that the project is working on and collect them as Gentoo current goals

2007-04-10 Thread Petteri Räty
Bryan Østergaard kirjoitti:
> On Tue, Apr 10, 2007 at 11:34:25PM +0300, Petteri R??ty wrote:
>> As the recent thread showed there is a lot going on in Gentoo land
>> although it doesn't always seem so. I propose we extend project xml to
>> describe current stuff going on in the project in question and their
>> estimated completion date. Then we require this file to be updated
>> monthly. What do you think?
>>
> I'd probably just cron my updates personally :)
> 
> Alpha and IA64 would both read "More keywording stuff done, yawn" every
> month. Python, apache and mozilla would read something like "fixed
> random bugs". Most other projects I'm involved in would be very much
> like that I think.
>

I think project leads could apply for exception from the council if they
are more like on going maintenance (arch teams come to mind). But
something like Java has had something big in works all the time I have
been involved. I don't really care about the implementation that much as
long as we have a page where all the current major things under work are
described.

Regards,
Petteri




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] New metastructure proposal

2007-04-10 Thread Chris Gianelloni
On Tue, 2007-04-10 at 22:50 +0200, [EMAIL PROTECTED] wrote:
> it's just so easy to step on other
> ppls feet these days ;)

I tend to agree that this is a problem, but only insofar as we've become
too territorial.  Many times I see bugs filed with seemingly minor
changes being asked for.  A good example is bug #173884 which is a
completely valid request.  The change is simple, removing
"insinto /etc/env.d ; doins $somefile" and replacing it with "doenvd
$somefile" instead.  Now, this is something that *anyone* with commit
access should feel comfortable doing to *anyone's* packages without fear
of being attacked for touching someone else's packages.  Unfortunately,
we're all a bit too territorial over what we keep in the tree sometimes.
If we had more explicit freedom to touch other people's packages for
minor things, we would go a lot further towards the goal of being a
community of mutually respectful people working towards a common goal.
Our rule of thumb here is pretty simple... "If you touch it, don't break
it.  If you break it, fix it."  Some people have become too frightened
to touch packages for even typo fixes due to the territoriality of some
of our developers.  We need to fix this and have a more open and
welcoming feeling for new developers and old developers alike.

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


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


Re: [gentoo-dev] RFC: extending project xml to have stuff that the project is working on and collect them as Gentoo current goals

2007-04-10 Thread Mike Frysinger
On Tuesday 10 April 2007, Petteri Räty wrote:
> I propose we extend project xml to describe current stuff going on in the
> project in question and their estimated completion date.

mmm good ...

> Then we require this file to be updated monthly.

... not so good
-mike


pgpz8Qu87JVkL.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] New metastructure proposal

2007-04-10 Thread Joshua Jackson
Petteri Räty wrote:
> Alexandre Buisse kirjoitti:
>   
>> What I *want* to do is to make gentoo fun again. And I believe that
>> decentralising and giving more autonomy to people will achieve exactly
>> that, for reasons explained in the proposal.
>>
>> 
>
> I am a project lead for two projects and have no idea what kind of more
> autonomy I would need for my two projects.
>
> Regards,
> Petteri
> --
> Gentoo/Java project lead
> Gentoo/Recruiters project lead
>
>   
I agree as a Project lead of another...I don't think more autonomy is
needed..Basically I'm allowed to do what Is best with the team (and that
amounts to mostly just patting people on the back. Good job x86 team
members btw <---see there's a pat on the back). So really, I think most
project leads are there to a, give a direction to the team, and once its
there twiddle our thumbs and go yay I got good people under me who work
hard. its management at its finest ;)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: extending project xml to have stuff that the project is working on and collect them as Gentoo current goals

2007-04-10 Thread Bryan Østergaard
On Tue, Apr 10, 2007 at 11:34:25PM +0300, Petteri R??ty wrote:
> As the recent thread showed there is a lot going on in Gentoo land
> although it doesn't always seem so. I propose we extend project xml to
> describe current stuff going on in the project in question and their
> estimated completion date. Then we require this file to be updated
> monthly. What do you think?
> 
I'd probably just cron my updates personally :)

Alpha and IA64 would both read "More keywording stuff done, yawn" every
month. Python, apache and mozilla would read something like "fixed
random bugs". Most other projects I'm involved in would be very much
like that I think.

The only projects that I'm a member of that it would be interesting to
hear from imo is devrel and council and they already give status updates
whenever something interesting or important happens.

Please note that I'm not against these status updates at all. I just
don't think forcing a pre-determined schedule makes much sense.

Regards,
Bryan Øtergaard
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [RFC] New metastructure proposal

2007-04-10 Thread Petteri Räty
Alexandre Buisse kirjoitti:
> 
> What I *want* to do is to make gentoo fun again. And I believe that
> decentralising and giving more autonomy to people will achieve exactly
> that, for reasons explained in the proposal.
> 

I am a project lead for two projects and have no idea what kind of more
autonomy I would need for my two projects.

Regards,
Petteri
--
Gentoo/Java project lead
Gentoo/Recruiters project lead



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: [gentoo-core] [RFC] New metastructure proposal

2007-04-10 Thread Alon Bar-Lev

On 4/10/07, Alexandre Buisse <[EMAIL PROTECTED]> wrote:

Hi everyone,

as everyone probably noticed, there is a current atmosphere of sinking ship,
with quite a lot of people leaving and many agreeing that gentoo is no fun
working on anymore. Before it's too late, I'd like to propose a big reformation
that would help solve some of the issues we are currently having and,
hopefully, bring back some of the fun we all had developing and using this
distribution.


Thank you for bringing this up. I think the discussion is very important.

It is first time I response to a "political" issue here... So forgive
me if I am totally wrong.

I don't think this is the reason people are leaving.
I think people are leaving because a lack of direction.
I am not aware of any goal Gentoo distribution wish to acquire. For
example: Do we wish to use a mainstream distribution? Do we aim to a
specific user community? Or Do we develop distribution for our use?

If you wish to be (And I think we should be) mainstream distribution,
we should derive targets, such as QA level, response times and
content.

Being more modular is one technical feature to achieve better
stability. But we should discuss the basics first.

I hear a lot that open source project with unpaid developers cannot be
committed to deadlines or requirements from its developers, but I
disagree. There can be an open source project with high quality
products and dead lines, if these properly defined.

I am quite new here, but it seems like there are few groups here, from
a group that interested in anarchy to a group that interested in
formal hierarchy.

I must disclose that in my view whenever a large group of people are
doing something together, some kind of hierarchy must be in place. And
I am not talking about current council, it seems that current council
does not LEAD Gentoo anywhere.

I read that sometime in history there was an effort to impose
structural format on the community, but then Daniel Robbins left?

If we wish to be a major distribution, we must grow. If we to grow we
must organize our-self better, and work toward a common goal. Common
goal forces decision making. Decision making forces leadership.
Leadership forces vision.

Is there any vision?

Now, for your idea.
When I written something similar in the past, someone told me that it
was already suggested... I don't know why it wasn't accepted.

I think too that ebuilds should exists in several overlays. At least:
Stage3 (current)
Base (baselayout, networking, boot loaders etc)
-tear-

Each tear should have commitments for:
1. Time from upstream release package until it in overlay.
2. Time from security issue until it in stable.
3. Time from stable request until make stable per each platform.
4. Time for addressing bug, time for solving bug.
5. Keep last N stable version (major, minor).
I guess you got the idea.

For example, for crypto there can be several overlays, tear-1 overlay
with core packages, tear-2 with misc packages, tear-3 with supported
at free-time bases.
Each tear has its own measures.

tear-1 desktop cannot be dependent on tear-2 crypto, the desktop herd
need to ask crypto herd to move the package into tear-1 before
dependency is added.

I totally agree that each user may ask for package of specific
overlay, but I think that this should not be specified in the build,
but by the user at /etc/portage.

For example, I decide that dev-libs/gtk+ should be from overlay X the
portage should take it from there.

But I believe we should first discuss the community goals, then derive
a technical solution.

Best Regards,
Alon Bar-Lev.
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: extending project xml to have stuff that the project is working on and collect them as Gentoo current goals

2007-04-10 Thread Petteri Räty
Chris Gianelloni kirjoitti:
> On Tue, 2007-04-10 at 23:34 +0300, Petteri Räty wrote:
>> Then we require this file to be updated
>> monthly. What do you think? 
> 
> I think Release Engineering would kill you in our off time.  This has
> been brought up before, but some projects just don't have enough going
> on to update on a regular cycle.
> 

So you just change the date? I don't think we should require anything
but acknowledgment that the old data still applies.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: extending project xml to have stuff that the project is working on and collect them as Gentoo current goals

2007-04-10 Thread Chris Gianelloni
On Tue, 2007-04-10 at 23:34 +0300, Petteri Räty wrote:
> Then we require this file to be updated
> monthly. What do you think? 

I think Release Engineering would kill you in our off time.  This has
been brought up before, but some projects just don't have enough going
on to update on a regular cycle.

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


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


Re: [gentoo-dev] [RFC] New metastructure proposal

2007-04-10 Thread Alexandre Buisse
On Tue, Apr 10, 2007 at 22:32:20 +0200, Chris Gianelloni wrote:

> On Tue, 2007-04-10 at 21:32 +0200, Alexandre Buisse wrote:
> > work. Stage 4's were going in this direction, but they were too isolated 
> > and, as
> > far as I know, they are dead now.
> 
> Wow.  I'm glad to see that yet another thing I spend so much time
> working on is marginalized or otherwise discounted because someone
> couldn't take 3 seconds to check their facts before making a post.  The
> stage4 concept is alive and kicking.  It is one of the targets made by
> catalyst, and likely something we will be utilizing much more in later
> releases.

Sorry about that, I should have taken the time to look it up. Since I
didn't hear about it after Stuart leaved, I assumed no one was working
on it anymore.

 
> If anyone has further questions about the stage4 target or how it's
> utilized in catalyst, feel free to drop onto the gentoo-catalyst mailing
> list and ask.
> 
> Now, just to stay on topic with this posting, I have some simple (yeah
> right) questions.
> 
> Will this actually resolve any of the recent problems?

Yes, as I tried to explain in the proposal.

 
> Will this stop flame wars?

Probably not, but it can help reduce the volume, hopefully. Indirectly,
of course, but I believe it would help a lot to reduce the tensions.

 
> Will this cause people be nicer to each other?

Definitely, yes. Because everyone will work on a smaller scale.

 
> Will this give us more qualified developers?

Will depend on how each team will do its recruitment. And of course, to
get official status, some kind of council would ensure some minimal
qualifications (along the current guidelines would be my guess).

 
> Will this increase the quality of the tree?

Hard to tell. Having people leave the project out of disgust certainly
doesn't improve it.

 
> Restructuring the project isn't going to solve these problems.  

Not all of them, of course. And I never pretended it would. But I
believe that it would definitely help.


> At best,
> it will mask them during the time that we've wasted restructuring only
> to find that we are back with the same set of problems, though now
> without any form of centralized management to have even the glimmer of
> hope of being able to resolve them.

I don't see how not having a centralized management would make it
impossible to solve problems. Or are people really that stupid that they
can't manage to get together and reach a decision, in some way or
another (I gave some ideas in the last part of the email as well). Just
giving all your power of decision to a big boss is a very crude and
unefficient way of solving problems.


> It will take us to a complete mess
> of incompatible overlays and trees.  

If we do it carelessly, certainly. But free software has solved much more
complex problems in the past.


> It also places the projects in a
> hierarchy that doesn't match the actual power structure.

Power structure? I'm afraid I don't understand what you mean here.

 
> If the parent project doesn't govern the sub-project, then why is it a
> sub-project, at all?

To ease coordination and make obvious relationships clearer, I guess.
Can also help overlay management with hints like "you've pulled the
audio overlay, you probably also want the multimedia one" and stuff like
that. But it isn't really important, and the name "subproject" is
probably misleading.

 
> What exactly are all of us supposed to actually *do* while we're waiting
> for the SCM conversion and for the package managers to get the support
> necessary and all of the changes are made to the tree?  

Keep working on the current version? I don't know, I would classify that
as an implementation detail to be sorted if we actually decide to go
forward.


> Do we simply
> stop developing the distribution for days?  Weeks?  Months?

I'm sure we can find a better solution than that. But do we want to
discuss such tiny details before the big plan itself?

 
> I think that the clique-like nature of many projects is part of the
> problem.  We already have too much of a "us versus them" mentality.

I'm not sure what you mean. Which projects are you speaking about? It
sounds like a silly accusation to me, but perhaps I'm unaware of some
other case.

 
> How will moving to having lots of independent projects with no central
> authority make Gentoo better?

I have said this in the proposal. If you don't agree on specific points,
please provide arguments to back up your position.

 
> Will it make the distribution better for our users?

Because gentoo won't be dead in a couple months? Because people will
think again that it's a fun project and want to be part of it?

 
> Reading back over your proposal with my questions in mind leaves me with
> exactly one last question.
> 
> What, exactly, is your proposal supposed to actually accomplish?

What I *want* to do is to make gentoo fun again. And I believe that
decentralising and giving more autonomy to people will achieve 

Re: [gentoo-dev] RFC: extending project xml to have stuff that the project is working on and collect them as Gentoo current goals

2007-04-10 Thread Carsten Lohrke
Thanks for the xml excerpt Pettery, but I'm still in the dark about what you 
speak at all.


Carsten


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


Re: [gentoo-dev] [RFC] New metastructure proposal

2007-04-10 Thread paul
Chris Gianelloni schrieb:
> On Tue, 2007-04-10 at 21:32 +0200, Alexandre Buisse wrote:
>> work. Stage 4's were going in this direction, but they were too isolated 
>> and, as
>> far as I know, they are dead now.
> 
> Wow.  I'm glad to see that yet another thing I spend so much time
> working on is marginalized or otherwise discounted because someone
> couldn't take 3 seconds to check their facts before making a post.  The
> stage4 concept is alive and kicking.  It is one of the targets made by
> catalyst, and likely something we will be utilizing much more in later
> releases.
Nice to hear ;)
As already noted, splitting the tree at arbitrary boundaries will not
work. However, I think I understand the motivation that drives the
proposal in the first place. My feeling is: things getting more complex
(ebuild wise, deps, more packages),  it's just so easy to step on other
ppls feet these days ;)

maybe its time to kill the life tree?

/me runs away ;)

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



Re: [gentoo-dev] RFC: extending project xml to have stuff that the project is working on and collect them as Gentoo current goals

2007-04-10 Thread Petteri Räty
Mike Doty kirjoitti:
> Petteri Räty wrote:
>> As the recent thread showed there is a lot going on in Gentoo land
>> although it doesn't always seem so. I propose we extend project xml to
>> describe current stuff going on in the project in question and their
>> estimated completion date. Then we require this file to be updated
>> monthly. What do you think?
>>
>> Regards,
>> Petteri
>> -- 
>> Gentoo/Java project lead
>> Gentoo/Recruiters project lead
>>
> what do you mean by "project xml"?






Java



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: extending project xml to have stuff that the project is working on and collect them as Gentoo current goals

2007-04-10 Thread Ned Ludd
On Tue, 2007-04-10 at 23:34 +0300, Petteri Räty wrote:
> As the recent thread showed there is a lot going on in Gentoo land
> although it doesn't always seem so. I propose we extend project xml to
> describe current stuff going on in the project in question and their
> estimated completion date.

>  Then we require this file to be updated
> monthly. What do you think?

I'd rather not put this stipulation into place. 

Unless you are proposing that planet.gentoo.org die. Which I don't think
you are doing..

-- 
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: extending project xml to have stuff that the project is working on and collect them as Gentoo current goals

2007-04-10 Thread Mike Doty

Petteri Räty wrote:

As the recent thread showed there is a lot going on in Gentoo land
although it doesn't always seem so. I propose we extend project xml to
describe current stuff going on in the project in question and their
estimated completion date. Then we require this file to be updated
monthly. What do you think?

Regards,
Petteri
--
Gentoo/Java project lead
Gentoo/Recruiters project lead


what do you mean by "project xml"?
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] RFC: extending project xml to have stuff that the project is working on and collect them as Gentoo current goals

2007-04-10 Thread Petteri Räty
As the recent thread showed there is a lot going on in Gentoo land
although it doesn't always seem so. I propose we extend project xml to
describe current stuff going on in the project in question and their
estimated completion date. Then we require this file to be updated
monthly. What do you think?

Regards,
Petteri
--
Gentoo/Java project lead
Gentoo/Recruiters project lead



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] New metastructure proposal

2007-04-10 Thread Chris Gianelloni
On Tue, 2007-04-10 at 21:32 +0200, Alexandre Buisse wrote:
> work. Stage 4's were going in this direction, but they were too isolated and, 
> as
> far as I know, they are dead now.

Wow.  I'm glad to see that yet another thing I spend so much time
working on is marginalized or otherwise discounted because someone
couldn't take 3 seconds to check their facts before making a post.  The
stage4 concept is alive and kicking.  It is one of the targets made by
catalyst, and likely something we will be utilizing much more in later
releases.

If anyone has further questions about the stage4 target or how it's
utilized in catalyst, feel free to drop onto the gentoo-catalyst mailing
list and ask.

Now, just to stay on topic with this posting, I have some simple (yeah
right) questions.

Will this actually resolve any of the recent problems?

Will this stop flame wars?

Will this cause people be nicer to each other?

Will this give us more qualified developers?

Will this increase the quality of the tree?

Restructuring the project isn't going to solve these problems.  At best,
it will mask them during the time that we've wasted restructuring only
to find that we are back with the same set of problems, though now
without any form of centralized management to have even the glimmer of
hope of being able to resolve them.  It will take us to a complete mess
of incompatible overlays and trees.  It also places the projects in a
hierarchy that doesn't match the actual power structure.

If the parent project doesn't govern the sub-project, then why is it a
sub-project, at all?

What exactly are all of us supposed to actually *do* while we're waiting
for the SCM conversion and for the package managers to get the support
necessary and all of the changes are made to the tree?  Do we simply
stop developing the distribution for days?  Weeks?  Months?

I think that the clique-like nature of many projects is part of the
problem.  We already have too much of a "us versus them" mentality.

How will moving to having lots of independent projects with no central
authority make Gentoo better?

Will it make the distribution better for our users?

Reading back over your proposal with my questions in mind leaves me with
exactly one last question.

What, exactly, is your proposal supposed to actually accomplish?

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


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


Re: [gentoo-dev] [RFC] New metastructure proposal

2007-04-10 Thread Petteri Räty
Alexandre Buisse kirjoitti:
> Hi everyone,
> 
> as everyone probably noticed, there is a current atmosphere of sinking ship,
> with quite a lot of people leaving and many agreeing that gentoo is no fun
> working on anymore. Before it's too late, I'd like to propose a big 
> reformation
> that would help solve some of the issues we are currently having and,
> hopefully, bring back some of the fun we all had developing and using this
> distribution.
>

I can say that inside all the teams I work with things are just fine and
fun as ever. :)
IMHO it's just this mailing list that is perceived rotten in some
people's eyes. Only time time will if the ongoing changes will help.

> 
> The idea is pretty simple: modularization. There is a core part, with a couple
> hundred packages that are absolutely necessary to a system. Then we have a
> hierarchy of overlays with additional ebuilds for people's need. Top-level
> projects could look like: desktop, dev, business, embedded, misc. Then we
> would have subprojects, e.g. multimedia, DE, games for desktop, multimedia
> being itself subdivided in audio and video, and so on. This would get us a
> tree of arbitrary depth, with development happening mostly in leaves. The
> hierarchy would mostly serve as a classification tool, and projects would not
> necessarily share resources, including devs, with their subprojects, neither
> should they have decision power over them.
>

Splitting the tree is a nice idea but first we would need to solve the
problems that have come up in previous threads about this some of which
you outline later.

> 
> By having everything as modular as possible, we also allow an easy fork of a
> single project, for whatever reason. So if enough people think that mozilla is
> being badly maintained by the current project and that people in it don't want
> or can't apply their fixes, they can easily provide their own overlay with
> better ebuilds.  And if their version is indeed better, over time it will get
> the official status and have superseeded smoothly the first project. Think of
> paludis and pkgcore vs portage.
>

Hmm. Should I emerge mozilla-firefox from module A or module B. Both
have web sites claiming theirs is better. Flame on. Maybe we should just
focus on QA being able to kick out people who do a lousy job.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [RFC] New metastructure proposal

2007-04-10 Thread Alexandre Buisse
Hi everyone,

as everyone probably noticed, there is a current atmosphere of sinking ship,
with quite a lot of people leaving and many agreeing that gentoo is no fun
working on anymore. Before it's too late, I'd like to propose a big reformation
that would help solve some of the issues we are currently having and,
hopefully, bring back some of the fun we all had developing and using this
distribution.


The basic idea is to make gentoo a lot more meta than it already is. Something
that is said quite often is that gentoo lacks a direction. Some people want it
to be a business-oriented distribution, some want it to be bleeding-edge, some
a multimedia, development platform, you name it. Obviously, arbitrarily
choosing one of those directions would mean losing a lot of developers, and
this is something we can't afford to do. The solution, of course, is to go
meta: provide a set of tools that allow people to build the distribution of
their dreams.
This is something that we are already trying to do, but my opinion is that we
are not going far enough. For one thing, we target users as the one who should
build and customize their distribution, while it would be pretty interesting
to also target ourselves as the ones who should be doing this "instantiation"
work. Stage 4's were going in this direction, but they were too isolated and, as
far as I know, they are dead now.



The idea is pretty simple: modularization. There is a core part, with a couple
hundred packages that are absolutely necessary to a system. Then we have a
hierarchy of overlays with additional ebuilds for people's need. Top-level
projects could look like: desktop, dev, business, embedded, misc. Then we
would have subprojects, e.g. multimedia, DE, games for desktop, multimedia
being itself subdivided in audio and video, and so on. This would get us a
tree of arbitrary depth, with development happening mostly in leaves. The
hierarchy would mostly serve as a classification tool, and projects would not
necessarily share resources, including devs, with their subprojects, neither
should they have decision power over them.

This structure has many advantages, one of those being that since projects are
autonomous, they handle their own recruitment, which helps the dev/user
distinction fade away. It concentrates development in small areas where people
will know each other well and be able to interact efficiently.  By
decentralizing, we remove the need for a big authority and give everyone the
freedom they want. The current devrel authority is reduced to only the core
project, though people could still ask its wisdom whenever conflicts pop up.
Basically, the only job involving red tape and a central authority is deciding
who gets the nice "gentoo official project" stamp, and the resources infra can
then provide. Of course, QA would be the main, if not only, criterion in this
choice.

By having everything as modular as possible, we also allow an easy fork of a
single project, for whatever reason. So if enough people think that mozilla is
being badly maintained by the current project and that people in it don't want
or can't apply their fixes, they can easily provide their own overlay with
better ebuilds.  And if their version is indeed better, over time it will get
the official status and have superseeded smoothly the first project. Think of
paludis and pkgcore vs portage.



So far, I've come up with two main disadvantages to this reformation. The first
is that dependencies between different projects could become a problem if not
handled carefully. For one thing, they would require a change to ebuild
syntax, along the lines of DEPEND="dev.perl.libs:libfoo", and of course
support from package managers. Pulling single ebuilds when required instead of
a full overlay would be a nice thing to have as well. Another idea to simplify
this would be to have a central DB with every known ebuild in it (including
non-official, bad QA ones) and the names of repositories/projects providing
it. This would give enough information to package managers for them to make
intelligent choices about how they should behave.

The other big problem is that a migration to this structure would require a
lot of effort from everyone. The good news is that we could use the
opportunity to migrate to a nicer scm (and given what gentoo would look like,
a distributed one like mercurial or git would be a natural choice) and also
that we would get a good idea of what is maintained and what isn't. Leaving
out stuff that no-one wants would then be very easy. Also, I believe that by
having a clear goal, everyone should get a huge motivation boost and I believe
that things could go quite smoothly, and even quickly.



Of course, many details have been left out that should be discussed and solved
before any decision is taken. Among those is the status of arch teams, which
is a bit unclear. An idea would be to have the main three or four most-used
arches (x86, amd64, ppc would be my guess) in KEYWORDS

[gentoo-dev] Re: genlop-0.30.6 released

2007-04-10 Thread Markus Ullmann
Mike Frysinger schrieb:
> doubt it'll be possible to convince the developers to merge here ... genlop 
> is 
> written in perl and qlop is written in C ...
> -mike

Maybe we can do this as another 99bottle ;)

For those who don't know what it is about, look it up here ...
http://99-bottles-of-beer.net/

-Jokey

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] genlop-0.30.6 released

2007-04-10 Thread Doug Goldstein
Michael Cummings wrote:
> On Mon, Apr 09, 2007 at 10:43:58AM -0400, Michael Cummings wrote:
>   
>> -t fixed (not in svn yet, but it was an easy thing to fix)
>>
>> trying to compile something that should take more than an hour on my box to 
>> make
>> sure -c is fixed also. Sorry about the shoddy release,
>>
>> 
> can anyone tell i'm having a slow day at the office, or at least being
> successful in maintaining a low profile today?
>
> Fixed up, 0.30.7 is on its way to the mirrors. 
>
>
>   
When do the public floggings begin for 0.30.6 bugs? 5 lashes per bug!
-- 
gentoo-dev@gentoo.org mailing list



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

2007-04-10 Thread Paul de Vrieze

Seemant Kulleen wrote:

On Thu, 2007-04-05 at 13:29 +0200, Denis Dupeyron wrote:

Why not simply allow trustees to veto a council decision ? This does
not give trustees enough power to be a second council, but would
permit them to stop something that they believe will damage Gentoo.
This is very little red tape IMHO.


I believe that the trustees do not necessarily have any jurisdiction
over the council.  They are concerned with legal type matters that
affect the foundation, not with technical and political things within
Gentoo itself.  I could be wrong about this, but that's how I read it.


Actually much of the hardware that supports gentoo is owned by or lend 
to the foundation. The trustees have legal control over that (while 
infrastructure has technical control), so if it comes to a pissing 
context, the foundation would probably win. It is not a situation anyone 
would want to get into. There is no other formal relationship between 
the foundation and the council.


Paul
(Gentoo dev/trustee)
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] genlop-0.30.6 released

2007-04-10 Thread Mike Frysinger
On Tuesday 10 April 2007, Andrej Kacian wrote:
> Timothy Redaelli <[EMAIL PROTECTED]> wrote:
> > Imho is a waste of time to maintain two projects which does the same
> > things (genloop and qlop)
>
> Perhaps because each has features that the other doesn't (genlop's --date,
> for example).

because i havent gotten around to implementing them in qlop ;)

i focused on the options from genlop that i actually utilized ...
-mike


pgp5uO3RYK5eJ.pgp
Description: PGP signature


Re: [gentoo-dev] genlop-0.30.6 released

2007-04-10 Thread Andrej Kacian
On Tue, 10 Apr 2007 14:28:52 +0200
Timothy Redaelli <[EMAIL PROTECTED]> wrote:

> Imho is a waste of time to maintain two projects which does the same
> things (genloop and qlop)

Perhaps because each has features that the other doesn't (genlop's --date, for
example).

Also, as long as involved people don't consider it a waste of time, it's not a
waste of time - it's their time, after all.

Regards,
-- 
Andrej "Ticho" Kacian 
Gentoo Linux Developer - net-mail, antivirus, sound, x86


signature.asc
Description: PGP signature


Re: [gentoo-dev] genlop-0.30.6 released

2007-04-10 Thread Michael Cummings
On Tue, Apr 10, 2007 at 02:28:52PM +0200, Timothy Redaelli wrote:
> Imho is a waste of time to maintain two projects which does the same
> things (genloop and qlop)

gollee, we wouldn't want competing products, would we? I mean, imagine if
someone tried writing a competitor for emerge??

:P 

This email was intended as light hearted - neither camel's nor bovine were
harmed in the process. That and it pains me to make that point about
competition.

~mcummings


-- 

-o()o--
Michael Cummings   |#gentoo-dev, #gentoo-perl
Gentoo Perl Dev|on irc.freenode.net 
Gentoo/SPARC
Gentoo/AMD64
GPG: 0543 6FA3 5F82 3A76 3BF7  8323 AB5C ED4E 9E7F 4E2E
-o()o--

Hi, I'm a .signature virus! Please copy me in your ~/.signature.


pgpJRTJbt2Pdu.pgp
Description: PGP signature


Re: [gentoo-dev] genlop-0.30.6 released

2007-04-10 Thread Mike Frysinger
On Tuesday 10 April 2007, Timothy Redaelli wrote:
> Imho is a waste of time to maintain two projects which does the same
> things (genloop and qlop)

doubt it'll be possible to convince the developers to merge here ... genlop is 
written in perl and qlop is written in C ...
-mike


pgpb0w0E2LgeK.pgp
Description: PGP signature


Re: [gentoo-dev] genlop-0.30.6 released

2007-04-10 Thread Timothy Redaelli
Michael Cummings ha scritto:
> Been a while, upstream moved on in life but we continued to get interested 
> users
> filing bugs, so
> 
> genlop-0.30.6 went into the tree this morning. Primarily a bug fix release 
> based
> on what was open in bugs.gentoo.org. Enjoy :)

Imho is a waste of time to maintain two projects which does the same
things (genloop and qlop)

-- 
Timothy `Drizzt` Redaelli - http://dev.gentoo.org/~drizzt/
FreeSBIE Developer, Gentoo Developer, GUFI Staff
There are two major products that come out of Berkeley: LSD and UNIX.
We don't believe this to be a coincidence.  -- Jeremy S. Anderson



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: base packages up for grabs

2007-04-10 Thread Raúl Porcel
Peter Weller wrote:
> On Sun, 08 Apr 2007 20:19:23 -0600
> Ryan Hill <[EMAIL PROTECTED]> wrote:
> 
>> Mike Frysinger wrote:
>>> working here is no longer fun
>> * HUGZ *
>>
>>
>>
> 
> Hoi! Giving hugs is a right reserved by me and me only! :P
> 
> /me hugs Mike

/me stabs welp
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] base packages up for grabs

2007-04-10 Thread Matthias Schwarzott
On Sonntag, 8. April 2007, Mike Frysinger wrote:

> sys-power/nvram-wakeup
VDR-Team can look at it.

Matthias

-- 
Matthias Schwarzott (zzam)
-- 
gentoo-dev@gentoo.org mailing list