Re: [gentoo-dev] Re: [RFC] Gentoo Wiki Project
On 09/04/10 18:24, Zeerak Mustafa Waseem wrote: Really? I understood it as the wiki being an all-purposes wiki, meaning users could (would and should) create articles on how to get some application running or how to get some setting working, and the developers will have their own section, so to speak, where they can collaborate on various projects where a wiki would be an asset. It seems to me from the discussion here on the list that it is to centralize documentation (- the official docs), so that gentoo can point to the wiki and say If it's not in our docs, maybe it's in the wiki. I may have mistaken the actual purpose of the wiki, but then by all means, correct me :-) It has no purpose. The official wiki currently has no rules and no mission statement. There's been no activity for 3 days. ...in which time the unofficial wiki got countless edits in many languages. And my server downloaded backups 3 times (because we have a public backup policy in place to ensure the content is never lost again - something some people seem to like ignoring (or are just ignorant of)). AllenJB
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 04/04/10 08:31, Joshua Saddler wrote: lots of stuff about what mediawiki supposedly can't do that is just completely untrue GuideXML may be better for the Handbook use case, with its ability to produce single page and multipage documents, but frankly I think that for the rest of the documentation, most of which only covers 1 or 2 pages, the ease of learning and editing mediawiki formats is far superior. (I wouldn't be surprised if there's a way to reproduce this single-page and multipage ability using inclusion on mediawiki) I keep hearing this line about GuideXML not being hard to learn, but if that's so true, why does Gentoo have so few developers contributing to the documentation? Why does the current system basically rely on a single developer tidying up and completing the documentation? I've tried getting my head around GuideXML a few times and I hate dealing with it. I much prefer to use the Gentoo Wiki, where I can just throw stuff up really quickly using a syntax I use in many other places and is well documented. This line about learning wiki syntax is so old, but here's my reply yet again: GuideXML is a non-tranferrable skill. Nowhere else in the entire world uses it. Even if you haven't edited a wiki anywhere else, chances are you probably will one day, and even if it's not mediawiki it'll probably use syntax that's similar to it in many ways. Syntax highlighting can easily be done with any of a number of plugins. I'm sure ebuild syntax could be added without a massive amount of pain. There are multiple ways to construct tables (wiki style, HTML and probably some others - almost certainly more available via plugins), some easier than others. And you can do styling either inline or in the site-wide stylesheets. Mediawiki has built-in intradoc linking to every heading, and in all the use cases I've seen this level is fine. Intradoc linking to individual letters^Wparas is just frankly way overboard (Does the Gentoo documentation even use it anywhere?). Wiki's may not be a magic bullet that'll solve all of Gentoo's problems, but the current system doesn't seem to be working well, so something needs to change, and I believe that a system that allows more people to contribute more easily, using a syntax that's already widely used so is either already known or an easily transferable skill is not a bad place to start. AllenJB
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 04/04/10 15:15, Dror Levin wrote: At first, I'd wish for things to be migrated from the unofficial wiki (if the license does not allow for copying, then re-writing it. Our users will do a lot of it, I'm sure). I'd wish to migrate a lot of things from the forums, after getting the authors permission if necessary. Maybe at some point I'd like the devmanual to be moved to the wiki (probably only editable by devs or a certain team, the specifics are not important right now). The quizzes can be put on the wiki. GLEP summaries in language users understand. Drafts for news items. The list goes on and on. Dror Levin I'd like to ask what you think in launching a site that simply clones an existing site is? Why take all the hard work the editors have put into their articles on the unofficial wiki and duplicate them on another site, creating TWO copies, both of which may be updated with different information. This is completely pointless. And as someone who has contributed a lot to the existing wiki, I don't care if it's official or not, but any site I find copying articles I've contributed to (and certainly the ones I wrote from scratch) will suffer all the wrath and abuse I can bring to it. An official wiki should not be used to duplicate the existing unofficial wiki (and I don't believe this is the intent of the developers who want one). It should be used to provide additional documentation on top of that provided by the existing wiki. AllenJB
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 04/04/10 15:47, Dror Levin wrote: Creating just another wiki is what's pointless. What I want is to deprecate all unofficial wikis (there are others besides gentoo-wiki.com) which were created simply because there never was an official one and creating chaos, then centralize everything in one official wiki, and build on top of that. Fix the historic mistake. Concentrating information from the forums and various wikis is just the first step. This should be the goal of all of us, yours as well. Who wants to run around all over the internet trying to find relevant information on various forums, wikis, blogs, etc. when an official wiki can remedy a big part of that, making it easier to find what you're searching for. Instead of being scattered around, we want everything in one place, that's how it can be made even better. Dror Levin The unofficial wiki may have been created because there wasn't an official one, but that doesn't mean it's any less of a community in its own right. Starting the official wiki by effectively ripping off others work and attempting to destroy existing user communities is NOT the right way to go about things, in my opinion (and losing the editing history of those articles in the process). You should first try to start your wiki/community and make it a community in its own right, rather than trying to steal/destroy/rip off existing communities. My personal goal is to continue to maintain an existing community full of useful documentation, already concentrated in one place. The unofficial wiki avoids duplication by pointing to existing documentation where ever possible. The search problem is already dealt with by Google, so that's no reason to go about ripping off other peoples work. With your aims in mind, I don't see the point in duplicating existing material, creating TWO places you have to check to see what's been updated. If an official wiki starts up and becomes a major documentation centre for user contributions, then I may consider moving my articles over, but until that time I currently intend to maintain them in place, with their complete history in tact. AllenJB
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 04/04/10 23:45, Zeerak Mustafa Waseem wrote: On Sun, Apr 04, 2010 at 04:13:19PM +0100, AllenJB wrote: The unofficial wiki may have been created because there wasn't an official one, but that doesn't mean it's any less of a community in its own right. Starting the official wiki by effectively ripping off others work and attempting to destroy existing user communities is NOT the right way to go about things, in my opinion (and losing the editing history of those articles in the process). You should first try to start your wiki/community and make it a community in its own right, rather than trying to steal/destroy/rip off existing communities. My personal goal is to continue to maintain an existing community full of useful documentation, already concentrated in one place. The unofficial wiki avoids duplication by pointing to existing documentation where ever possible. The search problem is already dealt with by Google, so that's no reason to go about ripping off other peoples work. With your aims in mind, I don't see the point in duplicating existing material, creating TWO places you have to check to see what's been updated. If an official wiki starts up and becomes a major documentation centre for user contributions, then I may consider moving my articles over, but until that time I currently intend to maintain them in place, with their complete history in tact. AllenJB You're absolutely right, it is a seperate community, and reading your replies I can't help but think Is the url really that important?. After all regardless of where the articles that you've written, you still would be the writer. You could still take part in the various discussions that may arise on the articles. The way I see it is that when the official wiki comes up, it will only be a question of time before the pages covered in the unofficial wiki are covered in the official one, particularly if it'll be mainly user-driven and people stop thinking about using the unofficial wiki, as there is a wiki and the answer isn't there. So when they find the answer, they add it. Personally I'd prefer to be part of the change rather than resisting it. I can understand reluctance to join a project you aren't certain will succeed, though. The way I see it, the official wiki has to earn my respect as a project. The unofficial wiki already has already been through this process. It's no different whether I'm trying a new piece of software or a new distro. It's not the URL that bothers me. I will, as I have said, quite happily move the articles I've written over, relicensing what I can if necessary, if/when I believe that the community would benefit. My problem is with the attitude of let's start the official wiki by taking the content of the unofficial wiki, regardless of the wishes of the active contributors of those articles. As another note, the license of gentoo-wiki doesn't stop anyone from copying but is incompatible with the license on the docs (was mentioned in a thread recently) so what is in gentoo-wiki won't be copied, but at best/worst rewritten. As an endnote, none of the above is meant as provocative or offensive, so in case it does offend; you have my apologies (it seems like a touchy subject for you so I thought I'd make it clear :-) ) Yes, the license may allow you to do this, and legally you might be able to do so under the license. But the legal license and ethics/morals involved in such action are different things. As I see it, the purpose of licensing my articles under an open license is to allow them to be contributed to and read without issues in the eventuality that the current wiki is lost for any reason (tho this is highly unlikely to happen again in the forseeable future as I and others now actively backup the content of the wiki, and the server maintainer has much better full backups in place) or the event that I am hit by a bus. If those who wish to run an official wiki can see no sensible starting point other than copying the content of the unofficial wiki, then I would bring into question what the point of an official wiki would be, and why should the Gentoo developers psend time and resources on duplicating the efforts of the community when there is a huge long list of other things they could do that would provide services to the community that are not already catered for. AllenJB
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 03/04/10 14:40, Dror Levin wrote: On Sat, Apr 3, 2010 at 16:19, Ben de Groot yng...@gentoo.org wrote: 2 - maintainers === Who is volunteering for maintaining the wiki? We need editors and moderators, people who look out for quality control and take care of spam removal. So let's get together a team. I'm sure if we ask on the forums we'll get some users interested as well. I volunteer. Spam shouldn't be that much of an issue if editing is restricted to registered users, but it is a good idea to have a team of moderators similar to the one that exists for the forums (of course users can take part of it as well as developers). Most of the spam on gentoo-wiki.com comes from registered accounts. Requiring registration does not stop most wiki spam. Very little of the spam comes in from unregistered editors. On gentoo-wiki.com we currently use a combination of anti-spam tools, which seems to work best. The main 2, from a day-to-day administration view are the url blacklist and manual removal of spam and associated accounts. You could require email authentication first, but I believe this is unlikely to reduce spam - creating a setup that automatically deals with account verification emails is trivial and throwaway accounts are too easy to get hold of. In addition I believe it would reduce the amount of positive contribution more than it reduces spam - I believe people often want to make quick, small corrections / additions and telling them to come back later is going to be the same as telling them go away. I would highly recommend using MediaWiki as, at least from my experience, it's the most prevalent of the wiki setups available. While this may bring some disadvantages (number of spam attempts (tho I'm nottotally convinced you'll get less than any other web form out there), etc), it also brings the advantages of being well developed with a wide variety of plugins, lots of wiki syntax guides / tutorials you can point users to and a wide userbase with existing knowledge of the syntax. AllenJB
Re: [gentoo-dev] X vs gtk USE flags
On 08/02/10 11:15, Nikos Chantziaras wrote: Hello. Please don't be too harsh if I got this wrong or if this looks like whining :P A lot of ebuilds seem to ignore the X USE flag and instead only have gtk, qt and the like. This should be declared absolutely wrong, IMHO. When a program provides a command-line tool and a GUI tool, and the GUI tool uses only one toolkit, then the USE flag should be X. gtk vs qt vs fltk etc should be used only in cases where a program can be built with either of those toolkits. When there's only one choice, then this doesn't make sense. Isn't this what the X USE flag is there for in the first place? Having a package where, say, Gtk is *not* optional having a gtk USE flag doesn't make sense. The X tool of that package is optional, but Gtk is not optional for the X tool. A Gnome user probably has X gtk -qt in make.conf, while a KDE user has X qt -gtk in hope to have programs that support both Gtk and Qt being built with the toolkit that is more native to his DE. When a package has a GUI tool that is able to only use one of those toolkits, people who have it disabled in make.conf will get no GUI tool at all even though they have X in their USE flags. I hope I was able to explain the problem (as I see it) correctly :P If people agree with me, it might be a good idea for maintainers of packages that behave like that to start using X as the USE flag that controls building of the packages GUI tools. I don't see that either system makes particularly more sense than the other. The only situation that comes immediately to mind is: Under the current system, if packages add or remove support for multiple toolkits, the changes are trivial, but under your system it would invoke shuffling use flags around (which could easily affect dependencies in other packages). It would also not be immediately clear which toolkits support has been added/removed under the proposed system (since a package would go from, for example, having use flags gtk kde to just X). Of course, even if your system was saner, the ultimate question is: Who's going to run through all the graphical packages and update all the use flags and dependencies? AllenJB
Re: [gentoo-dev] Re: X vs gtk USE flags
On 08/02/10 12:32, Nikos Chantziaras wrote: On 02/08/2010 01:39 PM, Samuli Suominen wrote: IMHO. USE=X is for controlling X.org dependencies, not for avoiding everything that deps on them, so I disagree. I was under the impression that USE flags are for enabling/disabling features, not for controlling deps. DEPEND and RDEPEND is, AFAIK, the way to control deps. Features influence dependencies. If you enable kde features the package will require kde dependencies. So use flags and dependencies are irrevocably linked. What Samuli is saying is that the X flag should be specifically for X (and not X-related, such as graphical libraries) features, while the kde and gtk use flags should remain in use as they are. This way when you see X as a use flag, you know it means enable X features and isn't likely to pull in anything but X libraries, if you see kde you know it means enable kde features and isn't likely to pull in anything but kde libraries, and so on. AllenJB
Re: [gentoo-dev] Re: X vs gtk USE flags
On 08/02/10 14:02, Nikos Chantziaras wrote: On 02/08/2010 03:41 PM, AllenJB wrote: On 08/02/10 12:32, Nikos Chantziaras wrote: On 02/08/2010 01:39 PM, Samuli Suominen wrote: IMHO. USE=X is for controlling X.org dependencies, not for avoiding everything that deps on them, so I disagree. I was under the impression that USE flags are for enabling/disabling features, not for controlling deps. DEPEND and RDEPEND is, AFAIK, the way to control deps. Features influence dependencies. If you enable kde features the package will require kde dependencies. So use flags and dependencies are irrevocably linked. What Samuli is saying is that the X flag should be specifically for X (and not X-related, such as graphical libraries) features, while the kde and gtk use flags should remain in use as they are. This way when you see X as a use flag, you know it means enable X features and isn't likely to pull in anything but X libraries, if you see kde you know it means enable kde features and isn't likely to pull in anything but kde libraries, and so on. So I guess what I was really proposing then was a gui USE flag :P Sorry about that, I didn't fully understand the meaning of the X flag. And what purpose would this flag server that's not already covered by using USE=X fltk qt gtk kde gnome (and possibly a couple of others I've forgotten about) - which are all already in the desktop profile, which the vast majority of people who don't care what toolkit they get will already be using anyway? The current system caters perfectly for both people who want to avoid specific toolkits and those who don't care what toolkits they use. AllenJB
Re: [gentoo-dev] Re: Lastrite (part 1): KDE3-only applications that won't build when KDE4 is installed
Dale wrote: lowly user again Is it possible to just mask and maybe keyword KDE 3? Maybe do a news item as to why it is being done? That way people like me that don't use overlays can still keep KDE 3.5 but it requires us to unmask them. It would be just like we have to do to use a new program that may have security issues or bugs but just in reverse. I mention because I have already downloaded Mandriva and plan to install it as a temporary fix if needed. I think I can suffer through Mandriva for a couple months while this gets sorted out. I'm planning to install the same for my brother. I would like to install Gentoo but he's not as geeky as me. back to my hole again Dale :-) :-) Give the developers a _good_ reason why overlays shouldn't be used in this case and I'm sure they'll consider it. But I don't think I refuse to use a standard tool of my chosen distro (for no good reason) is going to change their minds here. Overlays allow for a clear separation of fully supported and partially / unsupported packages in a manner that's clear, easy to use and maintain for both users and developers, with the added bonus of reducing disk usage and sync time for those who don't wish to use that set of packages. I fully welcome the way the sunsetting of KDE 3.5 is being done. It's clear and easy to follow. AllenJB
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
Maciej Mrozowski wrote: Hi there! Resulting from discussion during last Gentoo KDE team meeting taking place 22 Oct 2009 at #gentoo-meetings (summary fill be available soon), having Gentoo GNOME team representative, it's been decided to go ahead with splitting desktop profile to DE-specific subprofiles, to avoid bloat and provide desktop specific separation which should result in desktop subprofiles being actually practical. It's been proposed to: - keep 'desktop' profile but strip it from any desktop specific features and settings, making it default recommended choice for anyone using non-KDE and non-GNOME desktop environment, yet avoiding USE flags bloat. Any other DE is free to join and create own DE-specific subprofile if needed. - create 'KDE' (or 'kde') and 'GNOME' (or 'gnome') subprofiles within 'desktop' profile and move any desktop specific things there. This should in theory allow us to not add 'recommended' IUSE defaults to desktop specific packages, but keep those settings in profile - making profile effectively 'out of the box' solution for those who need it. If you have any comments, suggestions, important notices regarding this change, please keep discussion in gentoo-desktop mailing list. Thanks As a user and someone who provides support on IRC regularly, I think extra profiles in this manner is unnecessary complexity. At a guestimate there's going to be less than 10 USE flags difference between the profiles. (New) users already find it confusing what the differences between profiles are (the number of users I've seen using a developer profile because they do some programming, for example*) and frankly I think having these extra profiles will make some users think you can only have one of kde or gnome. Why are we talking about out of the box with a distro that doesn't even come with a pre-compile kernel? Or X installed? Gentoo isn't an out of the box distro. If disabling use flags is considered too confusing for users, maybe the entire system needs to be revised. * Why is the developer profile even shown on eselect profile? Wouldn't it be better to keep unsupported profiles off this list. Surely Gentoo devs can cope with setting their profile manually in favor of a little sanity preservation for the rest of us?
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
Samuli Suominen wrote: AllenJB wrote: * Why is the developer profile even shown on eselect profile? Wouldn't it be better to keep unsupported profiles off this list. Surely Gentoo devs can cope with setting their profile manually in favor of a little sanity preservation for the rest of us? It's not only for Gentoo developers, but for /Software/ developers in general. IMHO. General software developers should have the following features enabled? - test (all test suites) - stricter (horribly strict portage handling) - digest (ignore package digests) - cvs (not even documented in man make.conf) - sign (gpg key signing for cvs manifest commits) As well as the infamous I_KNOW_WHAT_I_AM_DOING=yes Certainly test, stricter and digest are all known to me to cause issues for anyone who doesn't understand what they do and why. AllenJB
[gentoo-dev] Anyone interested in maintaining the Gentoo Handbooks?
Hi all, The situation with the Gentoo Handbook is quite frankly getting beyond a joke for those of us donating our time to help users. I have tried to bring up the issues on the docs team list but pretty much get shot down and told everything is fine and dandy. For example, quoteth the Handbook at: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1chap=5 Most PC users should use the stage3-i686-2008.0.tar.bz2 stage3 archive. This results in users starting out with a version of portage that doesn't understand EAPI-2. Guess what happens next. I personally would happily donate my time to working on the docs, if only it didn't involve a markup language nobody else uses. I suggested a closed wiki for official documentation, but was again shot down saying that the existing team (who seem to be doing nothing) would need to reskill and that the server admins dislike wikis. Is it really satisfactory that the official install documentation results in a basically non-working install? AllenJB
Re: [gentoo-dev] Anyone interested in maintaining the Gentoo Handbooks?
Nirbheek Chauhan wrote: On Sat, Oct 3, 2009 at 8:24 PM, AllenJB gentoo-li...@allenjb.me.uk wrote: The situation with the Gentoo Handbook is quite frankly getting beyond a joke for those of us donating our time to help users. I have tried to bring up the issues on the docs team list but pretty much get shot down and told everything is fine and dandy. For example, quoteth the Handbook at: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1chap=5 Most PC users should use the stage3-i686-2008.0.tar.bz2 stage3 archive. This results in users starting out with a version of portage that doesn't understand EAPI-2. Guess what happens next. I personally would happily donate my time to working on the docs, if only it didn't involve a markup language nobody else uses. You're in luck, the Beacon project has perfected it's Django branch which is now nearly ready for deployment. I think this is a far better option than converting all of the existing XML docs into Wiki and alienating an entire team. What is the Beacon project? URL? A tried a quick bit of googling but came up with nothing useful. What entire team? Part of the problem is that there appears to be no one working on the docs to start with. There's been a bug open on the 2008.0 - autobuilds change open since February with, as far as I can tell, nothing at all done towards fixing the handbooks. ( http://bugs.gentoo.org/260403 ) The last comment on that bug by a docs team member basically says: All the doc they need is 'Boot CD, follow on-screen instruction. If it fails, file a bug for the release team'. Done. Now, can we all forget abouth them? Which I think is a very poor attitude for someone tasked with maintaining the documentation (and appears to totally ignore the fact that the abomination of an installer the GLI was has been long dead and buried, even when that comment was made). Just because you very rarely reinstall Gentoo, and once you've done it a few times it's easy to do off-by-heart, that doesn't mean it should be impossible for new users to ever install Gentoo for the first time. I believe the Gentoo Handbook is a great, essential guide for new Gentoo users - if only the install section actually worked! AllenJB
Re: [gentoo-dev] Anyone interested in maintaining the Gentoo Handbooks?
Joshua Saddler wrote: On Sat, 03 Oct 2009 15:54:31 +0100 AllenJB gentoo-li...@allenjb.me.uk wrote: I have tried to bring up the issues on the docs team list but pretty much get shot down and told everything is fine and dandy. Going to have to call bullshit on this one. Who told you that on the lists? Have you *seen* *any* of the posts *I've* made? Take a look back at the list for the last, oh, year's worth of posts from me. We know there's stuff to do. There just aren't enough people. I do what I can, but I'm but one man. As an example, quoteth one Joshua Saddler on 2009-07-19 on the -docs list: I dunno if new blood is needed . . . we have perfectly capable folks in the docs team. They've been around for a few (or more) years, and they've invested the time and trouble to write perfect GuideXML. The problem is getting them up *off* their asses to do the work. I personally would happily donate my time to working on the docs, if only it didn't involve a markup language nobody else uses. I suggested a closed wiki for official documentation, but was again shot down saying that the existing team (who seem to be doing nothing) would need to reskill and that the server admins dislike wikis. Who seem to be doing nothing. Thanks. Thanks for shitting all over my work for the last month/year/years. All the hours I spend each week (each day) even when I'm devaway maintaining docs in /doc/, /proj/, and our other www pages in /main/. Thanks for saying I do nothing. I know you're not aware of everything that's going on behind the scenes, but to make such a blanket statement is just uncalled for. I suggest you take a look at http://sources.gentoo.org/gentoo/xml/htdocs/ (doc/en/ and proj/en/) to see some commit history before making such an unkind statement. We're not totally dead. Not all of the team is inactive. I'm active. The translators are active. Our lead has been fielding the bugs as they come in. I have no intention of shitting all over anybodys work. My apologies if that was the interpretation. I'm simply escalating an issue I have raised before to somewhere I think it'll get more attention. Maybe you're not totally dead, but my criteria for activity has been the multiple bugs I've been sitting on and the number of times I'm having to tell new users the handbook is wrong, ignore it and follow my instructions in this case or oh dear! You seem to have installed a version of Portage so ancient that 99% of our package tree can't be installed (or words to that effect) - mostly to do with the lack of up-to-date handbooks, which as per my original post is now becoming a dire situation, in my opinion. The problem with the English side of the docs is that I'm basically the only person doing anything. That means that while I can *sorta* keep up with the regular influx of non-handbook doc bugs, I can't do the entire handbook revamp on my own.* * Actually, I could, but some of the changes I have in mind are so far-reaching that I'd prefer not to go over the head of my team lead and instead stick to our existing policies rather than start breaking things left and right. And you still want to claim you don't need new blood? For some odd reason I seem to be hearing two different things from the same person. If the rest of the team is dead, why not escalate the issue to, say the -dev list. At least from what you've said in your most recent post you seem to think _something_ does need to be done about the current situation. AllenJB
Re: [gentoo-dev] Stabilization of Python 3.1
Dirkjan Ochtman wrote: On Sat, Sep 19, 2009 at 19:06, Alex Legler a...@gentoo.org wrote: What is the point of stabilizing it if users shouldn't use it as main interpreter? Just leave it in ~arch until it can be safely used. Making it easily available so that people can port stuff, so that the entire world may be able to use it as their main interpreter sooner? Seriously, it's out there, there's no reason to keep it from stable. Just prevent people from making python invoke 3.x and everything will be fine. Cheers, Dirkjan Yes, there is a very good reason: The sanity of the users and those who support them. As a user who has spent a lot of time on IRC and the forums supporting other users, I think I can safely say that stabilizing a version of python which is not supported by portage will end up in a nightmare scenario. At the very least portage, python-updater and eselect, if not the majority of the commonly used tools (whichever of gentoolkit, portage-utils, eix, etc use python), should support python 3.1 before it goes stable. Everything would be fine if all the users read news items, forums, mailing lists and web pages - but they don't. It will get missed by many many users - too many for something that breaks portage, in my opinion. I would suggest the developers keep python 3.1 out of stable until it is supported by portage, puthon-updater and eselect at minimum (ie. you can easily revert to 2.6). While writing this an alternative solution has occurred to me: Make sure portage dependencies are correct so that python doesn't get dep-cleaned (a brief check of the portage 2.1.6.7 ebuild makes it look like this currently isn't the case - surely this should've been done as soon as it was known portage didn't support python 3!) and perhaps add a block to eselect so that python-3.1 can't be selected as the system python interpreter until portage supports it. AllenJB
Re: [gentoo-dev] Stabilization of Python 3.1
Alex Legler wrote: On Sat, 19 Sep 2009 19:09:38 +0200, Dirkjan Ochtman d...@gentoo.org wrote: Seriously, it's out there, there's no reason to keep it from stable. Just prevent people from making python invoke 3.x and everything will be fine. Yeah, right, let's install it on all those stable machines, but then not use it. Way to go! Alex Surely this isn't an issue: If the dependencies on packages are correct, surely this shouldn't happen? If the dependencies aren't correct, maybe checking and correcting them for every package that needs python should be a requirement for stabilization. AllenJB
Re: [gentoo-dev] New 10.0 profiles are in repository
Josh Saddler wrote: Mart Raudsepp wrote: I wanted to work at some point on splitting out gnome and kde profiles to separate ones. Perhaps desktop profile could be a generic universal one with USE flags enabled that rox/lxde/fluxbox and so on would like as well, and then gnome adds its stuff, and kde adds its own stuff. Or desktop could be one that enabled both GNOME and KDE stuff as now, by multi-inheriting both gnome and kde profiles. Or perhaps both a lowest common denominator desktop-base profile and a big desktop one enabling everything... What could be nice is if users could select multiple profiles. They first choose the desktop profile, which has lots of basic stuff that's DE/WM-agnostic. They could then select another profile that adds e.g. Gnome stuff, like you suggested. I suppose the potential problem here (besides coding support for more than one profile) is making sure that the selected profile's USE flags (etc.) don't conflict with other selected profiles. Profile authors would have to be pretty aware of what other profiles contain, and/or the package manager would have to have some heavy duty resolver. One could just avoid the whole multiple-profiles-selected thing by cloning bits of one profile (like a minimal agnostic desktop), then adding your own USE flags, and calling it the Gnome profile, but this introduces lots of code duplication. Many new users seem to have trouble grasping how profiles work in their current, relatively simple, format. I think adding complexity to this is only going to make things worse. This will also take a step back in that users will have to be exposed to the raw profile locations within the tree. We've only just got rid of this (as soon as the handbooks actually get updated, anyway) now that eselect profile is available in stage3. Getting profile paths wrong was, in my experience, one of the most common problems new users had. I believe that if you want to successfully implement this idea, you will have to create a tool (or modify eselect profile) to allow this to be done without exposing users to the raw paths. AllenJB
Re: [gentoo-dev] 2009.0 profiles
Ben de Groot wrote: We've been living with the 2008.0 profiles for a while now. I think the time has come for 2009.0 profiles so we can have some updates. Also, there are plans for an anniversary release of our LiveCD, so I think the time is right to start working on a new set of profiles. One reason I bring this up is that the Qt team would like to see the qt3 useflag dropped from desktop profiles, and I'm sure others have some suggestions as well. Haven't the devs just been making changes directly to the profiles since at least autobuilds came about? I'm sure I've seen some global use flag changes relatively recently. What is the actual policy on this? It seems kind of pointless to me to tie global use flag changes to a release cycle when per-package use flags are now changed on a whim (with EAPI-2 style default use flags) Traditionally, the release team has taken care of this, as the profiles were tied to releases of install media and stage3 archives. Now that we have the autobuilds, this relationship isn't as self-evident anymore, which is why I address the wider dev community. With the introduction of autobuilds, would it be a good idea to rename the profiles so that they don't have the date association? This does seem to confuse a number of new users who will appear asking where the 2009 profiles are. What does Gentoo use versioned profiles for now that use flag changes, in particular per-package use flags, don't seem to be linked at all. What should they be used for? Is this going to be another thing that isn't updated in the Handbooks? Please share your ideas on this. Cheers, Ben
Re: [gentoo-dev] About time to unify cdda and cdaudio USE flags and make the remaining one global?
Gilles Dartiguelongue wrote: Le lundi 06 juillet 2009 à 14:18 -0700, Josh Saddler a écrit : Sebastian Pipping wrote: Rémi Cardona wrote: And now for some bikeshedding fun, which flag are we going to keep? ;) My vote would be for cdaudio as that - is more general (including analog playback) - is more user friendly but let those decide who implement it. I'm also in favor of cdaudio: it's a bit more self-explanatory. I also think it's better to have such a generic description for apps that use libcdio/cdparanoia/cddb combinations, such as the package I maintain, media-sound/decibel-audio-player. As I said in [1], cdda has a precise meaning and cdaudio is all but a blurry alternative. Also your examples are bad because they are blurring the definition even more. Are we talking audio cdrom ripping, audio cd data retrieving or simple audio cd playing support ? [1] https://bugs.gentoo.org/show_bug.cgi?id=274818#c1 While cdda might be the correct technical term, how many users will actually recognize what it means? Personally I think cdaudio (or, to throw in another alternative audiocd) would be recognized by most users as support for playing audio cd's (as in the things you buy in the shops and stick into any stereo made in the last 15+ years). Are users really going to want to fine-tune between just playing or also being able to rip/write audio cd's? A quick check with quse -D cdaudio cdda (below) shows that the current use flag descriptions, as far as I read them, don't make any discrepancy between these definitions anyway - they all basically say play audio cd's to me (with some additionally enabling cddb, which as a side note already has a global use flag) Current use flag descriptions: local:cdaudio:media-plugins/audacious-plugins: Enable cd audio playback support local:cdaudio:media-sound/amarok: Enable cdaudio functionality local:cdaudio:media-sound/decibel-audio-player: Adds support for CD audio playback and lookups via CDDB local:cdaudio:media-sound/mpfc: Enable cd audio playback support local:cdaudio:media-sound/picard: Enable support for CD Index Lookups. local:cdda:gnome-base/gvfs: Enables Compact Disc Digital Audio (standard audio CDs) support local:cdda:media-sound/aqualung: Enables libcdda cd audio playback support local:cdda:media-video/vlc: Enables audio CD and VCD playback support. So ultimately, this isn't even bike shedding in my opinion. There's only one color to paint with anyway. AllenJB
Re: [gentoo-dev] Exim and Sendmail need a maintainer
Fabian Groffen wrote: On 24-06-2009 13:51:37 +, Torsten Veller wrote: | mail-mta/exim. I'm looking for users that want to help maintaining Exim. Especially if you feel like becoming a Gentoo developer at some time, contact me directly. I recommend you post this to planet, the forums, maybe the -user mailing list and Gentoo's Newsletter... oh wait! Maybe not the newsletter then. =P It might be useful to include a summary of what you expect the users to do, what knowledge they need and what help is available (Don't forget that what's obvious to you may not be obvious to them!) More than 2 users might actually see it then =P AllenJB
[gentoo-dev] Please use eselect news items!
Hi all, As a user, I'd like to encourage developers to make use of news items (eselect news) for important changes. I find them much more noticeable than elog messages (which, while I have set them up so they get emailed to me, I admit I don't always read). I think they're also easier to go back and re-read later (not everyone knows how to dig out old elog messages). 2 recent changes I would suggest having news items for are the libpcre .la files issue, because it often doesn't get noticed until later when builds fail, and the masking of the kdeprefix use flag as this is a fairly major change and I think it's useful for users to know why these changes are being made. Another case is that prior to it's masking, the kdeprefix use flag was deprecated, with only an elog message on every kde package to notify users, resulting in users who have their elog messages emailed to them receiving a very large number of emails all with the same content - I would also suggest news items in such cases in future. Thanks to all the developers who worked to bring us this long awaited feature - I think it's brilliant, so please use it! AllenJB
[gentoo-dev] Versioned use flags and preferencing (eg. qt3 / qt4 on same package)
Hi all, https://bugs.gentoo.org/show_bug.cgi?id=274197 The above bug brings up 2 issues: First, hplip says one thing, but does another with qt3 and qt4 use-based dependencies. This is obviously a bug that needs to be fixed. As a user, the second issue it brings up for me is what is the policy applied to the rest of the tree with regards to packages that can use one or more of several options (eg. qt3 or qt4) and have both / all flags specified? Do packages that can use both/all always use both/all? When both/all flags are specified, which one takes preferences? Always the newer? Where is this documented (both from a users point of view, and from a policy point of view)? If hplip the only package that can only use one of qt3/qt4 and as such that's why it's the only one with local use flag descriptions, or are there more which just haven't been documented? AllenJB
Re: [gentoo-dev] New app-eselect category?
Fabian Groffen wrote: On 26-05-2009 09:04:46 +0200, Ulrich Mueller wrote: As of today, app-admin contains 179 packages. We could move the 27 eselect-* packages to a new app-eselect category (eselect itself would stay in app-admin). Opinions? I hate package moves, so is it really *really* necessary? I have to agree. app-admin is hardly among the largest categories. Perhaps we should consider splitting up the 400 odd packages in kde-base (kde-graphics, kde-admin, kde-games, etc) =P As for app-admin-eselect, I'd favor tags over increasing the category levels, tho I'm not convinced either is necessary at the current time (tho tags might make searching easier, in some ways). AllenJB
Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support
lx...@sabayonlinux.org wrote: On Mon, May 25, 2009 at 3:43 PM, Alex Legler a...@gentoo.org wrote: On So, 2009-05-24 at 20:04 +0200, lx...@sabayonlinux.org wrote: [...] app-admin/equo (sabayon overlay -- Entropy Framework client) supports the postfix @repository to let users force the installation of a package from a specific repository. @ is used by Portage for sets. Paludis has been using ::repo for repo dependencies for years. Why not go with the established syntax? I wrote postfix not prefix. Sets use @ prefix. Your @ is still a prefix for the repository name. Yeah but emerge @overlay would be obviously illegal. So your argument is a bit pointless ;) For usability's sake, please don't do this. I can imagine users getting confused over the different meanings of the @ sign. I do not want to trigger a discussion like the one PHP had when choosing namespace separators, but we got the :: established in Paludis and Paludis is used by way more Gentoo people than equo. :: C++/PHP/whatever separator has nothing to do with the purpose of @overlay. Personally I think the PHP namespace syntax issue is a very good analogy. There's an established syntax, even if it's not a written standard, already used in a very similar situation, and that should be taken into account. Paludis is not a Gentoo project and doesn't follow Gentoo features validation rules. So is Entropy. If Paludis has its own syntax it doesn't automatically mean that Gentoo Portage *has to* follow it. I prefer a more democratic way = discussing here. As far as I can see, a discussion is happening. You started a discussion here and others mentioned that there is a specific syntax already used for this by a very similar application. You appear to be the only one who's arguing against that syntax. As a user, I have to agree that using @ for multiple purposes, even if it can't be applied to the same purposes in different locations, is potentially confusing, even if not just plain silly. As a side note, I think I've read somewhere that it may in the future be possible to specify sets in package.* (which I assume would be done using the @set-name syntax), but can't remember where off-hand. This may have just been a suggestion, but if it ever is implemented, it would surely add to the confusion. AllenJB So it only seems logical to me to use the wider-known and at the same time ambiguity-free operator. Alex
Re: [gentoo-dev] RFC: Gentoo Support Everywhere
Jesús Guerrero wrote: Hello, This is a request for comments on a new project, namely Gentoo Support Everywhere. http://www.gentoo.org/proj/en/gse/ The web page doesn't really explain all the background needed to understand why would anyone want to start such a project. However this forum thread might be more clarifying: http://forums.gentoo.org/viewtopic-t-762914.html The initial aim is to provide some support to these lost souls that wander around the LQ forums, and to create a Gentoo subforum at LQ like many other distros do. However, eventually the support might be extended to other places if there's a need and enough human power to do so. Comments welcome, and thanks for reading. After reading everything so far, basically as far as I can see this project exists solely to provide a capacity for an official presence on LinuxQuestions (and perhaps other sites later). Of the current membership it appears to be taking up no time. However, is an entire standalone project for this necessary? Could this not just be coordinated as a task of userrel (or perhaps forum moderators, as suggested earlier)? What purpose does having a standalone project have over doing this within an existing project? Specifically in relation to the LQ sub-forum, will the members of the project be moderating that sub-forum? Or is their task purely to help there and moderation is left to the LQ moderators? How will you ensure that an official presence is maintained in the long run? While it's all well and good to say that the current members are spending their time there anyway, but what happens in 3+ years time when they move on. As I see it Gentoo is left with a (semi-)official sub-forum that it created but no longer supports - How will this reflect on Gentoo as a whole? Will you be intending to recruit some sort of official helpers (who are probably already active on these forums)? Would they become members of the project (and thus Gentoo Staffers/Developers)? What privileges would these project members have within the Gentoo Development sphere? AllenJB
Re: [gentoo-dev] RFC: Gentoo Support Everywhere
Could someone who CAN see the forum thread please post the content to the list so that everyone can see it please? (Alternatively, perhaps post how to get to it from forums.gentoo.org manually) AllenJB
Re: [gentoo-dev] Re: RFC: Gentoo Support Everywhere
Jesús Guerrero wrote: On Wed, May 20, 2009 00:40, Duncan wrote: Jesús Guerrero i92gu...@terra.es posted http://forums.gentoo.org/viewtopic-t-762914.html I've checked it lots of times, and it's there. It's in the Moderators subforum, and it's near to the top of the list on that subforum so if you can access that subforum you shouldn't have a problem finding it, since linuxquestions is in the title. Well there's the problem. Why have you chosen to put it in a closed forum? Why not put it in, for example, Gentoo Chat, where everyone can see it? Stop posting it works for me and post something that will definitely work for everyone please. AllenJB
Re: [gentoo-dev] Re: Can we stop wasting time and bandwidth? (was: The fallacies of GLEP55)
Nirbheek Chauhan wrote: On Sat, May 16, 2009 at 4:48 PM, Ben de Groot yng...@gentoo.org wrote: Nirbheek Chauhan wrote: The statistics are irrelevant. So why do you bring them up? That's the question you should ask Duncan. Not me. I provided statistics to highlight and provide dramatic effect. People who prefer to discuss them and make it the primary (and only) point of reply should reconsider their tactics. Sorry, but what? You post things to a discussion on a mailing list and expect people not to discuss them? Then tell those people that THEY are the ones who should reconsider their tactics? This stuff does not need to be resolved, put to rest, approved, disapproved, or whatever! It needs to be kicked out till we can get *BASIC* stuff fixed. I agree, but apparently council thinks it's worth their time. But I disagree on the maintainer-wanted thread. It's not that important an issue. We have Sunrise already, so let's try to improve that. Alright, so you say it's not that important. Then bring things up that *are* that important. Then we can solve those instead. While I disagree with the maintainer-wanted project idea itself, the fact that it has appeared does mean people are thinking about these things and the thread has brought up discussion on what is wrong with Gentoo and how it can be fixed. These are good things. While the original idea may not be implemented, the discussion it has brought about will hopefully push things a little further in the right direction. AllenJB
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
that better resembles the project setup so that individual projects can more easily find queries that are likely to affect them? AllenJB
Re: [gentoo-dev] Retiring
George Prowse wrote: Peter Faraday Weller wrote: Hi Thanks, welp Sad to hear it mate. As the person who did your first install for you (i think) I think you will be missed. I am quite surprised about what you said about the state of things because i've got the distinct impression from others that Gentoo has been improving in the past 12 months. About the lack of the developers, something I proposed about 3 years ago might be applicable: has Gentoo ever thought about doing a Dev Day in much the same way as the Bug Days? Advertise a day where people can come and have a chat with developers and get coached because there is a vast amount of people and knowledge out there and I never see anything about Gentoo wanting people. If you book them, they will come. G In my opinion, such a drive wouldn't work. I've said it before in previous posts to the Gentoo -devel and -project lists, as well as my blog posts[0]: I think Gentoo needs to improve the organisation of the projects. I know it takes developer time to update project pages and do things like maintaining the developers wanted pages, but I think that Gentoo would see this returned in a higher number of competent developers. One of the biggest problems I have as someone considering becoming a developer is following what's going on and working out where I could make contributions that are both something I would enjoy doing and would be useful for current milestones (eg. autobuilds handbooks or improving / stabilizing KDE4) that are being worked on. [0] http://allenjb.me.uk/category/linux/gentoo On a related note, I thought the recent email from the Prefix project to the -devel list was excellent - it's exactly the sort of thing I would hope to find on a projects page on gentoo.org. It contains a detailed explanation of the project, its purpose, current state and aims and includes a roadmap so that (potential) contributors can easily see where they can help out in a way that will be considered useful by the development team. I would also like to see some less secrecy for things that are going on. For example, I know that the newsletter team are currently working on a new setup for the newsletter. While I somewhat understand some of the reasons that the developers involved have chosen to not give out information on this project, I question the overall value in keeping such projects secret in this manner. A project page with the current progress and a roadmap of the project on would not only keep everyone informed, but might encourage contributions (in the form of solving any specific problems the developers are having, for example, or in the case of the newsletter, preparing content to contribute). I've also spoken before on the bus factor, which I believe comes into play here. As far as I know only one or two developers are working on the project and if they were to disappear for a length of time for any reason, (virtually) all current knowledge of the project, its progress and its code / setup would be lost. This leads me on to another issue I have with Gentoo development, which I believe is related, and that is the organisation of the source code repositories. As far as I can see there appears to be no formal organisational scheme to this at all, which can make it really hard to find things. Ideally, I would like to see a scheme that generally goes something like: /project/subproject/task. So, for example, you could find all the docs under /documentation and all the newsletter content under /pr/newsletter. (On a sidenote, the SVN repos seem a little better on this than the CVS repos layout, but it's still not as clear as I think it could be) As always, I realize this would take time to change, but I (again) think there's a good chance that it would improve contributions (on the basis that potential contributors are more likely to actually contribute if they can find what they want to work on easily). AllenJB
Re: [gentoo-dev] RFC: Deprecating EAPI0
Patrick Lauer wrote: Hi all, with the discussion about EAPI3 we have now 4 (or 7, depending on how you count them ;) ) EAPIs available or almost available. This is getting quite confusing. To make our lives easier I would suggest deprecating EAPI0 and migrating existing ebuilds over some time to EAPI1 or higher until EAPI0 can be obsoleted at some point in the future. I would set the start of deprecation warnings about 3 months from now and the obsoletion quite a time later, maybe 12 months from now, when a sufficient amount of ebuilds has been migrated. Deprecating EAPI1 at the same time would reduce the amount of EAPIs we have to think about, but since it has some changes like adding src_prepare migration would not be as trivial. So I'd prefer keeping it around a bit longer. Comments? Patrick While there definitely arguments for deprecating EAPIs, I would suggest caution. A low number of active EAPIs can make life easier for developers, but it can also make life harder for some users. There are still users coming to the forums upgrading systems which only understand EAPI 0. I accept that Gentoo is certainly a relatively fast moving distro, but I think that developers also do need to consider users who have systems that are currently just working and may not upgrade often (once a year or even less). As such, I would suggest that forcing a move to the most recent stable EAPI is possibly unwise. I believe that forcing EAPIs to move forward at too quick a pace will cause more issues for these users. An answer to this could be to set a standard for the minimum time between upgrades - for example, 1 year - and ensure that users with anything that old can atleast upgrade portage and its dependencies to the minimum required versions without major issues. I understand that this may cause extra work in some respects, but if such a standard is set and documented then it will help users (admins) by giving them a set frequency at which they must upgrade at least the package manager, if not @system. Secondly, it was suggested that a project to upgrade all ebuilds in the tree from EAPI 0 could bring new developers, offering KDE4 as an example. I would offer caution on this assumption. KDE4 was not simply about upgrading ebuilds, but about users (contributors) and developers being able to install and test packages they wanted to install and test. I can not realistically see such an effort being asserted in the name of simply deprecating EAPIs. Yes, breakage occurred, but this was as far as I can see a complete rewrite of the KDE packaging from scratch. As such I would suggest that a certain level of breakage was to be expected. I would also suggest that the speed at which bugs are being fixed may be more of an indicator of lack of man power than anything else, and that the situation could be improved by looking at expending more effort on encouraging contributions and ultimately recruiting developers. I realize that getting people to expend effort on non-coding work can be difficult, but I think that ultimately the effort expended will be repaid in terms of extra contributions. In general, I would have to agree with those who believe there are currently better ways to expend effort within Gentoo. As such I would suggest that at most, EAPI deprecation only applies to new packages and version bumps. AllenJB
Re: [gentoo-dev] devs on IRC (was :Regen2 ( was QA Overlay Layout support ))
Donnie Berkholz wrote: On 19:06 Wed 11 Mar , Thilo Bangert wrote: the presumption seems to be, that as a dev one has to be available via IRC. it has long been my feeling that Gentoo as a project could realize more of its potential by better integrating people who dont do IRC. I think IRC helps to build a more tightly knit community and, because of this, is very important to Gentoo. The less close we are as a community, the more free we feel to be hostile because we don't see the folks on the other end of the big tube as real people. It's much like a technique that militaries use during wars to de-personalize the enemy, except with the Internet, we start that way and have to apply effort to grow closer. While it may be tight nit, there's the danger that it's so tight no one else can get in, so to speak. I don't think anyone's saying anything like no more IRC. What I at least am advocating is that what goes on on IRC gets summarized somewhere in addition. As I said before, this not only helps keep a log of what goes on for future generations, but also allows others (users and devs who don't have time to follow everything) to look in and follow what the devs are doing more easily. I think that this would ultimately help make Gentoo development more visible and more accessible, ultimately leading to an increased conversion of users to contributors, if not users to devs. AllenJB
Re: [gentoo-dev] devs on IRC (was :Regen2 ( was QA Overlay Layout support ))
Steev Klimaszewski wrote: memoserv Did you not read a single word of what I just said? memoserv only allows 1-1 communication. I'm talking about methods which allow for 1:many or many:many. memoserv also doesn't solve the bus issue or really provide any permanent record of communication (AFAIK there's no SLA on memoserv, which means if Freeserve decides to delete all your memos tomorrow, they are gone for good). Websites and mailing lists don't have these issues because they get archived and mirrored everywhere (gmane, google, archive.org) - a fact which made itself very apparent when Gentoo Wiki went down last year (where virtually all the old content was recovered from google cache and mirrored, as well as being available 6 months later on archive.org). Stops before he repeats even more of what he just said AllenJB
Re: [gentoo-dev] devs on IRC (was :Regen2 ( was QA Overlay Layout support ))
Markos Chandras wrote: On Tuesday 10 March 2009 14:15:36 Thilo Bangert wrote: Bugs aren't a good way to keep in touch with developers, that's what irc is for. while i dont necessarily think, that bugzi is the best way to stay in contact with me, it surely is a better way than IRC - on which i am close to never. the presumption seems to be, that as a dev one has to be available via IRC. it has long been my feeling that Gentoo as a project could realize more of its potential by better integrating people who dont do IRC. kind regards Thilo To be honest , I don't agree with that. Being around on irc is quite helpful to get direct feedback from users and fix bugs before they hit more users. This is a good way to reduce the amount of bugs that hit bugzilla. While IRC is undoubtedly a useful communication medium, it is pretty much a here and now thing. I believe that Gentoo would benefit quite a lot if teams started using more permanent forms of communication such as blogs, wikis or websites. Not only would this allow the current set of developers within a team to know what one another are up to and what needs to be done, but it would also allow those who are not so intimately involved (both other devs, contributors and users) to keep up to date and contribute as well as leaving something for future developers to be able to look back on and see what options / improvements / etc were considered / done in the past. I recently wrote a blog post that went somewhat along these lines: http://allenjb.me.uk/blog/why-only-think-about-projects-for-gsoc As someone who's very interested in getting involved in Gentoo Development, I often find it hard to gather information on what projects / people are up to, what's currently going on and what the plans for the future are. AllenJB
Re: [gentoo-dev] devs on IRC (was :Regen2 ( was QA Overlay Layout support ))
AllenJB wrote: Markos Chandras wrote: On Tuesday 10 March 2009 14:15:36 Thilo Bangert wrote: Bugs aren't a good way to keep in touch with developers, that's what irc is for. while i dont necessarily think, that bugzi is the best way to stay in contact with me, it surely is a better way than IRC - on which i am close to never. the presumption seems to be, that as a dev one has to be available via IRC. it has long been my feeling that Gentoo as a project could realize more of its potential by better integrating people who dont do IRC. kind regards Thilo To be honest , I don't agree with that. Being around on irc is quite helpful to get direct feedback from users and fix bugs before they hit more users. This is a good way to reduce the amount of bugs that hit bugzilla. While IRC is undoubtedly a useful communication medium, it is pretty much a here and now thing. I believe that Gentoo would benefit quite a lot if teams started using more permanent forms of communication such as blogs, wikis or websites. Not only would this allow the current set of developers within a team to know what one another are up to and what needs to be done, but it would also allow those who are not so intimately involved (both other devs, contributors and users) to keep up to date and contribute as well as leaving something for future developers to be able to look back on and see what options / improvements / etc were considered / done in the past. I recently wrote a blog post that went somewhat along these lines: http://allenjb.me.uk/blog/why-only-think-about-projects-for-gsoc As someone who's very interested in getting involved in Gentoo Development, I often find it hard to gather information on what projects / people are up to, what's currently going on and what the plans for the future are. AllenJB Just wanted to quickly add mailing lists to the explicitly mentioned venues for improved communication. As a quick example, I'm interested in the PR / Newsletter side of Gentoo, but I find it very hard to keep up-to-date. I recently learned that there's a new blog-like version of the newsletter in development but I've heard nothing else about it and searching hasn't turned up anything. While I am on the gmn irc channel, I don't have time to read through all the backlogs for relvent information. I am also on the gentoo-pr mailing list (among many others, as well as checking on the lists via gmane) and it's basically completely silent. I'm currently waiting to catch one of two devs who might be able to give me more information on IRC. To all eyes looking from the outside in, unless they happen across the one forum thread I did, the newsletter is dead and nothing is being done about it, which gives a poor view of the state of affairs within Gentoo Development. To take the bus analogy to this, if these 2 developers are hit by a bus, then who knows what's currently going on with the newsletter and where all the resources are? I have said it before and I will say it again, yes the newsletter may be a current weak point for Gentoo, but it's a very obvious one because it's the one that's visible to everyone in the community. I still think my points are valid for any area of Gentoo development tho. AllenJB
Re: [gentoo-dev] new categories: (was: Last Rites: games-puzzle/ksudoku)
Norberto Bensa wrote: Excuse me for thread hijack. Would it make sense to add (for example): kde-games gnome-games ? Or the other way around. Move kde-base/kmail to mail-client/kmail ? What about both ways using symlinks: kde-games/ksudoku - games-puzzle/ksudoku ? Thanks, Norberto Personally I prefer all the official kde package in kde-base - it allows me to quickly know that this given package is part of the official KDE package set. I don't see a need for kde-games - it's pretty clear from the descriptions which of the kde-base packages are games, and for the reason stated above I don't like the idea of mixing official and unofficial packages. I suspect symlinks are likely to cause issues (what happens if you try to install both kde-games/ksudoku and games-puzzle/ksudoku?) and as far as I know are never used in the package tree. Package moves like this are occasionally going to happen, no matter how you structure the repository. The only real question here is whether this is a package move (in which case, I believe, portage goes through and updates /etc/portage/package.*, world and possibly custom sets contents automatically) or just a package mask (in which case it's up to the user to do all those updates) AllenJB
Re: [gentoo-dev] PR Project Activity Issues
Alec Warner wrote: On Mon, Jan 26, 2009 at 1:30 PM, AllenJB gentoo-li...@allenjb.me.uk wrote: Hi all, The Gentoo PR Project currently appears to be having difficulties with keeping up, both with the newsletters and announcements, and I believe this is currently reflecting badly on the project as a whole. These issues are apparently holding back some key changes to the Gentoo website to make it easier to navigate and help the project appear more active than is reflected by the current front page. If the project needs more hands, and these aren't appearing, then perhaps more should be done to advertise the positions and exactly what they entail (I would suggest announcements on the forums, with specifics on who to talk to for those interested). The newsletter has been having issues for some time, and this makes me wonder if the amount of effort required is excessive for the value obtained from those efforts. While the GuideXML system Gentoo uses for newsletters, etc is nice, does it require too much time and effort to convert articles to GuideXML and get the newsletters published? So you go on to describe issues with thew Newsletter. What kind of issues? Is there not enough content? At the moment the newsletter isn't getting published at all. If this is because there's not enough content being submitted, then I think more needs to be done to encourage submissions and/or actively seek out and write articles. This comes back to the number of editors the newsletter currently has, which is influenced by the skills required to work on the newsletter (currently CVS, GuideXML and knowledge of the scripts used to generate standard content). Is GuideXML in fact a barrier for submission (do we get complaints about it?) If there isn't enough content being submitted to actually produce one, then tell the community this. As said above, perhaps mroe needs to be done to actively seek out and create content. Are there insufficient translators? I can't see that translators is an issue, because even the English version isn't getting published. Are the editors not posting content quick enough? Are the editors editing properly? Are there enough posters in general? Alternative setups for the newsletter could be to either go text-only or web-only. Text-only would involved producing a text-only email, which is then copied and pasted onto the website for archiving. This would obviously require minimal formatting work. Ok, but if the problems are with finding material; changing how the material is posted will not help. The idea behind this was to reproduce the amount of work involved in taking a plain text submission (which I would guess is the form most submissions come in) and getting it published in the newsletter. This method removes the need for conversion to GuideXML. My idea for a web-only setup would require more initial work, but I think would make maintenance much easier once set up. The Gentoo Newsletter would become a separate website, not based on GuideXML, but on a standard CMS. Instead of having set release dates (weekly or monthly), articles would just be released as soon as they are produced. Why does a new shiny CMS enable this? Certainly we could provide access to news/ to a broader audience? You seem to think the target audience cannot author GuideXML though. The regular features like bug stats, GLSAs, developer changes could be easily generated automatically (I suspect almost all of those are mostly done automatically anyway - adapting such scripts for a CMS that can publish from RSS feeds should be relatively trivial) and would appear on the website without any intervention. This is covered by index2; so I'll ignore it ;) You're assuming index2 ever goes live. From what I've seen it's been hanging around for at least 6 months in a ready to go live state, so I'm not holding any hopes of this happening any time soon. =P As above, articles would be published as and when they are ready. Instead of just 1 editor, this website-based setup would be able to have multiple editors with little collaboration required (just to mark submissions as being worked on when an editor picks them up, which should be easily doable using a ticket-based system (bugzilla) or mailing list). Does the current news have only 1 editor? I am on PR but I tend not to commit news or approve things. Why do you not tend to commit news or approve things? It may not be just the 1 editor, but I suspect the problem is a general lack of active editors. From what I've read, current GMN publishers require knowledge of how to run all the scripts to generate the standard content and write GuideXML to a pretty good standard. I suspect this is all quite time consuming (from the little I've done in GuideXML, I certainly find that time consuming). This suggestion would: 1) Drop the skill requirements for news article publishers to being able to operate a CMS 2) Require minimum
Re: [gentoo-dev] PR Project Activity Issues
Donnie Berkholz wrote: On 21:30 Mon 26 Jan , AllenJB wrote: The Gentoo PR Project currently appears to be having difficulties with keeping up, both with the newsletters and announcements, and I believe this is currently reflecting badly on the project as a whole. It's easy to complain and harder to take action to actually improve things. From my point of view, it seems like you've got an awful lot of time for the former and none for the latter. Regarding the parts of PR besides the newsletter and events, let me know once you've done something useful like do the work to close a few PR bugs, and we'll talk then. I submitted a newsletter item a couple of months ago in GuideXML format.[0] I have some ideas forming for more, but I'm kind of dissuaded by the lack of actual publishing of the newsletter or any news about why it is not being published. [0] http://www.gentoo.org/news/en/gmn/20081130-newsletter.xml As I said in my opening post, I currently don't believe I have the time to commit to being a full time developer, but intend to as soon as I do. If you have some insight as to why these are apparent issues, please teach me. I would not have posted this thread if it were not for the fact that several developers also seem to think there is a problem and there seems to be no discussion going on that I can see as to what the causes of the problems are and how to solve them, so I decided to start one. PR has the dubious honor of being probably the most publicly visible of all the Gentoo projects, so maybe the issues are being blown out of proportion, but without any discussion there's no way to discover whether or not this is the case. Perhaps things would be better if we did not discuss this at just let the status quo stand? AllenJB
[gentoo-dev] PR Project Activity Issues
Hi all, The Gentoo PR Project currently appears to be having difficulties with keeping up, both with the newsletters and announcements, and I believe this is currently reflecting badly on the project as a whole. These issues are apparently holding back some key changes to the Gentoo website to make it easier to navigate and help the project appear more active than is reflected by the current front page. If the project needs more hands, and these aren't appearing, then perhaps more should be done to advertise the positions and exactly what they entail (I would suggest announcements on the forums, with specifics on who to talk to for those interested). The newsletter has been having issues for some time, and this makes me wonder if the amount of effort required is excessive for the value obtained from those efforts. While the GuideXML system Gentoo uses for newsletters, etc is nice, does it require too much time and effort to convert articles to GuideXML and get the newsletters published? Alternative setups for the newsletter could be to either go text-only or web-only. Text-only would involved producing a text-only email, which is then copied and pasted onto the website for archiving. This would obviously require minimal formatting work. My idea for a web-only setup would require more initial work, but I think would make maintenance much easier once set up. The Gentoo Newsletter would become a separate website, not based on GuideXML, but on a standard CMS. Instead of having set release dates (weekly or monthly), articles would just be released as soon as they are produced. The regular features like bug stats, GLSAs, developer changes could be easily generated automatically (I suspect almost all of those are mostly done automatically anyway - adapting such scripts for a CMS that can publish from RSS feeds should be relatively trivial) and would appear on the website without any intervention. As above, articles would be published as and when they are ready. Instead of just 1 editor, this website-based setup would be able to have multiple editors with little collaboration required (just to mark submissions as being worked on when an editor picks them up, which should be easily doable using a ticket-based system (bugzilla) or mailing list). An advantage, as I see it, of the website-based system is that it could be expanded to include features not currently easily possible with the current newsletter - categorized archiving of articles (not just be publish date) and user comments. While I haven't looked, it's probably possible to even find a CMS which includes email notification of new articles as a feature. AllenJB PS. This did start out as a submission for a council meeting agenda item, but I couldn't stop writing. PPS. To preempt the obvious suggestion: I do intend to become a developer, I just don't feel I have the time to commit right now. That'll hopefully change in ~6 months once I've finished uni and have a job.
Re: [gentoo-dev] QEMU Sick!
Mateusz Mierzwinski (me.matheos.org) wrote: - No main packages updates. Define main packages. If there are packages you know to be out of date, file a bug at http://bugs.gentoo.org - No serious Gentoo-Wiki - rewritten after great boom! Yes, the loss of content on Gentoo Wiki was unfortunate. An offsite backup system has now been put in place so this won't happen again on the same scale. Others have scraped Google Cache for most of the old content and put it up at http://gentoo-wiki.info. Many have been busy working on articles on the new wiki and it is fast returning to its former glory (it's even better in some respects IMO - the rewrite has been an opportunity to correct some issues). - Portage blocks! - in 2005 there was no blocks, system was stable and working with max performance - now blocks are needed - WHY?! Portage blockers did exist in 2005. What's more, as of portage 2.1.6, most blocks are now resolved automatically. - Amd64 have oldest packages developed by devs (much don't work). This is completely false. I use amd64 on most of my machines and the only thing I have issues with is Flash - but that's certainly not the fault of the Gentoo developers. - GLI death! People used GLI! You write OS for PPL, not for Your usage. The GLI has, in my opinion, been in a poor state since its inception. It has slowly gotten a bit better, but not enough. In my opinion it should never have been an icon on the desktop of the livecd. It wasn't ready. And for whatever reasons, progress on fixing its issues never seemed to be that good. Also, you'll actually find most open source developers are in it to scratch an itch. It may seem completely selfish, but it works. Developers volunteer their time on projects they are interested in. You can't force people to work on things they aren't interested in in their free time - it'll never work. I also believe there's an alternative project which is replacing the GLI for what it was intended to be used for. Details of this will be in the announcement when it is released. - Stupid ideas about kicking off creator of Gentoo - You using his work! That's sucks! Try to rewrite whole portage by Your own then You can kick off anyone You like! No one kicked off Daniel Robbins - As far as I know he left of his own accord. His relatively recent return is a long story and another issue entirely. - KDE 4.1 packages updates... or should I say - none of it! Latest unstable version of KDE 4 is 4.2 version!!! KDE is being worked on in overlays at the moment. Personally I don't think it's ready for everyday use yet. I tried the 4.2 SVN versions recently and it still had many issues. Check DistroWatch what You done with Gentoo! In 2007 Yr. Gentoo was 7-th place, and now? Distrowatch ranks distros based on page views on its site. It's hardly a great way to rank distros. AllenJB
[gentoo-dev] index2.xml: What needs to be done to get this live?
Hi all, What needs to be done to get https://bugs.gentoo.org/show_bug.cgi?id=252157 and all the other changes implemented on index2.xml to go live? I have tried requesting information on the bugs, but this seems to have got me nowhere. If there is still work to be done, what is it? I am willing to look at any work that still needs to be done because I believe that getting these wonderful changes to the Gentoo website live is important to the project. AllenJB
Re: [gentoo-dev] GLI Officially Deprecated
Philip Webb wrote: 090114 Donnie Berkholz wrote: On 15:23 Wed 14 Jan 2009, Ben de Groot wrote: Also, will we have an announcement on the www.gentoo.org frontpage? This seems to me an important enough issue to inform our users about. Yeah, I'll get something up. I've got a few pending now. I've been using Gentoo since 2003 have installed it in 2 machines. I've also felt it necessary more than once to comment in LWN in response to scare stories then circulating about the death of Gentoo how it was no longer putting out new versions reliably or on time. The fact that 'version' doesn't mean the same for Gentoo as other distros is not clear to the many people who haven't used Gentoo. I just had a look at the Gentoo home page, as if I were a newcomer wanting to find out how to get started. The 'about' page says nothing about the basic installation process, so I went to 'installation docs', where the 1st 'installation resource' is the 'Gentoo Handbook', which led me to get 'Gentoo AMD64 Handbook', then 'about the Gentoo Linux installation'. This emphasises that I can install Gentoo in many ways, the 1st of which listed is 'from one of our installation CDs'. May I suggest that the 'about' page needs an additional 3rd section entitled 'How do I go about installing Gentoo ?'. I'm sure DB is capable of writing whatever is needed, but it could be something like the following: Unlike most distributions, which rely on binary packages and create a new version of the whole system at regular intervals, Gentoo is installed once and thereafter kept upto-date by the user by means of Portage (as above). Installing Gentoo is not difficult, but it does require a bit more time attention from the user, which we at Gentoo consider to be a useful exercise for her or him to get to know better how a Linux system really works under the hood. All you typically need is a live CD and a copy of the Gentoo Handbook, which you can find by following the link to 'installation docs' above. It might be an idea also to amend the line in the Handbook above, so that 'one of our installation CDs' is not quite so prominent. HTH The ability of new users to find their way around the site was something I tried to fix with a new sidebar menu[0], which has currently been implemented in http://gentoo.org/index2.xml - Unfortunately this is currently being held up by something to do with the GLSA's that's been hanging around incomplete for the past 6 months now (see the deps of bug #252157). I've tried posting on the relevant bugs to find out exactly what needs to be done, but no one seems to care, which is a real shame as the new index would be a vast improvement in my opinion. [0] https://bugs.gentoo.org/252157 AllenJB
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: package.mask
Peter Volkov wrote: В Вск, 11/01/2009 в 10:31 +0100, Benedikt Böhm пишет: On Sun, Jan 11, 2009 at 01:56:52AM +0100, Friedrich Oslage wrote: - - you forgot the ChangeLog entry `cvs log` is the changelog, i don't see why i should add a changelog entry. There is the same reason as for ChangeLogs for ebuilds. Users (I'm user too) don't have cvs log at hand at their systems but still consider that it's important to know about changes. Is it really hard to script `echangelog msg cvs commit -m msg`? In my opinion the cvs commit log and the ChangeLog serve 2 different purposes. The cvs log is for developers while the ChangeLog is for users. While the cvs log will likely just want to explain what change was made, the ChangeLog should explain why it was made. Developers need to realise that users don't know everything about the software they use and don't always pin down the reasons for unexpected beviour. Users also don't always read the documentation given to them. This has been seen recently in the change of default behavior of the world set in stable portage is a good example of this. Many users didn't even know about the --update option and many don't read post-commit messages (I expect because they don't realise the importance of those messages or how they can change the ELOG options to make the messages easier to read, for example by having them emailed to them). There are other examples of insufficient information being given to users too - the dvdnav USE flag was masked recently, but neither the ChangeLog or the cvs commit message give any indication as to why this occurred. In my opinion Gentoo developers need to do more to communicate with their users. This could be as simple as prominently posting documentation on the elog system and how to tailor it. Or it might involve posting more announcements to the Gentoo website (which would double up and make the project look more active than it currently does from its front page). AllenJB PS. I know about index2.xml - but that doesn't look like it's going to be the main front page any time soon at the moment, which is a real shame because it has some awesome changes.
