Re: [gentoo-dev] July Council Meeting: Requested Agenda Item
On Sat, Jun 10, 2006 at 04:28:36AM +0100, Christel Dahlskjaer wrote: I would like to ask that the Council discuss the current state and future of the GWN at their next meeting. Council? Why escalate things? Have you talked to Ulrich about the problems mentioned below? Isn't the GWN somehow a userrel issue? ;-) 1. Reliability. The GWN claims to be a weekly publication, yet it frequently fails to publish without prior warning. There was no edition this week, and Patrick Lauer says that it is unknown whether there will be an edition next week as Ulrich Plate is AWOL. I agree there are problems due to Ulrich being awol every now and then, but what can the council do about it? Fire him so the GWN is unmaintained? ;-) 2. Permissions. Although it could be considered flattering that the GWN should choose a developer's blog as inspiration for an article, they should ensure that they have the developer / author's permission before quoting them (see previous complaints by brix, ciaranm and others). Why? What makes blog posts different to mailing list/forum threads, new versions being released etc? Do you want to ask people for permission then, too? I also believe that when posting an article or interview, a copy should be sent to the relevant people to ensure that they are ok with what is being posted (my dev of the week interview, for example, was rather screwed up and misrepresentative). When someone contacts GWN to have something corrected, it would be appreciated were the GWN staff to at least deign to acknowledge receipt, even if for some reason they choose not to honour the corrections or post a retraction (although refusing to publish corrections is extremely insulting to those wronged). Considering Ulrich is appearently still/again awol, could that be the reason? I have requested small fixes (like wrong email addresses in stuff i submitted) every now and than and got what i asked for. 3. Misinformation, misquotations and outright fabrications. Sure, there's freedom of the press, but that shouldn't be used as an excuse for deliberately making up quotes and printing intentional misinformation. Huh? Can you back that statement up? From a PR perspective, Gentoo could benefit greatly by better utilisation of the GWN. I believe that as it stands, however, the GWN is discouraging people from contributing and damaging Gentoo's credibility. I have submitted a bunch of articles to the GWN, and it has always worked fine for me. Yes, Ulrich is awol at times and sometimes there are smaller corrections to make in the final article, but i never felt discouraged to submit my stuff. Worst case it takes a few extra days to get published. Another thing that concerns me is the way the articles are written. It is blatanly obvious that the GWN writers are not native English speakers as both the grammar and the flow of the articles is far from attractive. Having read through the archives, I notice that there was once a time when the GWN was a great publication, and I would like to think that it could become great yet again; in its current state, though, it is doing more harm than good. I disagree. GWN could use some more manpower to improve this and that, but i don't see the harm - at least i could easily come up with lots of stuff happening that does more harm (Not pointing my finger at anyone and leaving it up to everyone's imagination to think of something that does damage Gentoo in a terrible way). Lack of content and poorly written or incorrect articles are often justified by the GWN team on grounds of overwork and insufficient manpower. When I asked why they were not recruiting, I was informed that no-one has any interest in contributing. Upon speaking with others, however, I find that this is not the case -- people are interested, but fear (and rightly so) that their work will be edited in such a way that it is no longer something with which they want to be associated. I'm sure a solution can be found to that problem - actually Ulrich is quite a nice guy to talk to, so if those people came out of hiding those problems may be solved by talking. Another complaint is that the GWN rejects any writing style which has any degree of character or levity. Any attempt at dececnt writing (the kind that would make it into publication in English newspapers or magazines, for example), is met with the claim that the GWN is not a humorous publication. http://www.gentoo.org/news/en/gwn/20060522-newsletter.xml#doc_chap3 Look at the picture and tell me it's not at least a tiny bit humorous. Agreed, the joke is a bit obvious. I would like to see discussion about the way the GWN is (mis)representing Gentoo, how we can better actualise its full potential and what can be done to address the concerns listed above. I'm still not sure why the council should discuss the issue in the first place, i think everyone agrees that the GWN is a bit understaffed (for whatever reason) and some
Re: [gentoo-dev] July Council Meeting: Requested Agenda Item
First of all, someone from infra/recruiters might please revoke my write access to gentoo/xml/htdocs/news/gwn. I'm no longer interested in contributing to the GWN. I also believe that when posting an article or interview, a copy should be sent to the relevant people to ensure that they are ok with what is being posted (my dev of the week interview, for example, was rather screwed up and misrepresentative). That's why Ulrich posts a draft to the core mailinglist, both for technical and grammar/spelling review. Also it is (at least it was) expected behavior, to give devs of the week (and devs mentioned or affected in/by other articles) a chance to review the article about them. If this wasn't the case with your article this is a problem we need to address. When someone contacts GWN to have something corrected, it would be appreciated were the GWN staff to at least deign to acknowledge receipt, even if for some reason they choose not to honour the corrections or post a retraction (although refusing to publish corrections is extremely insulting to those wronged). That's what I did in the past, of course: Only if I knew that there's something which needs to be corrected. (i.e. if there's a mail to the [EMAIL PROTECTED] alias). Another thing that concerns me is the way the articles are written. It is blatanly obvious that the GWN writers are not native English speakers as both the grammar and the flow of the articles is far from attractive. Having read through the archives, I notice that there was once a time when the GWN was a great publication, and I would like to think that it could become great yet again; in its current state, though, it is doing more harm than good. Once again: We have a draft posted to core to catch grammer/spelling mistakes. That doesn't improve the language used in GWN at all, but as you mentioned, none of us is a native speaker. I'm sorry for not being a native speaker. Finally, reading your mail makes me really angry. I'm seeing myself as a somewhat regular contributor to the GWN and would have expected, that someone who draws a negative picture of the GWN like you, tried to talked to me before posting such a mail. Also I see nothing the Council can decide to improve the GWN, besides stopping further GWN releases. I fully agree that we have lots problems and much room for improvement with the GWN, but I can't agree with the way your trying to achieve this. EOD for me. wkr, Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] July Council Meeting: Requested Agenda Item
Congratulations. I just unsubscribed from the gwn-feedback-alias after reading your mail. * Christel Dahlskjaer [EMAIL PROTECTED] [06/06/10 04:28 +0100]: 1. Reliability. The GWN claims to be a weekly publication, yet it frequently fails to publish without prior warning. There was no edition this week, and Patrick Lauer says that it is unknown whether there will be an edition next week as Ulrich Plate is AWOL. Several times Kurt or I took over the job of publicing the GWN when Ulrich asked us. So, there is a backup, but he didn't asked for this week. 2. Permissions. Although it could be considered flattering that the GWN should choose a developer's blog as inspiration for an article, they should ensure that they have the developer / author's permission before quoting them (see previous complaints by brix, ciaranm and others). I also believe that when posting an article or interview, a copy should be sent to the relevant people to ensure that they are ok with what is being posted (my dev of the week interview, for example, was rather screwed up and misrepresentative). When someone contacts GWN to have something corrected, it would be appreciated were the GWN staff to at least deign to acknowledge receipt, even if for some reason they choose not to honour the corrections or post a retraction (although refusing to publish corrections is extremely insulting to those wronged). And I expect the same from you. You should ask the affected people first before starting a discussion about them on our public mailing lists. This is a device I can give you for further userrelations-activities. 4. Credit. Care should be taken to ensure that crrect credit is given. It is. Either as Author or Contributor. Another thing that concerns me is the way the articles are written. It is blatanly obvious that the GWN writers are not native English speakers as both the grammar and the flow of the articles is far from attractive. Having read through the archives, I notice that there was once a time when the GWN was a great publication, and I would like to think that it could become great yet again; in its current state, though, it is doing more harm than good. It's quite interesting to see, that the GWN and also Debian's Weekly Newsletter is run by Germans mostly. Is there a problem with native speakers to run a periodically newsletter for a long time ( 3 years)? Lack of content and poorly written or incorrect articles are often justified by the GWN team on grounds of overwork and insufficient manpower. When I asked why they were not recruiting, I was informed that no-one has any interest in contributing. Upon speaking with others, however, I find that this is not the case -- people are interested, but fear (and rightly so) that their work will be edited in such a way that it is no longer something with which they want to be associated. Subscribe to the gwn-feedback-alias and read or comment the submissions to the GWN. Make sure that every user will receive and answer. And forward questions to the arch-teams. Isn't that userrel's job? I didn't saw your contributions there yet. Regards, Lars pgpBLKe0FtQQt.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
On Sat, 10 Jun 2006 02:01:25 +0100 Roy Marples [EMAIL PROTECTED] wrote: On Saturday 10 June 2006 01:33, Alec Warner wrote: So we have two use flags - client and server. Here are the possabilities -client -server +client -server +client +server -client +server Do we read -client -server and +client +server to mean the same thing? If so the logic can read if use client || ! use server ; then # build client fi if use server || ! use client ; then # build server fi How does portage stop us from doing that now? built_with_use is then incorrect, since for -client -server you really built both. use client build client use server build server The problem here is that breaks existing ebuilds, which could be viewed as equally bad. I do think we should avoid built_with_use where we can, as it causes emerge to abort. I still think this would be much better dealt with by splitting the ebuilds and using the existing one to install both sub-ebuilds. To my mind, building client or server is too big a split for USE flags which control features of a package rather than pieces of it. I realise that's not a clear distinction, but I think 'use client|server' is different from 'use ipv6'. The latter, which is how I see most USE flags that build stuff conditionally, is about including support for something within the application/libraries built by the ebuild. However USE client/server is about whether the apps/libraries are built at all. Suggestion was: net-misc/dhcp-client net-misc/dhcp-server net-misc/dhcp - RDEPEND on -client and -server This way, if something needs the server, they depend on dhcp-server. If something needs the client, it depends on dhcp-client. If you need both, depend on net-misc/dhcp. Over time, existing package depedencies can be reduced from dhcp to dhcp-client or dhcp-server as appropriate. The only objection I've seen so far to the split ebuild approach is that if upstream intend the whole tarball to be installed then we should do the same. I don't think that holds too much water; 1) The 'meta' build would provide the complete package as compiled upstream anyway 2) Just because upstream provide everything in one tarball doesn't mean upstream think you should necessarily install everything. Obvious example here is KDE. 3) The use flag approach effectively splits the build anyway, so there's not really any difference. But technically built_with_use isn't incorrect as the ebuild wasn't built with it. To effectively use built_with_use you cannot assume that the flag does what it says on the tin - you have to inspect the ebuild code you're querying. Prior history shows deps of db vs gdbm where if both or neither then db was used, otherwise the flagged db was used. Problems problems - soltutions that work with existing installs or do we just bite the bullet and do ! use client ! use server die must select either client or server Which kinda defeats the purpose of a clean install. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] July Council Meeting: Requested Agenda Item
субота, 10. червень 2006 04:28, Christel Dahlskjaer Ви написали: I would like to ask that the Council discuss the current state and future of the GWN at their next meeting. Hah? What has concil to do with this? Is it going to mandate GWN be better and it magically turns into some other thing? Why do you think there is malicious intent here at all? [skipping the listing] All these problems can be explained very simply - a lack of manpower. As I understand, GWN now is a one-man endeavour and Ulrich was pointing this out himself and literally yelling for help! Many many times! Over approx last 6 month or so.. Do we want a more reliable and representative GWN? Of course! How we can get there? Well, stand up and help! Involving council is not going to do anything besides starting yet another pointless burocratic endeavor. Well, I suspect it won't do even that - I am pretty sure council is going to just throw out this claim even if you officially start it. They can of course mandate some more action, but what would be the point? If there are no people willing to stand up, then who will listen to it? So, to conclude this thing. The only way GWN is going to improve, is if some more people will join the ranks and start writing/editing GWN entries. I'd say a team of 3 people is usually sufficient, but we need more like 7 so that three are available for more than a first month :) (this is based on my experience with organazing Russian transation team in its early days), plus a steady stream of at least one new dev joining/two month, to compensate for people droppig out. This should also have an effect of draft GWN published at least a day in advance, instead of a few hours, so that the rest of us will be able (and will ;)) take a look at it and make corrections.. George -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] July Council Meeting: Requested Agenda Item
On Sat, 2006-06-10 at 03:28 +0100, Christel Dahlskjaer wrote: I would like to ask that the Council discuss the current state and future of the GWN at their next meeting. I don't think you have to escalate that far. We should be able to discuss things without the thermonuclear option ;-) 1. Reliability. The GWN claims to be a weekly publication, yet it frequently fails to publish without prior warning. There was no edition this week, and Patrick Lauer says that it is unknown whether there will be an edition next week as Ulrich Plate is AWOL. We have tried to get a backup structure working, Halcy0n for example offered to help. Ulrich never responded to these offers. He usually has a good reason for not doing the GWN (like no Internet access, broken notebook etc), but I also find this quite unsatisfactory. 2. Permissions. Although it could be considered flattering that the GWN should choose a developer's blog as inspiration for an article, they should ensure that they have the developer / author's permission before quoting them (see previous complaints by brix, ciaranm and others). As far as I'm aware this has been taken care of. But with the GWN quite understaffed it is not easy to get everything done well. I'd appreciate some more support from others, but sadly my recruiting experiments usually ended after one contribution (for example summary of the -user ML). I also believe that when posting an article or interview, a copy should be sent to the relevant people to ensure that they are ok with what is being posted (my dev of the week interview, for example, was rather screwed up and misrepresentative). My fault. When someone contacts GWN to have something corrected, it would be appreciated were the GWN staff to at least deign to acknowledge receipt, even if for some reason they choose not to honour the corrections or post a retraction (although refusing to publish corrections is extremely insulting to those wronged). The reason for that is that the GWN is mostly sent out by mail. This makes corrections a bit more difficult, but I think having a sane policy for that would be helpful. 3. Misinformation, misquotations and outright fabrications. Sure, there's freedom of the press, but that shouldn't be used as an excuse for deliberately making up quotes and printing intentional misinformation. I don't know what exactly you are talking about here. But it shouldn't happen. 4. Credit. Care should be taken to ensure that crrect credit is given. Yes. From a PR perspective, Gentoo could benefit greatly by better utilisation of the GWN. I believe that as it stands, however, the GWN is discouraging people from contributing and damaging Gentoo's credibility. The problem with the GWN is the lack of reliable useful contributions. There was a time when the GWN was ~80% written by me, but that took more time than I could afford in the last weeks. Another thing that concerns me is the way the articles are written. It is blatanly obvious that the GWN writers are not native English speakers as both the grammar and the flow of the articles is far from attractive. Help is appreciated :-) The GWN has become a german thing, we have jokingly discussed writing it in german and letting someone translate it to english. Having read through the archives, I notice that there was once a time when the GWN was a great publication, and I would like to think that it could become great yet again; in its current state, though, it is doing more harm than good. Agreed. Lack of content and poorly written or incorrect articles are often justified by the GWN team on grounds of overwork and insufficient manpower. When I asked why they were not recruiting, I was informed that no-one has any interest in contributing. There's a big difference between one-off articles and continuous contribution. Also those that I found most willing to contribute had the biggest language problems - what we need is support from the native speakers. Upon speaking with others, however, I find that this is not the case -- people are interested, but fear (and rightly so) that their work will be edited in such a way that it is no longer something with which they want to be associated. Another complaint is that the GWN rejects any writing style which has any degree of character or levity. Any attempt at dececnt writing (the kind that would make it into publication in English newspapers or magazines, for example), is met with the claim that the GWN is not a humorous publication. Blame the flamefests of the past. Whenever attempts were made to give the GWN more dynamic it was flamed down (because ze german humor is not funny! Nein! ;-) ) So the consensus was to keep the silly jokes out of the GWN since always someone misunderstands or complains. I'd like to have it a bit more open, funny, enjoyable ... but there's only so much I can do. I would like to see discussion about the way the GWN is
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
On Saturday 10 June 2006 09:32, Kevin F. Quinn wrote: Suggestion was: net-misc/dhcp-client net-misc/dhcp-server net-misc/dhcp - RDEPEND on -client and -server You would also need net-misc/dhcp-common then to stop client and server installing the same required libraries and headers. In this instance, keeping it in one ebuild outweights the advantage of a split ebuild in my eyes. This way, if something needs the server, they depend on dhcp-server. If something needs the client, it depends on dhcp-client. If you need both, depend on net-misc/dhcp. Over time, existing package depedencies can be reduced from dhcp to dhcp-client or dhcp-server as appropriate. I doubt any package will ever depend on a dhcp server as such so that helps the one ebuild argument. I think I'll keep it as it now is - minimal use flag stops server installation. -- Roy Marples [EMAIL PROTECTED] Gentoo/Linux Developer (baselayout, networking) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Donnie Berkholz wrote: Chris Gianelloni wrote: Since when was overlays.gentoo.org supposed to even be a service to our users? As I understand it, the goal was to ease development, not to provide an easy method for half-working ebuilds to make it to our user's machines. Our users are our biggest base of testers, and the point of overlays is to develop and test, so of course one of the goals is to get overlays onto users' (testers') machines. Making testing as easy as possible is important. But it should be clear that it is testing, and if the apps were ready for the real Portage tree, they'd be in it. Thanks, Donnie That's already being done very well with per-team overlays. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
On Friday 09 June 2006 21:27, Ned Ludd wrote: Maybe along the same lines as what you are pointing out here it should also be noted that built_with_use is semi faulty and can return wrong results when no /var/db/pkg/$CATEGORY/$PVR/USE exists. this is done on purpose -mike pgpkeT3VMXksr.pgp Description: PGP signature
Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Stefan Schweizer wrote: Luis Francisco Araujo wrote: Fine. I highly agree on that, now my question is, why this needs to be officially supported? See Why does this have to be on official gentoo hardware? http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq The FAQ is offline due to ongoing discussion on this matter - expect a reworked FAQ when it has been reviewed. ? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
On Saturday 10 June 2006 04:32, Kevin F. Quinn wrote: I do think we should avoid built_with_use where we can, as it causes emerge to abort. no it doesnt ... the ebuild maintainer makes the package abort based upon the results of built_with_use ... -mike pgpIaYYFHjNYa.pgp Description: PGP signature
Re: [gentoo-dev] Dealing with /var/cache on unmerge
On Friday 09 June 2006 20:25, Andrew Ross wrote: Apologies if this has been addressed previously, i dont believe it has ever come up before Is there any sort of policy covering how an ebuild should deal with /var/cache during unmerge? maybe give ebuilds a way to maintain a list of files that portage should nuke when unmerging the package ... A similar issue exists with log files, but I'd expect them to occupy less space than caches, and generally be considered more useful (since they can't be regenerated). If they were to be dealt with, perhaps portage could have a purge option that removes all traces of a package from the system - including log and cache files (it looks like temp files should already be cleaned out by the ebuild). i'm not so sure ... i'd guess that the large majority of packages do logging with syslog() and there really is no way to bind logfile name to package sanely for all system loggers out there however, logs that a daemon itself generates/maintains rather than using the system logger would fall into this discussion -mike pgprI9bXGa4EW.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
Chris Gianelloni wrote: On Fri, 2006-06-09 at 22:05 +0100, Stuart Herbert wrote: On 6/9/06, Chris Gianelloni [EMAIL PROTECTED] wrote: Gentoo's standard operating procedure is to build packages as they were intended and packaged from upstream. +1 This means if the client and the server for a particular package is in a single package, we should build both by default. No thanks. That doesn't match the standard operating procedure mentioned above. By default, why don't we just build whatever $UPSTREAM intended built by default? That is *exactly* what I said. It means that different packages will behave differently throughout the tree, but that's okay, and is more Gentoo-like than your proposal. Except that you're just saying exactly what I said, just in different words. To facilitate building the client portions only, the use of the local minimal USE flag is allowed. How will you support building the server-only portions of the package? I honestly never bothered to consider it, and really don't care. Someone else can come up with that idea. The problem with using two USE flags is what do you do when someone chooses neither? It will build the $UPSTREAM default? And btw, i like the server and client use flag idea. +1 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] July Council Meeting: Requested Agenda Item
Lack of content and poorly written or incorrect articles are often justified by the GWN team on grounds of overwork and insufficient manpower. When I asked why they were not recruiting, I was informed that no-one has any interest in contributing. There's a big difference between one-off articles and continuous contribution. Also those that I found most willing to contribute had the biggest language problems - what we need is support from the native speakers. Have the GWN posted to -core in a sane time period prior to it's release. I seriously doubt anyone cares about whether the publication is always on time (whatever that may be). If it's a bi-weekly publication it doesn't always have to go out on the same day, as long as you get it out in the general time period. I sometimes respond with corrections/additions but they never make it because it is released before my mail is sent. Often when I see the core mail I don't even bother reading it since by looking at the timestamp I can guess it's already been mailed. -Alec -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
On Sat, 10 Jun 2006 05:44:41 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: On Saturday 10 June 2006 04:32, Kevin F. Quinn wrote: I do think we should avoid built_with_use where we can, as it causes emerge to abort. no it doesnt ... the ebuild maintainer makes the package abort based upon the results of built_with_use ... well yeah, that's what I meant :P -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] July Council Meeting: Requested Agenda Item
Christel Dahlskjaer wrote: I would like to ask that the Council discuss the current state and future of the GWN at their next meeting. This is an open project. The solution to the problems you raise is incredibly simple: Contribute on a regular basis, or find other people who will do so. Writing hugely demotivating emails, scaring away existing contributors, and wasting the council's time will not help at all. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] i18n project
So, let's rephrase it a bit. The following items represent my view about the i18n team's responsibilities: a) Translation of metadata.xml stuff in our tree (Is there any method to keep them up-to-date when the English text changes? Something like revision attribute that gets bumped when the English text gets updated?) b) Localization of Gentoo-developed applications (portage, gentoolkit,...) including their manpages c) l10n for other packages and sending patches upstream d) Translation of manpages. man-pages-cs for example sucks :(. e) Persuading people that having comments in configuration files *without* an equivalent somewhere on the web is evil. Good example might be baselayout. Why? Stuff on the web can be translated pretty easily, configuration files can't. e) Translation of our documentation (that's the GDP's job, the intention is just to share human resources :) ) and GWN. f) Translation/localization of w.g.o. Efforts were already started (meaning that the technology is available on at least one experimental site). My 0.02 Kč :) Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] July Council Meeting: Requested Agenda Item
On Sat, 2006-06-10 at 11:37 -0400, Alec Warner wrote: Have the GWN posted to -core in a sane time period prior to it's release. I seriously doubt anyone cares about whether the publication is always on time (whatever that may be). So what would a sane time period be? 12h? 24h? The problem with that is that you need an editor who is available during this period to add corrections, but with the new influx of helpers I think we can manage. If it's a bi-weekly publication it doesn't always have to go out on the same day, as long as you get it out in the general time period. Well ... it is easier when you work with a schedule. Missing a deadline may happen, but that should not be the usual behaviour. bi-weekly is silly because you forget which week it is and suddenly you skip another week by accident ... I prefer to keep it weekly. And looking at the flood of material we have for the next edition I think it is sustainable. I sometimes respond with corrections/additions but they never make it because it is released before my mail is sent. Often when I see the core mail I don't even bother reading it since by looking at the timestamp I can guess it's already been mailed. Hmmm. That looks like a timing problem - the GWN gets created on european time! I think we should try to have a bigger delay between draft and publication, but I'm not sure how to do it best. Maybe shift the draft to saturday and push the final version on sunday? Patrick -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] July Council Meeting: Requested Agenda Item
On Sat, 2006-06-10 at 10:27 +0200, George Shapovalov wrote: субота, 10. червень 2006 04:28, Christel Dahlskjaer Ви написали: I would like to ask that the Council discuss the current state and future of the GWN at their next meeting. Hah? What has concil to do with this? Is it going to mandate GWN be better and it magically turns into some other thing? Why do you think there is malicious intent here at all? I was hoping the council, whom I understand to be built up of people who genuinely care for Gentoo, would look at whether there was any ways of helping the GWN become better. Say, look at alternative ways of recruiting/ attracting contributors. It may have been the wrong place to bring it up, but its the place that was suggested to me when I asked people who have been around a lot longer than I have. [skipping the listing] All these problems can be explained very simply - a lack of manpower. As I understand, GWN now is a one-man endeavour and Ulrich was pointing this out himself and literally yelling for help! Many many times! Over approx last 6 month or so.. As Ulrich doesn't reply to my e-mails, I haven't had a chance to discuss with him, I have, however, spoken to Patrick at great length and I understand that the GWN finds it difficult to recruit, or even attract contributors. And I agree, the main problem appears to be manpower, which is why I am hoping that by creating some discussion people may come up with new / different ways of attracting people to the GWN. Do we want a more reliable and representative GWN? Of course! How we can get there? Well, stand up and help! Involving council is not going to do anything besides starting yet another pointless burocratic endeavor. Well, I suspect it won't do even that - I am pretty sure council is going to just throw out this claim even if you officially start it. They can of course mandate some more action, but what would be the point? If there are no people willing to stand up, then who will listen to it? If the council chooses to throw it aside and not look at ways of helping the GWN then well, that sucks. But atleast I tried. So, to conclude this thing. The only way GWN is going to improve, is if some more people will join the ranks and start writing/editing GWN entries. I'd say a team of 3 people is usually sufficient, but we need more like 7 so that three are available for more than a first month :) (this is based on my experience with organazing Russian transation team in its early days), plus a steady stream of at least one new dev joining/two month, to compensate for people droppig out. This should also have an effect of draft GWN published at least a day in advance, instead of a few hours, so that the rest of us will be able (and will ;)) take a look at it and make corrections.. I agree with the above, and as stated before, I am hoping that the Council, or hell, just discussion on -dev may result in someone jumping up and saying I have an idea, why don't you... or Have you tried.. as what would be great is if people could come up with ideas and ways of attracting people. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Re: Re: Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On 6/9/06, Peter [EMAIL PROTECTED] wrote: Firstly, I think it is very clear that anything in sunrise is experimental or not supported in the main gentoo tree. That's fine! I don't think any user who goes through the trouble to set up an overlay would miss that point. You can't go to o.g.o and not see the disclaimers. And, anyone who goes through the trouble to svn the overlay, edit make.conf, etc., would not be an ignorant newbie (no disrespect to newbies intended). Anyone who fetches the sunrise overlay would know exactly what he/she intends to do and why. Much different than emerge --sync with keyword x86. Recently on -user there was someone who couldn't build any gnome apps, because they had an obsolete gnome2.eclass in their overlay. This user certainly didn't know enough about portage or ebuilds to be using an overlay like that. Besides, users frequently do imprudent things to their systems. They will break their systems by unmasking p.masked stuff (I've done this, so I am in this group), add dangerous CFLAGS based on random forum or wiki pages, and use ~arch packages and then rant about any bugs that show up. As you've already said, having it on a *.gentoo.org domain gives some people a higher level of comfort with it, regardless of any dislaimers. I have no idea what the quality of the sunrise overlay will be, but it seems likely to be worse than the currently p.masked stuff. If getting sunrise is easy enough, and a substantial number of users start using it, supporting those users could become very difficult. -Richard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Peter wrote: Chris, I am not familiar enough about gentoo's hierarchy, politics, or team responsibilities to question your sincerity or authority to say something like: Sorry, but if it isn't supported, it doesn't belong on Gentoo infrastructure. Then please trust that these people who are familiar enough actually know what they're talking about. --de. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] July Council Meeting: Requested Agenda Item
On Sat, 2006-06-10 at 11:40 +0100, Daniel Drake wrote: Christel Dahlskjaer wrote: I would like to ask that the Council discuss the current state and future of the GWN at their next meeting. This is an open project. The solution to the problems you raise is incredibly simple: Contribute on a regular basis, or find other people who will do so. Writing hugely demotivating emails, scaring away existing contributors, and wasting the council's time will not help at all. Wow, thats not quite the response I had expected from you. Rather surprising based on your comments elsewhere. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] July Council Meeting: Requested Agenda Item
On Sat, 2006-06-10 at 09:35 +0200, Tobias Scherbaum wrote: First of all, someone from infra/recruiters might please revoke my write access to gentoo/xml/htdocs/news/gwn. I'm no longer interested in contributing to the GWN. I also believe that when posting an article or interview, a copy should be sent to the relevant people to ensure that they are ok with what is being posted (my dev of the week interview, for example, was rather screwed up and misrepresentative). That's why Ulrich posts a draft to the core mailinglist, both for technical and grammar/spelling review. Also it is (at least it was) expected behavior, to give devs of the week (and devs mentioned or affected in/by other articles) a chance to review the article about them. If this wasn't the case with your article this is a problem we need to address. When someone contacts GWN to have something corrected, it would be appreciated were the GWN staff to at least deign to acknowledge receipt, even if for some reason they choose not to honour the corrections or post a retraction (although refusing to publish corrections is extremely insulting to those wronged). That's what I did in the past, of course: Only if I knew that there's something which needs to be corrected. (i.e. if there's a mail to the [EMAIL PROTECTED] alias). Another thing that concerns me is the way the articles are written. It is blatanly obvious that the GWN writers are not native English speakers as both the grammar and the flow of the articles is far from attractive. Having read through the archives, I notice that there was once a time when the GWN was a great publication, and I would like to think that it could become great yet again; in its current state, though, it is doing more harm than good. Once again: We have a draft posted to core to catch grammer/spelling mistakes. That doesn't improve the language used in GWN at all, but as you mentioned, none of us is a native speaker. I'm sorry for not being a native speaker. I don't actually have a problem with the GWN being written by non-native speakers, English isn't my first language either. I do however think that we could benefit from improving the flow of the articles somewhat. Finally, reading your mail makes me really angry. I'm seeing myself as a somewhat regular contributor to the GWN and would have expected, that someone who draws a negative picture of the GWN like you, tried to talked to me before posting such a mail. Also I see nothing the Council can decide to improve the GWN, besides stopping further GWN releases. I had no intentions to make anyonee angry. And as you aren't listed on the GWN page I had no idea that you were a GWN team member, to my knowledge the only two people who do the GWN are Ulrich and Patrick, both of which I have attempted to speak with/spoken with. And the last thing I want is for the Council to stop the GWN, I am however hoping that they may choose to help the GWN get back on track. If nothing else I believe the council to be made up of people who care about Gentoo a lot, some of which have been around for some time and still remember the old unifying vision, some of which remembers how the GWN was run when it was 'totally awesome' (to use a blonde-ism) and people who hopefully would take the time to try help the GWN explore new/different ways of improving/growing. I fully agree that we have lots problems and much room for improvement with the GWN, but I can't agree with the way your trying to achieve this. What is wrong with it? Would you rather I attempted to have the current GWN staff replaced? Or the publication shut down? signature.asc Description: This is a digitally signed message part
[gentoo-dev] Project Sunrise -- Proposal
Okay, so after figuring out open problems (thanks to kloeri and various other people for help here), we now have a resolution that should satisfy all involved parties here. This should adress dostrow's demands as well. 1) m-w / m-n requirement Only ebuilds that are reported to bugzie (valid bug#) and set to maintainer-wanted are allowed here as well as maintainer-needed ones. maintainer-needed are only allowed if they're removed from the tree and moved over to sunrise (and thus end up as maintainer-wanted again). 2) Not one large tree but subdirs, one per herd to help herds better keeping track of which parts are alive in the overlay, each herd's ebuilds are grouped in a subdir, e.g. there will be a netmon/ dir with net-analyzer/specialapp below it. 3) a yes from herds required, keeping a timeout to avoid bugspam after a comment has been placed on a maintainer-wanted bug in bugzie, there's a grace time of two weeks for herds to either leave a comment on whether they're fine with take over or not. When this time is over and it is assigned to maintainer-wanted, then and only then it is implied as an OK to keep it also in the sunrise project. 4) work needed by herds - take a look at the homepage of the new program - take a look at the ebuild If you're at least partly happy with the new app, drop a note on the bug or just ping sunrise that you're ok with it. Then sunrise takes it over and improves the ebuild together with the contributor so that it reaches a level where it could theoretically be committed to the tree. Herds are more than welcome to help here if they feel like it but basic checks whether the app should ever be on gentoo will be sufficient. 5) commit access to the overlay We implement two levels of commit rights: 1. As there are people out there who just want to maintain one app for start, the ebuild should reach a level that project devs are fine with it, then the user is given permission to commit on that single app. An automated check makes sure that he doesn't commit anywhere else. If violations arise, the access is revoked immediately. 2. People who contribute good ebuilds over a certain period of time are allowed upon decision by project devs to actively help maintaining the project. They'll be given commit rights for the project then. Same frome above applies here: If we notice any abuse, we revoke access immediately. 6) QA assurance Of course there are minor issues with the ebuilds, otherwise they could be committed straight forward. Important thing is that it only finds the way into overlaye if the trusted committers (project devs and users who are given permission explicitely, see above) are fine with it. Additional note on arch issues: initially, just ~x86 and ~amd64 may be set. The rest would need successful test reports for other ~arch keywords. Stable keywording isn't permitted at all, there will be some automated check to make sure no one does it (by accident) here. Additional note: we won't start adding this to layman and making it available easier until the QA checks have been implemented. 7) tag on bugs All ebuilds that are made available on sunrise get an InOverlay KEYWORDS entry on bugs.g.o so that everyone, who looks at the bug, knows about it. 8) Grace time also given from the go point on. When we see that this gets a bit fine-tuning / acceptance among devs, we will explicitely call out a two weeks notice for ebuilds currently assigned to maintainer-wanted so that herds can keep an eye on them and either comment as given, reject take over permission completely, close as WONTFIX in case they're against the app for the tree in futures or just drop a note that they're fine with the take over and the development can be started on the ebuild. Remember the way they need to be reviewed as said in 4). The ebuild is subject to development, the sunrise devs do help with it in case your herd lacks time to completely take care of it. 9) Security In this early stage we have no security liaison on board yet. If one is willing to help out here, we'd be more than glad on welcoming him :) Greetz, Jokey signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
First off, I would like to apologize to everyone who has to read this thread. I know that it is long. I know that it can be frustrating. That being said, I also ask for your patience in this matter, as I am not going to back down on this. I will not roll over and let something I see as this damaging to Gentoo simply happen. Also, since it is obvious that some people are trying to deflect attention away from the actual issues, I will likely not respond to any points that I don't consider to be relevant. I'm not wasting my time, nor yours, with this garbage. Some people seem to not understand that this is not *only* a technical problem, and therefore cannot be discussed on a purely technical level. Some people also think that by comparing someone to a certain ex-developer, that they're going to either win some traction or cause their opposing side to give up. This is not the truth, at all. If it has done anything, it has *fueled* me to fight this project even more. On Fri, 2006-06-09 at 23:54 +0200, Patrick Lauer wrote: On Fri, 2006-06-09 at 16:14 -0400, Chris Gianelloni wrote: Since when was overlays.gentoo.org supposed to even be a service to our users? As I understand it, the goal was to ease development, not to provide an easy method for half-working ebuilds to make it to our user's machines. What's the point of development if not to help users? Umm... perhaps to create a *product* that gives usable software to users? How about a little history lesson? Not so many moons ago, new ebuilds were submitted to bugzilla. The bug wranglers would assign the bugs to the team most likely to end up as the maintainers, and new ebuilds either made it into the tree, or sat in bugzilla until the interest was there for it to be added, if ever. Some people felt that this process left lots of packages in bugzilla, with no one to watch over them. Because of this, the maintainer-wanted, and maintainer-needed bugzilla accounts were created to assist in tracking these bugs/packages. This was a good idea at the time, and worked fairly well so long as there were developers going through and actively searching for bugs, that were no longer assigned to the relevant teams, but instead, assigned into some big dumping ground for new package requests. This process failed, as visibility for new packages was reduced to the teams that would likely be doing the actual work. Now, instead of reverting a broken and failed process, a new project is being created in an attempt to fix the problem. Unfortunately, it has been pointed out that this will introduce an even larger set of problems, but that is not being addressed very well. Everything we do should be done to help users (and worst case we help that small group of users that are devs). I would have to absolutely disagree here. Gentoo's resources should be spent helping developers do their work more efficiently. This provides a positive end result of users getting more and better software. If we simply did everything for the users, then we would have every single kernel source tree done by a few guys with little understanding of kernel internals, we'd only ship a stage1 tarball, and reiser4 would be our default file-system, stability be damned. This means it *CANNOT* be left up to a small group of developers to decide without any discussion on the matter. So now we're a democracy where everything needs to be voted upon? Anything this abhorrently stupid doesn't need a vote. Bullshit. If you need to resort to insults you failed to show on a technical level why it is bad. I have already shown that this is a piss poor idea on a technical level. I don't think I need to reiterate this again and again, but just for you, since you're not catching on, I'll do it one more time. This is an attempt to fix what is a social problem with a technical solution, where one doesn't fit. What problem is this project trying to resolve, exactly? How will creating a secondary official (hey, it's on *.gentoo.org) portage tree help in creating a higher-quality primary portage tree? How will a small team maintain the security and reliability that Gentoo has come to be known for in a secondary portage tree without the support of a security team, or the architecture teams? Why was this not discussed on the developer mailing list before being publicly announced to the world as if it were a complete and working service, with all of the issues worked out? Now, (sorry Flameeyes) let's look at another scenario. A new user to Gentoo decides that he absolutely *must* have package foo. He reads on the forums that package foo is in the Sunrise overlay, so he uses layman and syncs up the overlay. Three weeks later, he decides that he wants pam_skey. He does a search, and there it is! He installs it. This user is not even *aware* that the package came from the overlay. He has a problem. He files a bug. Guess who gets it? Remember, that he isn't
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
On Fri, 2006-06-09 at 18:34 -0400, Mike Frysinger wrote: On Friday 09 June 2006 16:35, Chris Gianelloni wrote: This is the official (hehe) request for comments on making a policy of how to handle ebuilds than can be used for either client or server and how to allow for building client-only. rather than moving to some sort of policy that satisfies no one completely and we'll have to back out of later, why dont we wait until portage can give us proper support for USE=client/server Got an ETA? The situation we have now is confusing, at best, to our users, and something really should be done to resolve it. Waiting another 6 months to a year, only to be able to use it with the particular portage versions that support the proper EAPI for use-based dependencies is not an optimal answer for our users, which is why I came up with the proposal. Honestly, I don't care *what* is decided, so much as I want to spark conversation and see *some* resolution come of it that is *at least* consistent until use-based dependencies are a reality. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
On Sat, 2006-06-10 at 01:24 +0100, Roy Marples wrote: Do we read -client -server and +client +server to mean the same thing? We could, yes. If so the logic can read if use client || ! use server ; then # build client fi if use server || ! use client ; then # build server fi How does portage stop us from doing that now? It doesn't. The problem comes in with the dependency resolver. The only solution to this is checks using built_with_use in pkg_setup, which is discouraged except where absolutely necessary, as it causes all of the dependencies to be merged (incorrectly, possibly) before there is a failure. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Dealing with /var/cache on unmerge
Mike Frysinger wrote: maybe give ebuilds a way to maintain a list of files that portage should nuke when unmerging the package ... Something similar to this would be useful for kernel ebuilds, as simply unmerging kernel source will leave a load of temporary and object files on the filesystem. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] i18n project
On Sat, 10 Jun 2006 15:11:50 +0200 Jan Kundrát [EMAIL PROTECTED] wrote: b) Localization of Gentoo-developed applications (portage, gentoolkit,...) including their manpages I don't really like this one. Documentation, sure, but for the tools themselves I think it could cause more problems than actually help. Quoting a relevant discussion from #gentoo-portage earlier today that hopefully explains my concerns: zmedico I think if we are going to override LC_MESSAGES then we should consider it in terms of broader gettext support in portage. zmedico Flameeyes wants to help internationalize portage... SpanKY not much point if we reset language variables zmedico yeah, it has to be considered together genone zmedico: I don't like that idea much zmedico reasoning? genone makes support harder genstef extending the problem we are trying to solve, yeah zmedico we can refuse to support non-english reports. zmedico we already to afaik zmedico s/to/do/ genone I'm not only talking about bugzilla genstef haahaa, why do we have it in portage then? genstef how can something be both official and unsupported? ;) * genstef is stealing arguments from his opponents on the mailing lists ;) zmedico genone: if not bugzilla, then...? genstef forums, irc, mailing lists genone zmedico: any support channels: bugzilla, forums, irc, ... genstef direct mail genone not only support by us, but also user2user solar lots of things are officially unsupported zmedico I was thinking we could have a mode that gives both english and the user's native locale solar like overlays should of been one of those. overlay.dev.gentoo vs overlays.gentoo genone zmedico: two tracebacks? ;) * zmedico nods zmedico 2 exception strings genstef so portage exit errors will be doubled? genone IMO english+native is a extremely crappy thing zmedico yeah, maybe :) zmedico the thing is, nobody forces you to look at forums, irc, mail that's in a foreign language genone and my point is that users often don't even realize that their post contains non-english text zmedico it's an breach of etiquette, and they should be chastized :) zmedico I'd hope it could be handled well enough at a social level genone also in my experience translations in FOSS tend to be of poor quality, there have been several situations where I didn't understand what the german translation was supposed to mean where the original was perfectly clear genone Overtranslation being one big problem zmedico that's a problem for the maintainers of the translations. portage devs won't handle translation... genone well, maybe I'm wrong, but I think it would cause more problems than help zmedico too bad not everyone knows english. :) lisa too bad not everyone knows norwegian. :) Basically I don't think the benefit is rather dubious or maybe it's just that I had some rather bad experiences with translated versions of FOSS applications, but I'm quite opposed to this part of the project unless you have a way to remove my concerns. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
On Saturday 10 June 2006 10:29, Chris Gianelloni wrote: On Fri, 2006-06-09 at 18:34 -0400, Mike Frysinger wrote: On Friday 09 June 2006 16:35, Chris Gianelloni wrote: This is the official (hehe) request for comments on making a policy of how to handle ebuilds than can be used for either client or server and how to allow for building client-only. rather than moving to some sort of policy that satisfies no one completely and we'll have to back out of later, why dont we wait until portage can give us proper support for USE=client/server Got an ETA? The situation we have now is confusing, at best, to our users, and something really should be done to resolve it. sure, dont add support for the flags at all at this point, problem solved USE=minimal has no real definition, no point in trying to iron one out imo -mike pgpKXsIMY6zIf.pgp Description: PGP signature
[gentoo-dev] Re: Project Sunrise -- Proposal
Markus Ullmann wrote: 2) Not one large tree but subdirs, one per herd to help herds better keeping track of which parts are alive in the overlay, each herd's ebuilds are grouped in a subdir, e.g. there will be a netmon/ dir with net-analyzer/specialapp below it. A better solution is mentioned in the FAQ --snip-- I want to see all the ebuilds in sunrise that affect my herd, is that possible? Yes, we have hacked up a script in scripts/create-stats.sh for the moment, that will give you all packages, bugs and CC: sys-auth/pam_skey - bug 55279 - on CC: jakub pam-bugs taviso maintainer-wanted You might want to run it with your herd or maintainer as argument to get filtered output: scripts/create-stats.sh pam-bugs --snap-- If there is real interest in subdirs for other reasons than listing packages by herds I would like to hear them. For the moment we are still discussing everything as mentioned on the wiki: WARNING: This is currently under creation and review - fundamental changes may still take place Please work with us in IRC to make it please everyone. - Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] July Council Meeting: Requested Agenda Item
On Sun, 11 Jun 2006 01:00:43 +0200 Patrick Lauer [EMAIL PROTECTED] wrote: On Sat, 2006-06-10 at 11:37 -0400, Alec Warner wrote: Have the GWN posted to -core in a sane time period prior to it's release. I seriously doubt anyone cares about whether the publication is always on time (whatever that may be). So what would a sane time period be? 12h? 24h? The problem with that is that you need an editor who is available during this period to add corrections, but with the new influx of helpers I think we can manage. It should be sent *at least* 24 hours in advance IMO so everyone gets a chance to check it. Better to send news that's a few days old than to send incorrect news. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Project Sunrise -- Proposal
On 6/10/06, Markus Ullmann [EMAIL PROTECTED] wrote: Okay, so after figuring out open problems (thanks to kloeri and various other people for help here), we now have a resolution that should satisfy all involved parties here. This should adress dostrow's demands as well. 1) m-w / m-n requirement Only ebuilds that are reported to bugzie (valid bug#) and set to maintainer-wanted are allowed here as well as maintainer-needed ones. maintainer-needed are only allowed if they're removed from the tree and moved over to sunrise (and thus end up as maintainer-wanted again). 2) Not one large tree but subdirs, one per herd to help herds better keeping track of which parts are alive in the overlay, each herd's ebuilds are grouped in a subdir, e.g. there will be a netmon/ dir with net-analyzer/specialapp below it. If its unofficially part of a herd, then isn't it no longer a m-w/m-n ebuild? 3) a yes from herds required, keeping a timeout to avoid bugspam after a comment has been placed on a maintainer-wanted bug in bugzie, there's a grace time of two weeks for herds to either leave a comment on whether they're fine with take over or not. When this time is over and it is assigned to maintainer-wanted, then and only then it is implied as an OK to keep it also in the sunrise project. 4) work needed by herds - take a look at the homepage of the new program - take a look at the ebuild If you're at least partly happy with the new app, drop a note on the bug or just ping sunrise that you're ok with it. Then sunrise takes it over and improves the ebuild together with the contributor so that it reaches a level where it could theoretically be committed to the tree. Herds are more than welcome to help here if they feel like it but basic checks whether the app should ever be on gentoo will be sufficient. 5) commit access to the overlay We implement two levels of commit rights: 1. As there are people out there who just want to maintain one app for start, the ebuild should reach a level that project devs are fine with it, then the user is given permission to commit on that single app. An automated check makes sure that he doesn't commit anywhere else. If violations arise, the access is revoked immediately. 2. People who contribute good ebuilds over a certain period of time are allowed upon decision by project devs to actively help maintaining the project. They'll be given commit rights for the project then. Same frome above applies here: If we notice any abuse, we revoke access immediately. 6) QA assurance Of course there are minor issues with the ebuilds, otherwise they could be committed straight forward. Important thing is that it only finds the way into overlaye if the trusted committers (project devs and users who are given permission explicitely, see above) are fine with it. Additional note on arch issues: initially, just ~x86 and ~amd64 may be set. The rest would need successful test reports for other ~arch keywords. Stable keywording isn't permitted at all, there will be some automated check to make sure no one does it (by accident) here. Additional note: we won't start adding this to layman and making it available easier until the QA checks have been implemented. 7) tag on bugs All ebuilds that are made available on sunrise get an InOverlay KEYWORDS entry on bugs.g.o so that everyone, who looks at the bug, knows about it. 8) Grace time also given from the go point on. When we see that this gets a bit fine-tuning / acceptance among devs, we will explicitely call out a two weeks notice for ebuilds currently assigned to maintainer-wanted so that herds can keep an eye on them and either comment as given, reject take over permission completely, close as WONTFIX in case they're against the app for the tree in futures or just drop a note that they're fine with the take over and the development can be started on the ebuild. Remember the way they need to be reviewed as said in 4). The ebuild is subject to development, the sunrise devs do help with it in case your herd lacks time to completely take care of it. 9) Security In this early stage we have no security liaison on board yet. If one is willing to help out here, we'd be more than glad on welcoming him :) Greetz, Jokey I think this is a much improved//thought out version of the proposal. From the looks of things sunrise should never make it to layman however, because as we all know, anything that makes things more easily accessible to users is going to be (mis)used by more of them. From what I understand, you see Sunrise as an overlay for users to improve their ebuilds because they are insufficient quality to be in the main tree. If they are of this poor quality, they should be no where near users hands, this doesn't make sense. If on the other hand you saw sunrise as a way for more packages to be available to users due to there being a lack of maintainers, asking herds to check out ebuilds as part of the proposal seems
Re: [gentoo-dev] Portage-2.1 released breaking -U
On Friday 09 June 2006 11:57, Wernfried Haas wrote: Oh, and -U has finally been killed :-) too bad there is no usuable solution in its place for developers -mike pgpju0pwm1363.pgp Description: PGP signature
Re: [gentoo-dev] herds.xml
On Fri, Jun 09, 2006 at 05:08:23PM -0400, Chris Gianelloni wrote: On Fri, 2006-06-09 at 16:19 -0400, Mike Frysinger wrote: On Thursday 08 June 2006 21:08, Brian Harring wrote: One additional to this- the location for the file in the tree *should* be metadata/ - shoving it into profiles is the wrong location (it's not profile data, it's repo metadata). that is the correct location for it but we have no metadata tree tracked in cvs How about we keep it where it is (in CVS) and simply have it added to metadata during the normal runs before sync? Downside to this is that any tool written to expect the file in $PORTDIR now doesn't behave as well for cvs users (devs). Either solutions works for me however, mainly after the file being in the tree for majority of users. ~harring pgpyUMm1hTmqB.pgp Description: PGP signature
Re: [gentoo-dev] July Council Meeting: Requested Agenda Item
George Shapovalov wrote: субота, 10. червень 2006 04:28, Christel Dahlskjaer Ви написали: I would like to ask that the Council discuss the current state and future of the GWN at their next meeting. Hah? What has concil to do with this? Is it going to mandate GWN be better and it magically turns into some other thing? Why do you think there is malicious intent here at all? [skipping the listing] All these problems can be explained very simply - a lack of manpower. As I understand, GWN now is a one-man endeavour and Ulrich was pointing this out himself and literally yelling for help! Many many times! Over approx last 6 month or so.. Do we want a more reliable and representative GWN? Of course! How we can get there? Well, stand up and help! Involving council is not going to do anything besides starting yet another pointless burocratic endeavor. Well, I suspect it won't do even that - I am pretty sure council is going to just throw out this claim even if you officially start it. They can of course mandate some more action, but what would be the point? If there are no people willing to stand up, then who will listen to it? So, to conclude this thing. The only way GWN is going to improve, is if some more people will join the ranks and start writing/editing GWN entries. I'd say a team of 3 people is usually sufficient, but we need more like 7 so that three are available for more than a first month :) (this is based on my experience with organazing Russian transation team in its early days), plus a steady stream of at least one new dev joining/two month, to compensate for people droppig out. This should also have an effect of draft GWN published at least a day in advance, instead of a few hours, so that the rest of us will be able (and will ;)) take a look at it and make corrections.. George That's true. Ulrich has been asking desperately for help since a few months now. I propose we ask for contributors in the staffing-needs section instead or before taking this council way. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise -- Proposal
Comments inline ...
On Sat, 2006-06-10 at 13:37 +0200, Markus Ullmann wrote:
Okay, so after figuring out open problems (thanks to kloeri and various
other people for help here), we now have a resolution that should
satisfy all involved parties here. This should adress dostrow's demands
as well.
1) m-w / m-n requirement
Only ebuilds that are reported to bugzie (valid bug#) and set to
maintainer-wanted are allowed here as well as maintainer-needed ones.
maintainer-needed are only allowed if they're removed from the tree and
moved over to sunrise (and thus end up as maintainer-wanted again).
Fine.
2) Not one large tree but subdirs, one per herd
to help herds better keeping track of which parts are alive in the
overlay, each herd's ebuilds are grouped in a subdir, e.g. there will be
a netmon/ dir with net-analyzer/specialapp below it.
Fine.
3) a yes from herds required, keeping a timeout to avoid bugspam
after a comment has been placed on a maintainer-wanted bug in bugzie,
there's a grace time of two weeks for herds to either leave a comment on
whether they're fine with take over or not. When this time is over and
it is assigned to maintainer-wanted, then and only then it is implied as
an OK to keep it also in the sunrise project.
I'm 100% against implicit acceptance. If someone from the sunrise
project wishes to add an ebuild to the overlay they should have to get
an explicit OK from the team in question. The sunrise project could of
course keep a list of teams that have given a blanket OK and of those
that have totally opted out. For those teams in between an OK per
package sought by the sunrise project's team members is needed. I'm
sorry but the leg work to track this stuff and get acceptance has to be
100% on your projects head. Your proposal adds a need for me to actually
look at bugs for packages that I may have no interest in. I don't pay
any attention to maintainer-wanted now I don't want to pay any attention
to a subset of that ever.
4) work needed by herds
- take a look at the homepage of the new program
- take a look at the ebuild
If you're at least partly happy with the new app, drop a note on the bug
or just ping sunrise that you're ok with it. Then sunrise takes it over
and improves the ebuild together with the contributor so that it reaches
a level where it could theoretically be committed to the tree.
Herds are more than welcome to help here if they feel like it but basic
checks whether the app should ever be on gentoo will be sufficient.
So long as this is voluntary and the level of acceptance that I
described above is met I'm OK with it.
5) commit access to the overlay
We implement two levels of commit rights:
1. As there are people out there who just want to maintain one app for
start, the ebuild should reach a level that project devs are fine with
it, then the user is given permission to commit on that single app. An
automated check makes sure that he doesn't commit anywhere else. If
violations arise, the access is revoked immediately.
2. People who contribute good ebuilds over a certain period of time are
allowed upon decision by project devs to actively help maintaining the
project. They'll be given commit rights for the project then. Same frome
above applies here: If we notice any abuse, we revoke access immediately.
Again so long as the team that would have to maintain it in the tree
says OK *explicitly* then sure.
6) QA assurance
Of course there are minor issues with the ebuilds, otherwise they could
be committed straight forward. Important thing is that it only finds the
way into overlaye if the trusted committers (project devs and users who
are given permission explicitely, see above) are fine with it.
Additional note on arch issues: initially, just ~x86 and ~amd64 may be
set. The rest would need successful test reports for other ~arch
keywords. Stable keywording isn't permitted at all, there will be some
automated check to make sure no one does it (by accident) here.
Additional note: we won't start adding this to layman and making it
available easier until the QA checks have been implemented.
Erm...no! See that is the thing about item #1 on my list...there is
nothing preventing Joe User from checking out the overlay and adding say
a ppc64 keyword or a mips keyword to ${random_ebuild} meaning that bugs
*will* be generated for arch teams for packages that are not in the
tree.
Also note I'm not talking necessarily about the Hey, I installed
${package} and it broke. bugs because if ${package} isn't in the tree
bug-wranglers can catch it and off you go...the arch teams aren't
involved. What I am talking about is Hey, my ppc64 started doing weird
things yesterday, ${daemons} are no longer working. having that bug
assigned to the arch team, and then spending a long time only to track
down that the user installed some random library from sunrise seven days
ago and there just happened to be upgrades to
[gentoo-dev] Re: Project Sunrise -- Proposal
Marius Mauch wrote: On Sat, 10 Jun 2006 13:37:15 +0200 Markus Ullmann [EMAIL PROTECTED] wrote: Okay, so after figuring out open problems (thanks to kloeri and various other people for help here), we now have a resolution that should satisfy all involved parties here. This should adress dostrow's demands as well. 1) m-w / m-n requirement Only ebuilds that are reported to bugzie (valid bug#) and set to maintainer-wanted are allowed here as well as maintainer-needed ones. maintainer-needed are only allowed if they're removed from the tree and moved over to sunrise (and thus end up as maintainer-wanted again). 5) commit access to the overlay We implement two levels of commit rights: 1. As there are people out there who just want to maintain one app for start, the ebuild should reach a level that project devs are fine with it, then the user is given permission to commit on that single app. An automated check makes sure that he doesn't commit anywhere else. If violations arise, the access is revoked immediately. 2. People who contribute good ebuilds over a certain period of time are allowed upon decision by project devs to actively help maintaining the project. They'll be given commit rights for the project then. Same frome above applies here: If we notice any abuse, we revoke access immediately. One more rule I'd like to see (should be obvious, but better to write it down): People who commit to a certain project/ebuild have to be on the CC list of the relevant bug report(s) and any important commits should be documented on the bugs (including the revision of/link to the commit). I have not made it a rule yet to prevent whitespacing and updates for minor changes, also I would like to leave things like that to the people to decide to prevent that too many rules lock us in. How far would you want to go? Update for I have removed some quotes for I have made a version bump? Currently it is written down as follows: http://overlays.gentoo.org/proj/sunrise/wiki/HowToCommit, point 6 --snip-- 6) For later updates to the package in the overlay it is still considered good style to update the bug and link to the changes, for exmaple: I added some sed calls, it should build with --as-needed now http://overlays.gentoo.org/svn/proj/sunrise/sys-apps/openguru/openguru-1.ebuild --snap-- I think it should be at least changed from a suggestion to a you need to for updates of .. So,, my question, how far do you want them to go here? - Stefan -- gentoo-dev@gentoo.org mailing list
