Re: [gentoo-dev] RFC: regular project updates
Flameeyes, blubb, dostrow - what about publishing your recent blog entries as the official news from your projects? WKR, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: regular project updates
Patrick Lauer wrote: > So - as GWN monkey - I'm offering my services as aggregator for project > updates. I'd rather see the project managers/bosses/dedicated_members doing that themselves. Fine example might be GDP updates which work quite well, IMHO. > Maybe someone from the doc project wants to help to get this > information put on the website so that it's visible? I'm not sure about what permissions are required to post to the mainpage, but if the respective people are sane enough, they could get them, imho. > I suggest project updates every 6 months (which roughly is the same > timeframe as releases) Would those updates be mandatory or just recommended? > Any feedback appreciated :-) Well, as I said, we (the GDP) are already doing that. I'm not sure if it's a good idea to make such updates compulsory, but I'm sure we should at least recommend them. Let's make a deal - one lollipop/cookie for one status report, paid from the foundation funds, okay? :-) Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: regular project updates
On Thu, 2006-01-05 at 17:00 +0100, Patrick Lauer wrote: > Hi all, > > as the debate about the future direction of Gentoo continues it's > getting more and more obvious to me that there's a lack of information > skewing the debate. It seems that while most devs (and users) have a > good idea what's happening in "their" projects it's quite difficult to > see what is happening in other projects. > > So - as GWN monkey - I'm offering my services as aggregator for project > updates. Maybe someone from the doc project wants to help to get this > information put on the website so that it's visible? > > I suggest project updates every 6 months (which roughly is the same > timeframe as releases) > Maybe this helps people get a "global vision" of where Gentoo is and > where it's going. > > Any feedback appreciated :-) Perhaps we could kill more then one bird with on stone. Once every X months, have all herds commit an ebuildish file containing the following to CVS, which would then be parsed and posted on g.o. --- begin --- Herd name: What we do: General vision of our herd Working on: what we are specificaly working on Lead(s): current lead(s) Dev list: list of active devs AT/HT list: list of active AT/HTs Herd Deps: Other Herds we _need_ in order to work properly simple example - x86 Herd (as it is currently called) depends on linux, complex - webapps depend on PHP, Perl, python, Ruby etc; apache; ?mysql Herd associates: People we work in parallel with. ie - all work in parallel - KDE and Gnome work in parallel Herd homepage: either a homepage or a wiki --- end --- all herds depend implicitly on the gentoo infrastructure. Now, If this file isn't commited to CVS on the interval, the herd becomes stale, and is marked as such. If the the herd is stale for interval*2, the herd would be considered dead. Issues this may address - inactive devs/testers - clearly defined scopes for all herds - some communication grevences (easily find a herds direction and projects) - easy to 'find' related herds After parsing, this info could be posted to g.o and easily browsed. An org-chart could be generated for easy reference by all. Have all groups in gentoo be considered a herd. Including council, gentoo-infra, portage, ReleaseEng and others I can't think of. With the dependency structure developed 'from the bottom up', the issue of where we are going is mitigated. Also this allows for any group to have their own objective and not conflict with each other. Anyone can release a livecd under the gentoo name, just add the herdname in the title. ie. gentoo-2006_hardened.0, or gentoo-2006_bin.0 or gentoo-2006_server.0. There would still be an 'official' gentoo release, but I would wrather see a 'default recommended' release. Because in all reality, there is a different release for each arch. This is by no means complete, just some thoughts that might work. cat flames > /dev/null; I'd wrather hear nothing. -- Lares Moreau <[EMAIL PROTECTED]> | LRU: 400755 http://counter.li.org lares/irc.freenode.net | Gentoo x86 Arch Tester | ::0 Alberta, Canada Public Key: 0D46BB6E @ subkeys.pgp.net | Encrypted Mail Preferred Key fingerprint = 0CA3 E40D F897 7709 3628 C5D4 7D94 483E 0D46 BB6E signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: regular project updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: | Funny enough... I was working on this and forgot to send it out. | | I was planning on posting it also on the Release Engineering page, but | need to turn it into GuideXML first. Might want to run it through spellcheck first. Saw at least 1 typo. Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvW8IXVaO67S1rtsRAuUxAJ4o6zv4fjRpbzcf0s8faNXnrncwXgCeIVmI rEJohkAVFsRS9DDGtQSSPj4= =xjbU -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: regular project updates
On Thu, 2006-01-05 at 17:00 +0100, Patrick Lauer wrote: > So - as GWN monkey - I'm offering my services as aggregator for project > updates. Maybe someone from the doc project wants to help to get this > information put on the website so that it's visible? Funny enough... I was working on this and forgot to send it out. I was planning on posting it also on the Release Engineering page, but need to turn it into GuideXML first. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux Status Report for Release Engineering: Jan 3rd 2006 This is a simple status report for Release Engineering. The basic premise of this report is to inform our users and developers where Release Engineering is currently and where we are going in the future. This includes coordination work between Release Engineering and other teams. 2005.1-r1: As you are all probably well aware by now, Release Engineering produced a 2005.1-r1 release based on the 2005.1 snapshot. This media refresh was designed to resolve a few major bugs with the 2005.1 release and help users install Gentoo more effectively. This release also introduced an amd64 Installer LiveCD image. Very few bugs have been filed about this media refresh, which is a good thing. However, there were many bugs from 2005.1 that we were unable to resolve due to wishing to base off the 2005.1 snapshot. These bugs will be resolved with 2006.0's release. 2006.0: We are currently in the Development/QA phase of the 2006.0 release. We are currently working out the initial internal release schedule to determine availability of specific Architecture Coordinators. The major goals of 2006.0 is to improve the Installer LiveCD for amd64/x86 and possibly introduce some new experimental CD images for further Gentoo Linux Installer development. Release Engineering, along with the architecture teams, has been working to simplify and standardize the profiles under default-linux. We hope in the future to make this even easier once multiple parent inheritance has been added to portage. This release will also introduce NPTL as the default for all supporting architectures. Legacy support for non-NPTL stages above stage1 will be dropped from all supporting architectures after this release. This means there will be a stage3 tarball for no-nptl systems released with this release on architectures still supporting 2.4 kernels, but there will not be newer tarballs made with later releases. Catalyst: We are hard at work on stabilizing catalyst for a 2.0 release, which we will use for building the 2006.0 release, along with all future releases. Catalyst 2.0 is a significant re-write of the core functionality fo catalyst to make it more modular and more maintainable, along with adding some much-needed features. We plan on having a full catalyst 2.0 release into stable by the end of Febrary. We have had quite a bit of help from various members of several architecture teams to improve support for some of the more esoteric architectures. Installer: The Gentoo Linux Installer project has been hard at work on the next version of the Gentoo Linux Installer, version 0.3, which will be released for x86 and amd64 along with the 2006.0 release media. This will also be the first version of the Installer to become an offcially released and supported version for an architecture, as x86 will be releasing a Minimal InstallCD and Installer LiveCD, replacing the Universal InstallCD/PackageCD combination for GRP. Future: The future for Release Engineering is actually quite simple. We hope to automate more of our processes by incorporating more and more into catalyst, to reduce the work load on the Architecture Coordinators and also to allow more of our projects to easily build release materials. We hope to eventually move to an InstallCD/LiveCD combination for manual installs and GRP on all architectures. Work is being focused on making these processes more architecture-neutral to allow for more standardization across architectures to give Gentoo releases a more uniform look and feel. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: regular project updates
On Thu, 2006-01-05 at 16:41 +, Ciaran McCreesh wrote: > On Thu, 5 Jan 2006 17:28:13 +0100 Grobian <[EMAIL PROTECTED]> wrote: > | I'm thinking of quite dull news, so absolutely not meant to be a > | publication like GWN, but just thingis like some commits on the > | portage sources that say to fix/implement X, a discussion on project > | ML Y working on Z. > > Would our users really like to read a lengthy discussion on the > intricacies of the changes made to versionator.eclass to improve > performance, or the way in which the ten zillion packages needed by > the new KDE/Gnome/Xorg release were keyworded for a particular arch, > or the design decisions made for vim-spell.eclass to avoid requiring > that our users have four gigs of RAM? I mean, it'd be pretty frickin' > boring... I think Fabian is targetting cross-dev communications there ... It'd be time-consuming but sounds interesting. There's lots of "unimportant" info, like ... say ... what fixes are in the new baselayout? Is gcc4 safe to use? ... Having all that in a central place (like planet.g.o, only moderated) might help - if there is enough support! Patrick -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: regular project updates
On 05-01-2006 16:41:12 +, Ciaran McCreesh wrote: > On Thu, 5 Jan 2006 17:28:13 +0100 Grobian <[EMAIL PROTECTED]> wrote: > | I'm thinking of quite dull news, so absolutely not meant to be a > | publication like GWN, but just thingis like some commits on the > | portage sources that say to fix/implement X, a discussion on project > | ML Y working on Z. > > Would our users really like to read a lengthy discussion on the > intricacies of the changes made to versionator.eclass to improve > performance, or the way in which the ten zillion packages needed by > the new KDE/Gnome/Xorg release were keyworded for a particular arch, > or the design decisions made for vim-spell.eclass to avoid requiring > that our users have four gigs of RAM? I mean, it'd be pretty frickin' > boring... Probably not, that's what I wrote that I really don't like it to be targetted (and sent to) users. I myself, on the other hand, *would* like to read that. -- Fabian Groffen Gentoo/Alt -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: regular project updates
On Thu, 5 Jan 2006 17:28:13 +0100 Grobian <[EMAIL PROTECTED]> wrote: | I'm thinking of quite dull news, so absolutely not meant to be a | publication like GWN, but just thingis like some commits on the | portage sources that say to fix/implement X, a discussion on project | ML Y working on Z. Would our users really like to read a lengthy discussion on the intricacies of the changes made to versionator.eclass to improve performance, or the way in which the ten zillion packages needed by the new KDE/Gnome/Xorg release were keyworded for a particular arch, or the design decisions made for vim-spell.eclass to avoid requiring that our users have four gigs of RAM? I mean, it'd be pretty frickin' boring... -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: regular project updates
On 05-01-2006 17:00:15 +0100, Patrick Lauer wrote: > So - as GWN monkey - I'm offering my services as aggregator for project > updates. Maybe someone from the doc project wants to help to get this > information put on the website so that it's visible? The following crossed my mind: what about a Developers release of the GWN? I see you guys scouring the planet, MLs and whatever more, but not all information there is user-friendly, or just a 'good idea' to tell the users about. I'd really like to see an aggregation of stuff from all kinds of sources (perhaps even including CVS/SVN commit messages) put into a monthly (or bi-weekly?) message sent to -dev for instance. It should just have some headliners for each project team, such that those who want be a bit aware of what happens in the whole of gentoo can read it, and take an active role when interested in some more information. I'm thinking of quite dull news, so absolutely not meant to be a publication like GWN, but just thingis like some commits on the portage sources that say to fix/implement X, a discussion on project ML Y working on Z. Also for instance that Flameeyes has been working on something with "--as-needed"; just what it is, and why, from planet. Perhaps even a short note that after +-150 commits the tree has been upgraded to XOrg-7_rc1 or something... that can be useful information, even though it does look like spam. This kind of information is all of the type background noise, hence it dull, but can be very important for those that are open to it. I would just be interested in such a thing, because I'd like to read some few lines per month on projects, but not whole MLs and every dev's Blog. Of course it's just shifting the problem of not wanting to read everything to someone else... but IMHO it does improve communication for those open to read the "Gentoo Developer Notes" (or something like that). Just a thought. No idea whether you really meant to do something like this. Would like you to do it though ;) -- Fabian Groffen Gentoo/Alt -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: regular project updates
Hi Patrick, On 1/5/06, Patrick Lauer <[EMAIL PROTECTED]> wrote: I suggest project updates every 6 months (which roughly is the sametimeframe as releases)Maybe this helps people get a "global vision" of where Gentoo is and where it's going. Didn't the new metastructure place requirements on projects for things like this? I haven't managed to track down a copy to check. Best regards, Stu
Re: [gentoo-dev] RFC: regular project updates
Patrick Lauer wrote: Hi all, as the debate about the future direction of Gentoo continues it's getting more and more obvious to me that there's a lack of information skewing the debate. It seems that while most devs (and users) have a good idea what's happening in "their" projects it's quite difficult to see what is happening in other projects. So - as GWN monkey - I'm offering my services as aggregator for project updates. Maybe someone from the doc project wants to help to get this information put on the website so that it's visible? I suggest project updates every 6 months (which roughly is the same timeframe as releases) Maybe this helps people get a "global vision" of where Gentoo is and where it's going. Any feedback appreciated :-) wkr, Patrick I would prefer quarterly, but anything is better than the present. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] RFC: regular project updates
Hi all, as the debate about the future direction of Gentoo continues it's getting more and more obvious to me that there's a lack of information skewing the debate. It seems that while most devs (and users) have a good idea what's happening in "their" projects it's quite difficult to see what is happening in other projects. So - as GWN monkey - I'm offering my services as aggregator for project updates. Maybe someone from the doc project wants to help to get this information put on the website so that it's visible? I suggest project updates every 6 months (which roughly is the same timeframe as releases) Maybe this helps people get a "global vision" of where Gentoo is and where it's going. Any feedback appreciated :-) wkr, Patrick -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
