Re: [gentoo-dev] Council Agenda 20100809 rev 01
On 8/6/10 3:36 PM, Alex Legler wrote: > On Fri, 06 Aug 2010 14:49:19 -0700, "Paweł Hajdan, Jr." > wrote: >> 1. The Gentoo Security team is severly understaffed, they have an >> entry on the Staffing Needs page, but no long-term improvement is >> visible over the last 6 months. The status visibility is low, and >> it's even hard to ask for tasks to help with. > > And you'd like the council to do what about that exactly? I'd like the council to help with improving the situation. I tried to help at the project level, and I'll probably do some work for the team. However, it still seems to me that a more long-term solution needs to be applied. Are the project leads active? Why is the security team so busy it can't train new team members? Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] net-proxy/squid needs your love
On Wed, Aug 04, 2010 at 08:47:36PM +0300, Petteri Räty wrote: > On 08/04/2010 08:34 PM, Markos Chandras wrote: > > On Wed, Aug 04, 2010 at 07:12:18PM +0300, Petteri Räty wrote: > >> On 08/04/2010 02:50 PM, Markos Chandras wrote: > >> > >>> > >>> @Council: Yet another example that we need to track the status of every > >>> single project in order to have a clear picture of which projects are > >>> active and which are dead > >>> > >> > >> Pruning projects that don't actively elect a lead would be a good start > >> and that doesn't require anything from the council to be implemented. > >> > >> Regards, > >> Petteri > >> > > Don't you think we need a team for that? Who is eligible to filter the > > project > > list and ask status updates from them? > > > > I think undertakers can take care of any possible cleanup commits as > they already touch project pages for developer retirements. Is there enough manpower for that ? > If you want > to join for that purpose just be in contact with them and I think they > will accept my proposal. I wish I could but I am involved in way too many projects. Maybe on September. > As for just status queries I think anyone could > query the status from projects and nothing special is required. Of > course we should coordinate so that many simultaneous queries are not done. > > Regards, > Petteri > The inactivity of many herds most of the time blocks the work of some other herds. Isn't council's responsibility to step up and resolve these interproject issues? It shouldn't be that difficult to ask for monthly project status updates ( A simple "Yes, we are alive but slow kthxbye" would be sufficient, just to know that somebody is actually listening to that e-mail alias after all ), discuss this on Council's monthly meetings ( Shouldn't it take more than 20' if you already have the status updates on your Inbox ) and decide whether you should prune these herds or not. IMHO undertakers cannot handle the load atm but council can. Furthermore this inactivity ( as I said before ) doesn't look that good at all to our user community . Moreover it seems like dead herds don't even bother to ask for help or "hire" more proxy maintainers to co-maintainer some of their ebuilds. They just stay quiet on their corner and do nothing. Since Council is supposed to be the leading entity of Gentoo I was wondering how come this issue never popped up on any of your meetings. Do you really don't see a problem here or I am just that weird and everything is running smoothly? -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 pgpSSyKAEkC9p.pgp Description: PGP signature
Re: [gentoo-dev] Council Agenda 20100809 rev 01
On Fri, 06 Aug 2010 14:49:19 -0700, "Paweł Hajdan, Jr." wrote: > > 1. The Gentoo Security team is severly understaffed, they have an > entry on the Staffing Needs page, but no long-term improvement is > visible over the last 6 months. The status visibility is low, and > it's even hard to ask for tasks to help with. And you'd like the council to do what about that exactly? -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
Re: [gentoo-dev] Council Agenda 20100809 rev 01
On 8/6/10 12:26 PM, Tomáš Chvátal wrote: > since I am this meetings girl for everything here is first pass on our > agenda. I'd like to add some points to the agenda. 1. The Gentoo Security team is severly understaffed, they have an entry on the Staffing Needs page, but no long-term improvement is visible over the last 6 months. The status visibility is low, and it's even hard to ask for tasks to help with. 2. Can we get more project visibility about the git migration? Like what is happening, what is blocking us, some roadmaps? Maybe the data is there and I can't find it - but that would be another problem. Paweł signature.asc Description: OpenPGP digital signature
[gentoo-dev] Council Agenda 20100809 rev 01
Hi, since I am this meetings girl for everything here is first pass on our agenda. I am adding this mail only to g-dev and g-dev-announce to see if everyone notice, sorry if it slip your radar. Also if you have something to say on this mail please reply to gentoo-dev, or you will render me quite sad about thread breaking. Without much ado here goes THE PLAN: 1) allow all members to show up (5 min) 2) voting 2a) we have nothing to vote this time, nobody wanted anything YAY :) 3) discussion 3a) from last council meeting: the mailing list situation 3b) from last council meeting: eclass API changes 3c) EAPI 4 status (jmbsvicetto nominate this so we actualy do something new) 4) Bugs assigned to council@ in bugzilla and their progress 5) select the chair for following meeting 6) open floor: community/developers can smash us here :) Z) buy some cookies (30 min) Cheers Tomas signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Reviving GLEP33
On Fri, 6 Aug 2010 11:18:46 -0700 Brian Harring wrote: > And by "right now", I assume you meant to say "minimally a year down > the line after a portage is stabled supporting g55 semantics and > resolving any breakage it's usage induces". You know, the same issue > EAPI itself had to go through to ensure that people had a reasonable > chance of getting an appropriate error message and support being in > place. Uh, no, since GLEP 55 doesn't need users to be using a newer Portage. That is one of the many ways in which it is a much better solution. > New version formats aren't magically usable the moment g55 lands. At > the very least you're forgetting about bundled glsa's and their > knowledge of atom formats. > > Suppose the next comment will be "they suck, throw them out", but so > it goes. No, the fix is to give them EAPI suffixes too. > Realistically, 'the fact is' that a specific scm tag is preferable to > -. The reality is that people and the tools have been working > around it without huge issues for a long while. > > Would it be nice having some -scm tag? Sure. Is it worth the > disruption impementing it, and it's dependencies requires? That > arguement you've still not managed to convince people of. ...and 1.2-3 and 1.2-alpha3 style versions, and so on. Remember, it's only a disruption to implement it without GLEP 55. > The restrictions are "no new global functionality can set or > influence EAPI". Basically the same restriction you forced on > eclasses. It's nasty and arbitrary when I state it, but some how it > is sane when you propose it the same thing? No, they're not. The restrictions are "no changes that will make older package managers not realise that the EAPI was supposed to have been set to something else". That's not the same thing at all, especially on the "using new Bash syntax" front, and the very fact that you missed that point just goes to illustrate the difficulties involved. > The thing you're ignoring out of this g55 idiocy is that people don't > particularly seem to want it. There has been an extremely vocal > subgroup of paludis/exherbo devs pushing for it while everyone else > seems to have less than an interest in it. That's generalizing a > bit, but is reasonably accurate. Uh, no. Plenty of people want it. There has been an extremely vocal subgroup of people who will yell at anything they think is connected to the 'wrong people' pushing against it, thus making everyone else suffer. > _EITHER WAY_, rather than having g33 get beat down for unrelated > reasons by people screaming they want their pony/g55, g33 can proceed > despite claims to the contrary, and it doesn't require g55 as > ciaran/crew have claimed. But no-one except you wants GLEP 33. What people want is per-package eclasses *without* all the arbitrary restrictions in GLEP 33. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Reviving GLEP33
On Fri, Aug 06, 2010 at 06:48:31PM +0100, Ciaran McCreesh wrote: > On Fri, 6 Aug 2010 10:27:32 -0700 > Brian Harring wrote: > > As for 'blatant hack', if you've got no users nor preexisting ebuild > > data, you can design whatever you want- it's quite easy to call > > things blatant hacks if you can design things from scratch and not > > worry about compatibility. This is a form of armchair quarterbacking. > > No it isn't, since we've proposed a working alternative that doesn't > have any of the defects that EAPI in its current form does. > You appear to be confusing "providing a better replacement that we can > use immediately that doesn't have any of these problems" with > "bitching". > That's ok. We can migrate to an even better solution now. And by "right now", I assume you meant to say "minimally a year down the line after a portage is stabled supporting g55 semantics and resolving any breakage it's usage induces". You know, the same issue EAPI itself had to go through to ensure that people had a reasonable chance of getting an appropriate error message and support being in place. Accuracy in details is very useful, including stating the full picture rather than just the parts you think sell your particular view. > The *fact* is, you can't use new version formats with any of your > proposals, New version formats aren't magically usable the moment g55 lands. At the very least you're forgetting about bundled glsa's and their knowledge of atom formats. Suppose the next comment will be "they suck, throw them out", but so it goes. Realistically, 'the fact is' that a specific scm tag is preferable to -. The reality is that people and the tools have been working around it without huge issues for a long while. Would it be nice having some -scm tag? Sure. Is it worth the disruption impementing it, and it's dependencies requires? That arguement you've still not managed to convince people of. > and using new global scope functionality or new bash > functionality introduces all kinds of nasty difficulties and arbitrary > restrictions of which developers have to be intimately aware. The restrictions are "no new global functionality can set or influence EAPI". Basically the same restriction you forced on eclasses. It's nasty and arbitrary when I state it, but some how it is sane when you propose it the same thing? The thing you're ignoring out of this g55 idiocy is that people don't particularly seem to want it. There has been an extremely vocal subgroup of paludis/exherbo devs pushing for it while everyone else seems to have less than an interest in it. That's generalizing a bit, but is reasonably accurate. Pretty much, scream all you want, if people don't like it it's not going to go anywhere. So... keep fighting windmills, or do something useful and use what is available to you (existing EAPI semantics). _EITHER WAY_, rather than having g33 get beat down for unrelated reasons by people screaming they want their pony/g55, g33 can proceed despite claims to the contrary, and it doesn't require g55 as ciaran/crew have claimed. Split a thread if you really want to rehash g55 also, rather than the thread jacking that is underway. ~brian pgpqKvk7fNErb.pgp Description: PGP signature
Re: [gentoo-dev] RFC: Reviving GLEP33
On Fri, 6 Aug 2010 10:27:32 -0700 Brian Harring wrote: > As for 'blatant hack', if you've got no users nor preexisting ebuild > data, you can design whatever you want- it's quite easy to call > things blatant hacks if you can design things from scratch and not > worry about compatibility. This is a form of armchair quarterbacking. No it isn't, since we've proposed a working alternative that doesn't have any of the defects that EAPI in its current form does. > EAPI did not have that luxury however, thus a pragmatic solution was > choosen. I've heard a lot of bitching from various folk about EAPI > over the years, but the fact is even with it's flaws (both in > process, people involved, and in original constraints) it still has > been rolling changes out- all the while without requiring people to > rewrite ebuilds from scratch, or continually track an unversioned > format that changes semi-monthly. You appear to be confusing "providing a better replacement that we can use immediately that doesn't have any of these problems" with "bitching". > It'd be nice if people were to remember that rather than spending > their time bitching about it. Hindsight, I'd have done a few things > differently, but that's the nature of hindsight- specifically I > would've used an eapi function rather than var. That's ok. We can migrate to an even better solution now. > Whether said people like it or not, it was a known decision at the > time of creation- including the scenario under discussion. One thing > you'll note about my posts is that I'll list out what is possible, > and state what should/shouldn't be done. Just because I personally > think something is complete shit doesn't mean I go telling folk it's > impossible. There's a difference between opinion and fact- you're > excusing opinion stated as fact, which is not correct. Fact is, this > technique does work even if certain folk have another approach they > want instead. The *fact* is, you can't use new version formats with any of your proposals, and using new global scope functionality or new bash functionality introduces all kinds of nasty difficulties and arbitrary restrictions of which developers have to be intimately aware. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Reviving GLEP33
On Fri, Aug 06, 2010 at 05:15:15PM +0100, David Leverton wrote: > On 5 August 2010 04:27, Brian Harring wrote: > > If an EAPI adds a new global function that cannot set/influence EAPI, > > PM's that don't support that EAPI will spit complaints about 'missing > > command' during sourcing- however the PM will still see the EAPI value > > is one it knows it doesn't support, and act accordingly. > > You're suggesting a system based around ebuilds running commands that > don't exist and ignoring the errors, which is a pretty blatant hack. It's called forwards compatibility, and is basically no different than type -p usage- the sole diff is that in ebuild usage since you're just pulling metadata as the first step, the existance check isn't needed since that functionality can't influence/set EAPI. If you don't support the EAPI result, complaining to the user about the steps getting there is misinformative at best. If you do support that EAPI, than bitch at the user with the errors. As for 'blatant hack', if you've got no users nor preexisting ebuild data, you can design whatever you want- it's quite easy to call things blatant hacks if you can design things from scratch and not worry about compatibility. This is a form of armchair quarterbacking. EAPI did not have that luxury however, thus a pragmatic solution was choosen. I've heard a lot of bitching from various folk about EAPI over the years, but the fact is even with it's flaws (both in process, people involved, and in original constraints) it still has been rolling changes out- all the while without requiring people to rewrite ebuilds from scratch, or continually track an unversioned format that changes semi-monthly. It'd be nice if people were to remember that rather than spending their time bitching about it. Hindsight, I'd have done a few things differently, but that's the nature of hindsight- specifically I would've used an eapi function rather than var. > While I don't think it's /absolutely/ out of the question, as I said > earlier, I can see why some people would exclude it from consideration > entirely. Whether said people like it or not, it was a known decision at the time of creation- including the scenario under discussion. One thing you'll note about my posts is that I'll list out what is possible, and state what should/shouldn't be done. Just because I personally think something is complete shit doesn't mean I go telling folk it's impossible. There's a difference between opinion and fact- you're excusing opinion stated as fact, which is not correct. Fact is, this technique does work even if certain folk have another approach they want instead. Either way, this trick does work, although PM's could stand some tweaking in their stdout/stderr outputting to make it a bit more user friendly, so g33 can be ironed out. ~brian pgpHbDYXe7AkR.pgp Description: PGP signature
Re: [gentoo-dev] RFC: Reviving GLEP33
On 5 August 2010 04:27, Brian Harring wrote: > If an EAPI adds a new global function that cannot set/influence EAPI, > PM's that don't support that EAPI will spit complaints about 'missing > command' during sourcing- however the PM will still see the EAPI value > is one it knows it doesn't support, and act accordingly. You're suggesting a system based around ebuilds running commands that don't exist and ignoring the errors, which is a pretty blatant hack. While I don't think it's /absolutely/ out of the question, as I said earlier, I can see why some people would exclude it from consideration entirely.
[gentoo-dev] QA last rites for mail-filter/bsfilter; mail-client/claws-mail-bsfilter
# Diego E. Pettenò (06 Aug 2010) # on behalf of QA team # # bsfilter is dead upstream, not bumped since 2006; # current stable was added in 2005 (and is not the last one # available); claws-mail-bsfilter is the only user and also # has broken dependencies. # # Removal on 2010-10-05 mail-filter/bsfilter mail-client/claws-mail-bsfilter
[gentoo-dev] Re: RFC: Reviving GLEP33
Jeremy Olexa posted on Thu, 05 Aug 2010 18:43:55 -0500 as excerpted: > People will not "hate you" - if the portage with EAPI4 is in ~arch, you > can have PHP w/EAPI4 in ~arch, even on zero-day of release. Likewise > with stable tree. It does not matter when council "approves" EAPI4, it > matters when portage has the implementation and is released.. Isn't it /both/? IOW, just because portage implements it, doesn't mean it's usable in-tree, if it's not part of an approved EAPI. Similarly, approval before released support again doesn't mean it's allowed in-tree. Only with both is it then allowed. Leastwise, that was my read of the council decision back then. But zero-day, yes, provided it's both approved and in-portage at the same level (~arch or stable). > The caveat is with @system packages, especially bash/python/portage > itself. Again, yes. -- 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
