Re: [gentoo-dev] [Gentoo Pheonix] Heartbeat team force
On 04/07/10 21:24, Ben de Groot wrote: with the herd embedded it's difficult though: the page http://www.gentoo.org/proj/en/base/embedded/index.xml lists members for it but the page source does not hold it, explicitly. where does it come from? It does, as can be seen in http://www.gentoo.org/proj/en/base/embedded/index.xml?passthru=1 you refer to the members of the embedded team. i was refering to the members of the embedded herd. the rendered page lists dagger, kumba, pebenito, solar to be working for that herd. the link you gave does not contain the word dagger. how does it get in there? sebastian
[gentoo-dev] Re: [Gentoo Pheonix] Heartbeat team force
* Sebastian Pipping sp...@gentoo.org: i was refering to the members of the embedded herd. the rendered page lists dagger, kumba, pebenito, solar to be working for that herd. the link you gave does not contain the word dagger. how does it get in there? From herds.xml. Really.
Re: [gentoo-dev] Council meeting 19 April 2010
On 04/07/2010 12:05 PM, Ulrich Mueller wrote: Next monthly council meeting will be at 19 April 2010, 18:00 UTC in #gentoo-council. If you have any topics you want us to discuss or even vote about, simply followup to this message. Ulrich Two things already discussed on this mailing list but I don't see a definite consensus so taking for a spin through council. 1. Keywording bugs with a single arch: http://archives.gentoo.org/gentoo-dev/msg_3f8603c9bc97b7b0bcf59782848c2650.xml Options to vote in order: After the maintainer has accepted that a package is good for stable (by being the assignee or reporter). a) The preferred way is to assign the bug to the single arch in question b) The bug can be either assigned to the arch or the arch can be CCed and the maintainer is the assignee c) The maintainer is the assignee and the arch is CCed 2. Bugzilla resolutions http://archives.gentoo.org/gentoo-dev/msg_9cb8abe1d6608e4fb4e525833eea897b.xml Vote on: - Remove LATER and REMIND from resolutions - Add LATER as a KEYWORD - Add resolution OBSOLETE Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Council meeting 19 April 2010
On Wed, Apr 07, 2010 at 11:05:34AM +0200, Ulrich Mueller wrote: Next monthly council meeting will be at 19 April 2010, 18:00 UTC in #gentoo-council. If you have any topics you want us to discuss or even vote about, simply followup to this message. VALID_USE- http://archives.gentoo.org/gentoo-dev/msg_b0e868626019f497eba47194c34e5421.xml Historically, no PMS change has been glep'ified, but if the council wants PMS changes to start being glep'd I'd be willing to guinea pig this one- earliest I'd have the glep out the door is saturday also. Few additional notes to the proposal- 1) few has offered up his time patch wise. 2) if he backs out, I'll throw in a gurantee of having it done prior to the next council meeting (realistically I can do it faster, I just have other fish I'd like to be frying). 3) dev feedback generally has been positive, exempting ciaran's views on it- please review those (if you'd like a summation I can provide one). 4) if there are questions re: use cycle breaking or other bits, feel free to ask prior please- council meeting times unfortunately right now intersect badly with my paying work so it's hard to be online to answer questions during the meeting (that said per the norm I'll try). 5) final reminder- part of the impetus of this is that if this is punted till EAPI5, it forces pkg_pretend as the interim use constraint checking- this has some nasty implications on the use cycle breaking intentions since it would require everyone to upgrade their ebuilds to EAPI5 if they've got use state constraints. Basically screws things up a bit and requires a potentially pointless EAPI bump for the sake of trying to knock EAPI4 out the door now (regardless of how long it takes to stable portage for it) rather than adding a few weeks in. Thanks- ~harring pgppE5c5febGm.pgp Description: PGP signature
Re: [gentoo-dev] Council meeting 19 April 2010
On Thu, 8 Apr 2010 05:02:25 -0700 Brian Harring ferri...@gmail.com wrote: 4) if there are questions re: use cycle breaking or other bits, feel free to ask prior please- council meeting times unfortunately right now intersect badly with my paying work so it's hard to be online to answer questions during the meeting (that said per the norm I'll try). Please detail your cycle breaking algorithm that works in such a way that it's guaranteed not to toggle flags that will break a system, but that does not require any changes to be made to ebuilds etc telling the package manager what those flags are. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Council meeting 19 April 2010
On 04/08/10 15:29, Ciaran McCreesh wrote: On Thu, 8 Apr 2010 05:02:25 -0700 Brian Harring ferri...@gmail.com wrote: 4) if there are questions re: use cycle breaking or other bits, feel free to ask prior please- council meeting times unfortunately right now intersect badly with my paying work so it's hard to be online to answer questions during the meeting (that said per the norm I'll try). Please detail your cycle breaking algorithm that works in such a way that it's guaranteed not to toggle flags that will break a system, but that does not require any changes to be made to ebuilds etc telling the package manager what those flags are. That would violate the Entscheidungsproblem. But why would you make the cycle breaking depend on an oracle? Once we have the method in place we can find the two special cases and think of ways to fix them. Abandoning the idea as a whole just because there may be a corner case that isn't as easy appears quite silly to me. Brian's proposal is the only one I've seen that is deterministic and sane, so I think we should figure out if we can improve it instead of giving up at the first bump in the road.
Re: [gentoo-dev] Council meeting 19 April 2010
On Thu, 08 Apr 2010 16:08:57 +0200 Patrick Lauer patr...@gentoo.org wrote: Please detail your cycle breaking algorithm that works in such a way that it's guaranteed not to toggle flags that will break a system, but that does not require any changes to be made to ebuilds etc telling the package manager what those flags are. That would violate the Entscheidungsproblem. But why would you make the cycle breaking depend on an oracle? Once we have the method in place we can find the two special cases and think of ways to fix them. The problem is, the special cases where it goes horribly wrong aren't rare. As soon as you start looking for cycles, you find flags like 'build', 'bootstrap' and 'acl'. Abandoning the idea as a whole just because there may be a corner case that isn't as easy appears quite silly to me. I'm not after abandoning the idea. I'm after doing it properly, and doing it properly starts by handling the problematic cases rather than pretending they don't exist. We've already seen repeatedly what goes wrong when you start with the assumption it'll probably work and then pile on special exceptions every time someone gets screwed over by something you didn't think of. Why don't we go with we'll only do it for things where we know it'll work instead this time? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [Gentoo Pheonix] Heartbeat team force
On Wed, Apr 07, 2010 at 01:20:11PM +0200, Sebastian Pipping wrote: Current results === Bug load per developer -- http://dev.gentoo.org/~sping/bug-heartbeat/report--bug-count-by-person.html What's the actual math that you're using (it wasn't clear in your repo). Question to be answered === - herds.xml does not hold membership lists for all projects, not even herds. The load evaluator needs access to complete mappings to generate output close to reality. How can such a mapping be made without duplicating data? herds, project files, aliases: - 3 sets of non-overlapping data. - lets ignore the private aliases for now, very few of them should get package bugs. Report on unresolved bugs owned by hidden aliases: - 11 of the 93 aliases have bugs - 258 bugs in total - Those with 10 bugs: - infra, 78 - bugzilla, 47 - retirement, 28 - mirror-admin, 21 - forum-mods, 20 - devrel, 19 - recruiters, 19 - Pulling XML out of Bugzilla does no longer feel right with this amount of data: it's 15,000 open bugs that need to be refreshed periodically in chunks of 100 bugs (Bugzilla's limit) each. That's 150 request for a full sync. How can that be improved? Lets talk more about what queries you're using, and we can probably work something out. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgp1RnvDCkrSG.pgp Description: PGP signature
[gentoo-dev] Re: [RFC] Gentoo Wiki Project
On Mon, 5 Apr 2010 20:12:49 +0200 Ben de Groot yng...@gentoo.org wrote: After the mostly positive feedback on the recent wiki discussion, we have now gone ahead, formed a preliminary team consisting of both users and developers, and put up a project page [1]. All constructive feedback on this new project is welcome. why are we setting up a user wiki when a very popular one already exists? it seems like a complete duplication of effort. i'm not saying don't do it, i'm just baffled why we would. - moderation can we can lock certain pages down to dev edits only? i'd like to document some of our policies/best practices that don't seem to be in writing anywhere (after vetting them on the list of course). -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [RFC] Gentoo Wiki Project
On 8 April 2010 21:51, Ryan Hill dirtye...@gentoo.org wrote: why are we setting up a user wiki when a very popular one already exists? Because some devs request things like this: can we can lock certain pages down to dev edits only? In our wiki we will be able to. Cheers, -- Ben de Groot Gentoo Qt project lead developer Gentoo Wiki project lead
[gentoo-dev] Re: [RFC] Gentoo Wiki Project
On Thu, 8 Apr 2010 22:13:07 +0200 Ben de Groot yng...@gentoo.org wrote: On 8 April 2010 21:51, Ryan Hill dirtye...@gentoo.org wrote: why are we setting up a user wiki when a very popular one already exists? Because some devs request things like this: can we can lock certain pages down to dev edits only? In our wiki we will be able to. you misunderstood me. i've wanted a dev wiki for years. i just don't see why it should also be promoted as a user wiki when one already exists. -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] [Gentoo Pheonix] Heartbeat team force
On 04/08/10 21:16, Robin H. Johnson wrote: On Wed, Apr 07, 2010 at 01:20:11PM +0200, Sebastian Pipping wrote: Current results === Bug load per developer -- http://dev.gentoo.org/~sping/bug-heartbeat/report--bug-count-by-person.html What's the actual math that you're using (it wasn't clear in your repo). let me try in python: load[dev] = bugs[dev] \ + reduce(sum, [bugs(h)/members(h) for h in herds[dev]]) it's personal bugs plus a fraction of all herds you're in. makes sense? - Pulling XML out of Bugzilla does no longer feel right with this amount of data: it's 15,000 open bugs that need to be refreshed periodically in chunks of 100 bugs (Bugzilla's limit) each. That's 150 request for a full sync. How can that be improved? Lets talk more about what queries you're using, and we can probably work something out. speaking of queries would limit me in what i may ask the data in the future. i have a full dump on open bugs more or less so i can ask them whatever i like. it's more flexible to me and makes much easier code than SQL stuff would. i guess that doesn't make it easier? sebastian
RE: [gentoo-dev] Re: [RFC] Gentoo Wiki Project
The official wiki can be use by powerusers who want to write some pretty good doc. A lot of powerusers can write excellent doc on the gentoo forum right now, so they don't need to by Gentoo Dev to right excellent stuff. I don't see your point. To: gentoo-dev@lists.gentoo.org From: dirtye...@gentoo.org Subject: [gentoo-dev] Re: [RFC] Gentoo Wiki Project Date: Thu, 8 Apr 2010 14:56:04 -0600 On Thu, 8 Apr 2010 22:13:07 +0200 Ben de Groot yng...@gentoo.org wrote: On 8 April 2010 21:51, Ryan Hill dirtye...@gentoo.org wrote: why are we setting up a user wiki when a very popular one already exists? Because some devs request things like this: can we can lock certain pages down to dev edits only? In our wiki we will be able to. you misunderstood me. i've wanted a dev wiki for years. i just don't see why it should also be promoted as a user wiki when one already exists. -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 _ Videos that have everyone talking! Now also in HD! http://go.microsoft.com/?linkid=9724465
[gentoo-dev] Re: [RFC] Gentoo Wiki Project
On Thu, 8 Apr 2010 21:37:46 + Sylvain Alain d2_rac...@hotmail.com wrote: The official wiki can be use by powerusers who want to write some pretty good doc. A lot of powerusers can write excellent doc on the gentoo forum right now, so they don't need to by Gentoo Dev to right excellent stuff. I don't see your point. They already write great stuff on http://en.gentoo-wiki.com/. I think having two different places to put this kind of stuff might split the contributor base. It'd be nice if we could either merge the two or make the official wiki about developing with Gentoo rather than how to use Gentoo, but in any case I'm just happy to have somewhere to stick things. -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
RE: [gentoo-dev] Re: [RFC] Gentoo Wiki Project
Indeed, that's why I don't want to have a wiki for devs only. The Gentoo wiki must be for the community and by the community :P There are many Gentoo experts that don't want to be officially devs. d2_racing To: gentoo-dev@lists.gentoo.org From: dirtye...@gentoo.org Subject: [gentoo-dev] Re: [RFC] Gentoo Wiki Project Date: Thu, 8 Apr 2010 16:55:36 -0600 On Thu, 8 Apr 2010 21:37:46 + Sylvain Alain d2_rac...@hotmail.com wrote: The official wiki can be use by powerusers who want to write some pretty good doc. A lot of powerusers can write excellent doc on the gentoo forum right now, so they don't need to by Gentoo Dev to right excellent stuff. I don't see your point. They already write great stuff on http://en.gentoo-wiki.com/. I think having two different places to put this kind of stuff might split the contributor base. It'd be nice if we could either merge the two or make the official wiki about developing with Gentoo rather than how to use Gentoo, but in any case I'm just happy to have somewhere to stick things. -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 _ Live connected. Get Hotmail Messenger on your phone. http://go.microsoft.com/?linkid=9724462
Re: [gentoo-dev] Re: [RFC] Gentoo Wiki Project
Hi, On 2010-04-08 19:51 UTC Ryan Hill wrote: On Mon, 5 Apr 2010 20:12:49 +0200 Ben de Groot yng...@gentoo.org wrote: After the mostly positive feedback on the recent wiki discussion, we have now gone ahead, formed a preliminary team consisting of both users and developers, and put up a project page [1]. All constructive feedback on this new project is welcome. why are we setting up a user wiki when a very popular one already exists? it seems like a complete duplication of effort. i'm not saying don't do it, i'm just baffled why we would. Well, one reason could be, that the unofficial one lost its whole database once, and there were other multiple multi-day outages in the past. I expect an official Wiki to have a reasonable availability and not losing most of the content, breaking links all over the net for months. Patrick. -- Key ID: 0x86E346D4http://patrick-nagel.net/key.asc Fingerprint: 7745 E1BE FA8B FBAD 76AB 2BFC C981 E686 86E3 46D4 signature.asc Description: This is a digitally signed message part.
