Re: [gentoo-dev] *DEVELOPMENT* mail list, right?
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
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 ...
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 ...
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 ...
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 ...
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 ...
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
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
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 ...
... 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
