Re: [gentoo-dev] [RFC] Ideas for projects...
On Thu, 11 Jan 2007 16:04:31 -0500 Chris Gianelloni [EMAIL PROTECTED] wrote: Submit your ideas here, so we can discuss them. I will be choosing one idea that we think we can accomplish to test out the idea of Council-driven projects. How about unified (and enforced) rules about Manifest PGP signing? Or was this already finished by someone? I am referring to key size, expiration length, trusted signatures, whether I can use my regular key, or a special one, ... If this has already been agreed upon and covered somewhere, can someone point me to an URL, so I can learn how do it right? Kind regards, -- Andrej Ticho Kacian ticho at gentoo dot org Gentoo Linux Developer - net-mail, antivirus, sound, x86 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Ideas for projects...
Andrej Kacian wrote: On Thu, 11 Jan 2007 16:04:31 -0500 Chris Gianelloni [EMAIL PROTECTED] wrote: Submit your ideas here, so we can discuss them. I will be choosing one idea that we think we can accomplish to test out the idea of Council-driven projects. How about unified (and enforced) rules about Manifest PGP signing? Or was this already finished by someone? I am referring to key size, expiration length, trusted signatures, whether I can use my regular key, or a special one, ... If this has already been agreed upon and covered somewhere, can someone point me to an URL, so I can learn how do it right? Kind regards, Talk to robbat2. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Ideas for projects...
Chris Gianelloni wrote: Submit your ideas here, so we can discuss them. I will be choosing one idea that we think we can accomplish to test out the idea of Council-driven projects. A simple QA review of the entire portage tree, fixing any trivial QA concern like missing headers inclusion, missing -fno-strict-aliasing wherever there are bad programming practices and so on; pushing upstream whatever is just more complicate that including an header or adding a CFLAG. -- Sandro (sanchan) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Ideas for projects...
On Mon, 22 Jan 2007 11:48:14 +0100 sanchan [EMAIL PROTECTED] wrote: | Chris Gianelloni wrote: | Submit your ideas here, so we can discuss them. I will be choosing | one idea that we think we can accomplish to test out the idea of | Council-driven projects. | | A simple QA review of the entire portage tree, fixing any trivial QA | concern like missing headers inclusion, missing -fno-strict-aliasing | wherever there are bad programming practices and so on; pushing | upstream whatever is just more complicate that including an header or | adding a CFLAG. And if you don't push upstream, a) it will never get fixed, b) people will carry on making the same mistakes and c) every version bump takes much longer. It's also harder for QA to contact upstream than the package maintainer, since QA will have to look for the appropriate bug tracker or mailing list, whereas package maintainers know this already. And ultimately, it's a waste of QA's time. There are far more severe breakages and there are not many people in QA. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Ideas for projects...
Ciaran McCreesh ha scritto: And ultimately, it's a waste of QA's time. There are far more severe breakages and there are not many people in QA. That's why I proposed this for a small targeted project. -- Sandro (sanchan) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Ideas for projects...
sanchan wrote: Ciaran McCreesh ha scritto: And ultimately, it's a waste of QA's time. There are far more severe breakages and there are not many people in QA. That's why I proposed this for a small targeted project. It was my interpretation that the benefit of a council driven non-tree project is that we can essentially involve non-developers in it. Doing a QA check is a great idea; but you need well trained people to do it and those people need gentoo-x86 access. Besides, the project is supposed to be fun :P -Alec -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Ideas for projects...
While hanging around lca07 it was mentioned how bandwidth hungry Gentoo is. Given a lot of the world is still on dialup this could increase the potential userbase for Gentoo. As such the project idea is Automated Xdelta Generation. principles: no manual generation of xdeltas by gentoo devs simple user usage (FEATURES=xdelta) avoiding digesting problems remain compatible with existing ebuilds user interface: FEATURES=xdelta emerge ~sys-kernel/gentoo-sources-2.6.20 found /usr/portage/distfiles/linux-2.6.19.tar.bz2 fetching linux-2.6.19_xdelta_2.6.20.xdelta generating linux-2.6.20.tar digest /usr/portage/distfiles/linux-2.6.20.tar matches storing /usr/portage/distfiles/linux-2.6.20.tar.bz2 (more fetching) unpacking .. ... ... FEATURES=xdelta emerge ~sys-kernel/hardened-sources-2.6.20 found /usr/portage/distfiles/linux-2.6.20.tar.bz2 digest mismatch - checking linux-2.6.20.tar digest good - assuming it was xdelta generated (more fetching) unpacking . I'm thinking xdeltas that gets generated on the staging server and some portage support so facilitate a minimal download. Note: i haven't looked at previous xdelta portage patches from years ago. -- Daniel Black [EMAIL PROTECTED] Gentoo Foundation pgpb4nnRYGEDq.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Ideas for projects...
Chris Gianelloni [EMAIL PROTECTED] said: Submit your ideas here, so we can discuss them. I will be choosing one idea that we think we can accomplish to test out the idea of Council-driven projects. packages.g.o is a really helpful tool - which could be even more helpful if there where some people behind it... and also the list of aging ebuilds with unstable keywords could be another project that perhaps could be revitalised through the council's action... kind regards Thilo pgpUMiduwnGv0.pgp Description: PGP signature
RE: [gentoo-dev] [RFC] Ideas for projects...
On Thu, 2007-01-11 at 16:36 -0600, Jason Huebel wrote: K, so my account hasn't been retired yet, so I'm making this comment as a developer (at least until someone gets around to my retirement bug). :-) I really like blubb's idea here. Not just of implementing GLEP 42, but the idea of having the Council responsible for overseeing and assigning tasks for the implementation of ALL approved GLEPs. I would only see this as feasible if the Council: #1. was considered everyone's manager #2. could refuse to continue work on a GLEP, even ones previously approved #3. had some control over what people actually worked on #4. was involved in the GLEP process before the approval (I'm sure there's more...) Honestly, I see #3 and #4 as the biggest problems. Were it up to me, I likely wouldn't have approved *many* of the earlier GLEPs, knowing that they would be very hard to implement and oversee. A GLEP is an enhancement idea created within Gentoo. The idea I had was really for *new* ideas that wouldn't necessarily be covered under the scope of a GLEP. Remember that we don't really have control over what people do. We're currently more geared towards policy. The idea, as I suggested it, was to create new groups that *did* meet all of the above concepts. A group that works for the Council, on a project that has had oversight from the beginning, allowing us to come up with milestones and tasks *prior* to any other work being done. Think of it more like contract developers that are assigned a task, rather than trying to strong arm the current developer pool, which are more generic developers, into doing something. Basically, it is recruiting with the fore-knowledge of what you'll be working on, rather than us trying to add such controls into the current developer system. Maybe GLEP 42 could be the pilot. :-) As far as I know, most of the portage-side stuff is done. Jason Huebel -Original Message- From: Simon Stelling [mailto:[EMAIL PROTECTED] Sent: Thursday, January 11, 2007 4:24 PM To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Ideas for projects... I like the idea. Something really useful I could think of is *drums* the implementation of GLEP 42. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list -- 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] Ideas for projects...
Chris Gianelloni wrote: The Gentoo Council is looking for some ideas for some small projects that we could initiate that would help Gentoo. These project ideas should be things that are attainable in a measurable amount of time, and should be fairly small in scope. This would be in the same vein as the Google Summer of Code projects. Robin Johnson came up with a good example, which was genflags an application that was to gather information from the running system and spit out a customized set of C(XX)FLAGS for the user. Submit your ideas here, so we can discuss them. I will be choosing one idea that we think we can accomplish to test out the idea of Council-driven projects. Thanks in advance! RSS feeds for packages added and removed from the tree with potential support for external overlays? I can see a file like debian's sources.list for the external ones with the addresses like this: #Add external overlay addresses here: http://dev.gentooexperimental.org/pkgcore-trac http://overlays.gentoo.org/proj/mysql/ http://overlays.gentoo.org/proj/java/ George -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Ideas for projects...
On Thu, Jan 11, 2007 at 04:04:31PM -0500, Chris Gianelloni wrote: Robin Johnson came up with a good example, which was genflags an application that was to gather information from the running system and spit out a customized set of C(XX)FLAGS for the user. I should clarify, that genflags was a short project based on requirements from Daniel Robbins. I wrote it in mid-2003. The old code (app-portage/genflags) is still in the tree, but has badly stagnated (not updated since GCC3.3, and it was before the widespread entry of amd64 machines). -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgphzRsY3KIsK.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Ideas for projects...
Chris Gianelloni wrote: Submit your ideas here, so we can discuss them. I will be choosing one idea that we think we can accomplish to test out the idea of Council-driven projects. Construction of a dynamic website for tracking kernel security issues. There are too many of them and too many kernels to do this through the normal GLSA process, and currently users are kept in the dark about fixed security issues. Tim had started developing a site for this (KISS) but it was never finished and had the large downside that it relies upon an operator duplicating lots of information from bugzilla and the ebuild tree into KISS. Such a system would be able to automatically pull a large proportion of the required information relatively easily. It would offer functionality to allow users to sign up for security announcements and fixes for their kernel(s) of choice, as well as feeding the same info into a mailing list for all kernels. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Ideas for projects...
I like the idea. Something really useful I could think of is *drums* the implementation of GLEP 42. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
RE: [gentoo-dev] [RFC] Ideas for projects...
K, so my account hasn't been retired yet, so I'm making this comment as a developer (at least until someone gets around to my retirement bug). :-) I really like blubb's idea here. Not just of implementing GLEP 42, but the idea of having the Council responsible for overseeing and assigning tasks for the implementation of ALL approved GLEPs. Maybe GLEP 42 could be the pilot. :-) Jason Huebel -Original Message- From: Simon Stelling [mailto:[EMAIL PROTECTED] Sent: Thursday, January 11, 2007 4:24 PM To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Ideas for projects... I like the idea. Something really useful I could think of is *drums* the implementation of GLEP 42. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Ideas for projects...
Simon Stelling wrote: I like the idea. Something really useful I could think of is *drums* the implementation of GLEP 42. GLEP 42 is almost fully implemented and is currently undergoing local testing (by me) to find the last of the obvious bugs. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Ideas for projects...
On 1/11/07, Chris Gianelloni [EMAIL PROTECTED] wrote: The Gentoo Council is looking for some ideas for some small projects that we could initiate that would help Gentoo. My idea would be to extend emaint to check package.keywords and package.use for obsolete flags, unnecessary atoms (like foo-1.2 in keywords when foo-1.3 is stable), atoms that don't match any current ebuild, and so on. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Ideas for projects...
On Friday 12 January 2007 05:43, Richard Fish wrote: My idea would be to extend emaint to check package.keywords and package.use for obsolete flags, unnecessary atoms (like foo-1.2 in keywords when foo-1.3 is stable), atoms that don't match any current ebuild, and so on. app-portage/eix already does a lot of this with --test-non-matching and --test-obsolete. -- Bo Andresen pgpxLeKmkecCN.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Ideas for projects...
On 1/11/07, Bo Ørsted Andresen [EMAIL PROTECTED] wrote: On Friday 12 January 2007 05:43, Richard Fish wrote: My idea would be to extend emaint to check package.keywords and package.use for obsolete flags, unnecessary atoms (like foo-1.2 in keywords when foo-1.3 is stable), atoms that don't match any current ebuild, and so on. app-portage/eix already does a lot of this... Sigh. I can't keep up with these changesnevermind :-( -Richard -- gentoo-dev@gentoo.org mailing list
