Re: [gentoo-dev] Re: Baselayout-2 progress?
On Saturday 01 March 2008 02:08:44 Duncan wrote: Is direct upgrade from previous baselayout-2.0.0-rcX going to be supported? Existing configs should work just fine - with the exception of the modules config. It's been moved to /etc/conf.d/modules instead of the /etc/modules.autoload.d folder. There is no automated migration as complex setups would go wrong. I was running that for some time and just now added and upgraded to the via layman version. There's a blocker, of course, as openrc is now providing most of the files that baselayout did. The problem is that unmerging the old 2.0.0-rcX baselayout in ordered to resolve the blockage is SCARY, since it leaves the system basically unbootable until the new setup is merged and at least basically configured. There's also the issue of not knowing for sure just what's going to still be around in terms of config files and the like, since unmerging baselayout isn't exactly an everyday thing. FWIW, I took the jump anyway, and the etc-update seemed to go reasonably well, but I've not rebooted yet... As others pointed out, this is a package manager issue and those blockers are there because of this. Not an OpenRC issue as such ;) Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for March
I want to propose to the council to talk about the amd64 arch team and its big bug list [1] considering they are the most staffed arch team. They have some bugs that are more than a month old and they are the last arch. Same for security bugs, and i think amd64 is an important arch and has a lot of users, and ATs. x86 doesn't have any AT active and we only have less than 10 bugs, amd64 has 144 bugs, and i'm talking about bugs with STABLEREQ keywords, just look at [1]. So it would be cool if they accepted help from other devs who don't have an amd64 system but have access to one and can test stuff. Cla is willing to help. There's even a bug that is a blocker... [1]: http://tinyurl.com/3dms4y -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for March
Raúl Porcel wrote: So it would be cool if they accepted help from other devs who don't have an amd64 system but have access to one and can test stuff. Cla is willing to help. I think this may be more a question of what our policy should be regarding level of testing/stability accepted. I'm sure manpower is a factor as well (number of devs isn't necessarily directly proportional to number of hours spent by those devs per week on gentoo). I don't keyword a package stable unless I've done at least a moderate amount of testing on the package to ensure that it works. If a package looks simple but obscure I might go ahead and install it and play with it, but I'd probably never keyword an emacs package stable, since I don't ever use emacs and I won't pretend that all there is to it is installing it and typing hello world and figuring out how to quit. Also, the more critical a package is the less likely I am to keyword it without care - I'm not going to keyword apache stable unless I've installed it and put several of my php/cgi-perl apps through a fair number of chores since I know that people who run apache generally care that it works. If there are folks out there who can test on amd64 systems then I'm sure that the amd64 team would look forward to their help (just contact kingtaco about it) - either by arch testing or perhaps by just keywording as appropriate. However, we do need to be careful about just going on a hunt to close bugs - if it builds then it's stable isn't really a policy I think we want to follow. As an amd64 user as well as a dev I know that I'd rather be a little further behind on package foo (with the ability to accept ~amd64 on it if I wanted to) than to have packages breaking every other week because somebody keyworded them just because it compiled and didn't have any glaring faults. I think we also need better coordination across gentoo regarding when packages should be stabilized. I've seen amd64 CC'ed on stablereq bugs filed by end users, and arch teams keywording them left and right, and there is no sign that the package maintainer wants the package stabilized. I know that I'd be annoyed if arch teams stabilized a package that I maintained and I didn't intend for it to become stable for whatever reason. At the very least maintainers should be contacted before packages go stable - and they should probably document their intent in STABLEREQ bugs before everybody goes crazy closing them out. I think that if we have the right policies then we'll be where we want to be. Personally, it doesn't concern me a great deal that there are tons of bugs open on an arch in and of itself (although blockers and security bugs are a different matter). I'd rather that then keyword something stable anytime one person (usually not the maintainer) asks us to. And users who feel like they're being held up should feel free to ping a dev to talk about it - and comments by users and maintainers in bugs indicating how stable a package really is make people like me more warm and fuzzy about keywording it without as much personal testing. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Monthly Gentoo Council Reminder for March
Hi, Richard Freeman [EMAIL PROTECTED]: Raúl Porcel wrote: So it would be cool if they accepted help from other devs who don't have an amd64 system but have access to one and can test stuff. Cla is willing to help. [...] I don't keyword a package stable unless I've done at least a moderate amount of testing on the package to ensure that it works. If a package looks simple but obscure I might go ahead and install it and play with it, but I'd probably never keyword an emacs package stable, since I don't ever use emacs and I won't pretend that all there is to it is installing it and typing hello world and figuring out how to quit. Hah, got you. Emacs team has a collection of test plans, that are understandable and have a step-by-step guide to the package. You may not have noticed because at the moment, Emacs teams handles nearly all stabilisation requests itself on amd64. Yes, testing is crucial, but it eases your pain if you have an arch tester going over it beforehand and amd64 is well equipped with that. If there are folks out there who can test on amd64 systems then I'm sure that the amd64 team would look forward to their help (just contact kingtaco about it) - either by arch testing or perhaps by just keywording as appropriate. However, we do need to be careful about just going on a hunt to close bugs - if it builds then it's stable isn't really a policy I think we want to follow. As an amd64 user as well as a dev I know that I'd rather be a little further behind on package foo (with the ability to accept ~amd64 on it if I wanted to) than to have packages breaking every other week because somebody keyworded them just because it compiled and didn't have any glaring faults. There are dozens of bugs out there for amd64, that are no stabilisation requests but contain a patch or simple requests that could be handled in a fast wayproblem is, nobody does. Don't get Raul or myself wrong, we are not here to accuse someone or do a mud fight. We care and are worried about the state of amd64, but do not want to lower the work invested by some members of the team, so don't take anything personal or try to justify by all means. As a matter of fact amd64 has some broken packages in the stable tree where bugs exist and noone seems to care. I think we also need better coordination across gentoo regarding when packages should be stabilized. I've seen amd64 CC'ed on stablereq bugs filed by end users, and arch teams keywording them left and right, and there is no sign that the package maintainer wants the package stabilized. I know that I'd be annoyed if arch teams stabilized a package that I maintained and I didn't intend for it to become stable for whatever reason. At the very least maintainers should be contacted before packages go stable - and they should probably document their intent in STABLEREQ bugs before everybody goes crazy closing them out. This happens seldomly...and normally stabilisations are assigned to the maintainer which should react and cc arches. Only maintainer-wanted is directly cced with arches by bug wranglers. So such problems occur if developers/trusted users create the stabilisation bug. I think that if we have the right policies then we'll be where we want to be. Personally, it doesn't concern me a great deal that there are tons of bugs open on an arch in and of itself (although blockers and security bugs are a different matter). I'd rather that then keyword something stable anytime one person (usually not the maintainer) asks us to. And users who feel like they're being held up should feel free to ping a dev to talk about it - and comments by users and maintainers in bugs indicating how stable a package really is make people like me more warm and fuzzy about keywording it without as much personal testing. Again, this is not a question of not testing but a question of getting more work done (by more people). Sometimes I do amd64 bugs although I am not on the team, my only test system is a remote machine with hardened kernel (miranda), but I do test the packages I mark stable. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March
Christian Faulhammer wrote: [snip] I agree 100%, thanks for explaining it better than me :P -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for March
On Saturday 01 March 2008 10:55:06 Raúl Porcel wrote: So it would be cool if they accepted help from other devs who don't have an amd64 system but have access to one and can test stuff. Cla is willing to help. Oh, I'd be more than happy to accept help from developers like that. It's just a case of what the big bosses think of it. Plus there's the fact that some other arches operate on a it compiles, mark it stable policy, and we don't want developers to bring that attitude to the amd64 team. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for March
On Saturday 01 March 2008 10:55:06 Raúl Porcel wrote: [..snip..] There are also a number of problems with people on the team who are there soley so that they don't have to ask the team to mark a package stable for them - they can just go and stable it themselves. OK, this may help the amd64 team in a minor way, but it would be much more preferable if they actually did any work *outside* of this. Now, some of you may have noticed a certain level of inactivity from me lately, but rest assured that now that I have my new Core 2 Duo laptop more or less up and running, I'll be able to do more amd64 stuff. welp -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for March
Peter Weller wrote: Oh, I'd be more than happy to accept help from developers like that. It's just a case of what the big bosses think of it. Plus there's the fact that some other arches operate on a it compiles, mark it stable policy, and we don't want developers to bring that attitude to the amd64 team. Hope you're not referring to any of my arches because that's not true :) In fact, if i did that, i wouldn't crash the alpha dev box so often, right Tobias? And that just leaves arm,hppa,mips,ppc,ppc64,s390,sh :P -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Keyword request interface (SoC candidate?)
Santiago M. Mola wrote: A lot of users don't feel comfortable using Bugzilla and often are lost with our procedures for keyword (both ~ and stable) requests. I think we could use an easy web interface for requesting specific keywords for packages in a point-and-click fashion. Speaking about Bugzilla in general, I think ours could really use a facelift. When you look at what some other projects have done to make their bug reporting and tracking interface more user-friendly, it's obvious we have a lot of room for improvement. I remember back when I first started using Gentoo seeing a mock-up some dev had done for a bugzilla redesign that was much simpler and visually appealing, but I can't remember who and I suppose they've probably retired since. I've always thought it was a shame it never saw implementation. Anyways, I think this could make a good project for someone in our community who would like to participate but perhaps is more artistic than technical. Previous web design work and a good understanding of user interface design would be required of course. I suppose we should probably ask infra if this is possible first too. ;) On keywording/stabilizing, Bugzilla has a flags feature that might be used to track what has been tested where. For example: https://bugzilla.mozilla.org/show_bug.cgi?id=12345 Flags have three states: +, -, and ?. + and - are obvious, and ? is a request. So imagine having a x86 tested flag that the maintainer sets to ? to request stabilization of their package. An email is sent to the arch alias notifying them of the request. The arch tester tests it out and sets the flag to + or - depending on their results. The arch dev stabilizes the package as normal. If we added a Keyword/Stable Request component to the Gentoo Linux product we could also have it dependent on that, so only bugs in that component would display the flags. We can also make it so only people with editbugs privileges and request or set flags. http://www.bugzilla.org/docs/2.22/html/flags-overview.html Again, this would require infra to be on board. -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwindows @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Fwd: Gentoo Foundation 2008 Elections - Results
Jorge Manuel B. S. Vicetto wrote: Hello fellow devs, users and Gentoo community, here are our 2008 trustees : NeddySeagoon fmccor tsunam tgall wltjr Congrats guys. :D -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwindows @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for March
В Сбт, 01/03/2008 в 14:39 +, Peter Weller пишет: There are also a number of problems with people on the team who are there soley so that they don't have to ask the team to mark a package stable for them - they can just go and stable it themselves. It'll be even better if we prohibit such things by telling that maintainer is not allowed to stabilize his/her packages. That said, 1. I know that some packages will never be stabilized without such practice but we could have list of such packages somewhere; 2. some archs do not have enough developer to enforce this policy but x86 and amd64 are not among them. -- Peter. signature.asc Description: Эта часть сообщения подписана цифровой подписью
Re: [gentoo-dev] Monthly Gentoo Council Reminder for March
Raúl Porcel wrote: Peter Weller wrote: Oh, I'd be more than happy to accept help from developers like that. It's just a case of what the big bosses think of it. Plus there's the fact that some other arches operate on a it compiles, mark it stable policy, and we don't want developers to bring that attitude to the amd64 team. Hope you're not referring to any of my arches because that's not true :) In fact, if i did that, i wouldn't crash the alpha dev box so often, right Tobias? I dunno - I just hit bug 211021 today while trying to clean out old bugs. Already stable on one arch and not a word from the maintainer. I do agree with many of the posts in this thread by others - a big issue is manpower. However, I did want to mention that stabling packages without input from maintainers seems to be a moderately-common practice. I'm sure the arch team leaders would welcome help if it were offered, but it is more important that packages keyworded stable actually work than for the latest-and-greatest package to be marked stable. Interested users can volunteer to be ATs as well - in my past experience as an AT when I keyworded a bug STABLE I could expect to see it committed by a dev within a few hours. While amd64 is a lot more mainstream than it used to be you can't just assume that upstream wouldn't have released something if it didn't work perfectly on amd64. Somebody had commented that there are cases where there are already-stable packages with bugs in them that are causing problems. Feel free to ping one of us, or start a discussion on the -amd64 mailing list, or email the amd64@ alias if necessary if something in particular is causing major headaches. Simply posting a comment in bug 37 out of 250 probably won't get much attention. I'm sure all the amd64 devs want to do what they can to help out those with more obscure packages. There are a LOT of packages marked stable on amd64 though, and while it has improved greatly upstream still doesn't support it as well as it does x86 (though I'm sure we won't get much sympathy from most of the other archs in this regard :) ). No disputing that there is a problem - we just want to be careful that the solution isn't worse than the problem... -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Monthly Gentoo Council Reminder for March
Hi, Richard Freeman [EMAIL PROTECTED]: Hope you're not referring to any of my arches because that's not true :) In fact, if i did that, i wouldn't crash the alpha dev box so often, right Tobias? I dunno - I just hit bug 211021 today while trying to clean out old bugs. Already stable on one arch and not a word from the maintainer. As I was the one ccing arches, I should explain here...humpback has not reacted on tor bugs for a long time, not even security ones. So I did bumps and minor fixes for some time now, including stabilisation requests. My only failure here was, that I did not add myself to metadata.xml. My policy is to ask for stabilisation -- no reaction for one week (if it is urgent), I call arches. While amd64 is a lot more mainstream than it used to be you can't just assume that upstream wouldn't have released something if it didn't work perfectly on amd64. Here you are right, and I must admit I sometimes only compile-test. I test everything I can, for special hardware I ask around in the team, but if there is no one I have no other choice. No disputing that there is a problem - we just want to be careful that the solution isn't worse than the problem... What we propose is proper testing and keywording by anyone around...not just team members. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for March
Richard Freeman wrote: Raúl Porcel wrote: Peter Weller wrote: Oh, I'd be more than happy to accept help from developers like that. It's just a case of what the big bosses think of it. Plus there's the fact that some other arches operate on a it compiles, mark it stable policy, and we don't want developers to bring that attitude to the amd64 team. Hope you're not referring to any of my arches because that's not true :) In fact, if i did that, i wouldn't crash the alpha dev box so often, right Tobias? I dunno - I just hit bug 211021 today while trying to clean out old bugs. Already stable on one arch and not a word from the maintainer. I do agree with many of the posts in this thread by others - a big issue is manpower. However, I did want to mention that stabling packages without input from maintainers seems to be a moderately-common practice. I've never seen that, unless the maintainer doesn't respond, like in this case, humpback has been ignoring his bugs for a long time, like other devs(unfortunately). Maybe the council should talk about that: devs ignoring his bugs for months, but i don't know how would they enforce that. What i've seen is some bugs where the arches were cc'ed by users or by a developer, but in this case, someone of the arch team that knows that the dev is active, just uncc's all the arches until the maintainer responds, but in this case, humpback didn't say anything about the previous tor stabilization request for months. So you should be glad someone active like Christian, took over the maintenance and he is responsible if something goes wrong with the stabilization. I'm sure the arch team leaders would welcome help if it were offered, but it is more important that packages keyworded stable actually work than for the latest-and-greatest package to be marked stable. Interested users can volunteer to be ATs as well - in my past experience as an AT when I keyworded a bug STABLE I could expect to see it committed by a dev within a few hours. IIRC you are from the blubb era, i'm i right? Blubb did a really god job with amd64, and in fact amd64 started 'slacking' since blubb left. Unfortunately that doesn't work anymore, in a lot of bugs i've seen an AT of yours posting his results, when i was going to do my arches. So i was more faster even that i have no ATs. And look at x86, we don't have any ATs, god, we even had some that moved to amd64! drac, mlangc, etc etc. For example, bug 205242. Look, its mlangc! :P While amd64 is a lot more mainstream than it used to be you can't just assume that upstream wouldn't have released something if it didn't work perfectly on amd64. Indeed, but on x86 we don't assume it either :) I don't understand how you having so many users, have manpower problems, you have two channels on IRC, x86 only has one and nobody says anything. It's just a though, i'm not blaming anyone. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Baselayout-2 progress?
Roy Marles [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sat, 01 Mar 2008 10:50:50 +: As others pointed out, this is a package manager issue and those blockers are there because of this. Not an OpenRC issue as such ;) Thanks ... And thank /you/! =8^) -- 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@lists.gentoo.org mailing list
Re: [gentoo-dev] Baselayout-2 progress?
Hmm, all interesting stuff You mention in the notes also that openrc has some kind of keepalive function which can restart crashing services. Can point me towards how that works (assuming it needs some kind of config?) I haven't had any time yet to try this on a test machine, but interested to give it a whirl on my embedded (busybox+uclibc) target... Cheers Ed W -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Baselayout-2 progress?
On Saturday 01 March 2008 22:26:24 Ed W wrote: Hmm, all interesting stuff You mention in the notes also that openrc has some kind of keepalive function which can restart crashing services. Can point me towards how that works (assuming it needs some kind of config?) No such function :) We can test to see if a service started daemon has crashed or not and report accordingly. The user can then restart the service if desired. This can be automated through scripts as well, but we don't automatically do this. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for March
At one time there were some apps which reported back usage from people's systems and showed package versions in use? Now, whilst this in itself is not an indication of package quality or bug-freeness. Perhaps it would be an interesting datastream to assist in deciding whether to mark a package stable or not? An incremental improvement to such a plan might be to consider how to split the data into high quality devs and testers running stuff stuff, keen users and dev boxes (which might be crashing and are of low quality). Sure it's a fairly low quality data source, but it might give a bit of confidence to take a punt unmasking a package if you can see that others are using it actively? Just my 2p Ed W -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Baselayout-2 progress?
Roy Marples schrieb: On Friday 29 February 2008 16:15:51 Ed W wrote: On the other hand since there still isn't a masked ebuild in portage (and I seem some notes on my on Roy's site) then I have to assume that in fact we are still a good way away from calling it a replacement and starting to push it out to users? It's actually been very stable and usable for a long time. It's not, and never will be a 100% drop in replacement for everything baselayout provides, but it's very very compatible. What about the timezone? Baselayout had a setting for the timezone in /etc/conf.d/clock. baselayout-2.0.0 + openrc doesn't seem to have that. Not needed? Bernd -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Baselayout-2 progress?
Bernd Steinhauser [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sat, 01 Mar 2008 23:50:09 +0100: What about the timezone? Baselayout had a setting for the timezone in /etc/conf.d/clock. baselayout-2.0.0 + openrc doesn't seem to have that. Not needed? Not needed indeed. The previous setting caused confusion because changing it didn't actually change the timezone (this isn't the place for the technical details). Now, the clock config file simply sets local or UTC, while the timezone is set using the standard glibc /etc/localtime - /usr/share/zoneinfo/ whatever-zone symlink or the TZ environmental variable (see the tzset and hwclock manpages among others). -- 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@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Baselayout-2 progress?
Duncan schrieb: Bernd Steinhauser [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sat, 01 Mar 2008 23:50:09 +0100: What about the timezone? Baselayout had a setting for the timezone in /etc/conf.d/clock. baselayout-2.0.0 + openrc doesn't seem to have that. Not needed? Not needed indeed. The previous setting caused confusion because changing it didn't actually change the timezone (this isn't the place for the technical details). Now, the clock config file simply sets local or UTC, while the timezone is set using the standard glibc /etc/localtime - /usr/share/zoneinfo/ whatever-zone symlink or the TZ environmental variable (see the tzset and hwclock manpages among others). Then there should be a note, that this setting is deprecated. Currently it only says: 'If you want to manage /etc/localtime yourself, set this to .' If there is a note, that this setting isn't used anymore it won't make users, that still have it set wonder why an etc update wants to remove it. Bernd -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for March
Raúl Porcel wrote: IIRC you are from the blubb era, i'm i right? Blubb did a really god job with amd64, and in fact amd64 started 'slacking' since blubb left. Unfortunately that doesn't work anymore, in a lot of bugs i've seen an AT of yours posting his results, when i was going to do my arches. So i was more faster even that i have no ATs. Yup - blubb is certainly missed. I can't point any fingers myself - I try to find and stabilize packages as I'm able to, but I can only spend so much time on gentoo. Every little bit helps though, even if I'm not high on the commits/day rankings. There are amd64 ATs out there - which brings up the other thread floating around. We need better ways to flag bugs that have been touched by an AT - for all I know there are a dozen open bugs that an AT has tested, but if there aren't any keywords or anything else I can query for, I can't get them stabilized. Indeed, but on x86 we don't assume it either :) I don't understand how you having so many users, have manpower problems, you have two channels on IRC, x86 only has one and nobody says anything. It's just a though, i'm not blaming anyone. My observation is that there are heavy-lifters who do a disproportionate share of the work. I'm certainly not one of them, and I really do appreciate these folks. If a heavy-lifter gives attention to something, it will shine. However, Gentoo is a volunteer-driven organization, and you can't order heavy-lifters to work on something in particular - it is their passion for what they choose to work on that makes them so effective. I guess what we need is processes that enable lots of small contributors to make a big difference - the bazzar approach. Another reply on this thread pointed out that it would be nice to be able to tell what packages people are using - if we could tell what is being used it would help guide stabilization without sacrificing testing (our users would be de-facto ATs without realizing it). The power of a thousand people doing very little can add up - many users would gladly sign up to have their packages monitored if it would help the gentoo cause. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March
Christian Faulhammer wrote: What we propose is proper testing and keywording by anyone around...not just team members. Thanks for the info - inactive maintainers are obviously a problem. Maybe the proper approach is for a more Free-for-all system like you suggest, with arch teams focusing on more arch-specific aspects of gentoo (such as the 32-bit libs for amd64, etc), and with arch teams having a QA oversight role for their arch. Perhaps arch teams should publish clear (and reasonably simple) policies they would like to see followed with their archs, and then devs could feel free to follow them on their own initiative. Accountability would obviously matter, but we don't want to chop off hands for first offenses, either. The Gentoo dev community is fairly closed - it isn't like just anybody can go keywording packages left and right. However, we do need to make sure that QA is followed. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March
Christian Faulhammer wrote: What we propose is proper testing and keywording by anyone around...not just team members. I agree... our main problem is manpower -- people actually working on the stable bugs. I've tried to do it myself a few times, but each time it just burns me out to the point where I don't want to (and won't) work on anything Gentoo-related for a time. I've mostly resigned myself to working on just security bugs, but even those are so common that we need people looking at them all the time as well. Anyway, I'm all for a policy of if you have an amd64 box, and you're on a team / herd that wants to move forward with stable plans, just consult the amd64 team and then go ahead with it. Anything to spread the workload so that people don't get fed up with the bottlenecks. Steve -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-portage-dev] please explain use of hooks
Hello I was aware that the alternative package managers provide hooks for some time now, but only found out recently that portage also has this feature. Unfortunately I was not able to find any documentation about it. I found some information related to hooks in portage on this list and elsewhere but all of those sources assumed that the reader already knows the basics. So what I am looking for is a tutorial along the lines howto write you first portage hook function. Of course a more in-depth description would also be welcome. If something like this already exists I apologize for not searching enough, and kindly ask you to point you to the location. The earlies post about hooks on this list seam to be from 2005, so I was a bit surprised I could not find any documentation about them. In my opinion this should be documented in the handbook. I can only assume that either no one found the time to write it or that hooks are intentionally not documented to prevent users from messing things up and then filling untraceable bug reports. So if later were the case I would still be very thankful if you could answer me in private, even though I think this should be documented in public. --Jonas -- gentoo-portage-dev@lists.gentoo.org mailing list
Re: [gentoo-portage-dev] please explain use of hooks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jonas Bernoulli wrote: So what I am looking for is a tutorial along the lines howto write you first portage hook function. Of course a more in-depth description would also be welcome. If something like this already exists I apologize for not searching enough, and kindly ask you to point you to the location. When portage is installed with USE=doc enabled, you'll find that there is a small Ebuild Phase Hooks section in the first chapter of the html documentation. Writing a phase hook is very much like writing a normal ebuild phase function. You just need to add a pre_ or post_ prefix to then name. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHyaK0/ejvha5XGaMRAjykAKCqcknbMtkLcqWSqB2t9wPN3PES7gCfQbPa 6MXfRyMUVQJBdREffaCwEBs= =6ymu -END PGP SIGNATURE- -- gentoo-portage-dev@lists.gentoo.org mailing list
