[gentoo-dev] Last rites for net-im/ickle and net-misc/gtm
Hey, while wandering trough the tree I came across net-im/ickle and net-misc/gtm, packages abandoned years ago, without metadata and any recent changelog entries. So I took it upon me to mask them for removal in a few days or so. Bugzilla is unreachable at the moment, but I don't think an entry is needed for these 2. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Session/.desktop WM compatibility, DM unification
On Mon, 2006-03-27 at 00:03 +0200, Dan Armak wrote: > = Bugs overview (probably missed some): = > > #89870: long story, summary: .desktop files are installed in different > places. > KDE only reads the KDE ones, Gnome only the Gnome ones (and both use a small > common set). This doesn't really fit in the WM/DM issue afaics. The fact just is that the alternative installations roots Gentoo KDE uses aren't dealt with in the eg. the menu config files. > So each DE doesn't benefit from the other's apps (.desktop files aren't just > for menus but also for e.g. services/actions on mimetypes/etc). 'Lightweight' > WMs with a menu are forced to choose one of the above to display. (And if you > merge both, the result is currently very ugly.) The xdg menu spec has sufficient capabilities of dealing with the amount of .desktop files. We just haven't dealt with them because they aren't a real issue yet because of the non-default KDE installation paths on Gentoo. > #53517: xdm, kdm, gdm (don't know about entrance and such) each have their > own > set of a lot of configfiles: Xaccess, Xreset, Xservers, Xsession, Xsetup, > Xstartup, Xwilling... Obviously bad. > > Today some files are shared / not duplicated (gdm <-> xdm, kdm <-> xdm), but > the work is not complete. It seems gdm only has its own Xsession now, and if > people confirm this I can work on getting rid of all of kdm's separate files > as well. BUT I still need cooperation here because there might be some > features in kdm's files which would need to be merged into the common (xdm?) > ones. GDM has had just its own Xsession for a long time iirc. I think most functionality provided by these other X* files are login manager (xdm?) specific. The one real issue is Xsession. > > #26326: unifying scripts that run on X sessions startup/shutdown. A lot of > non-WM-specific stuff, e.g. starting ssh/gpg agents, lives (often duplicated) > in DM-specific or WM-specific scripts. This is the core of the problem, this needs to be fixed > #14872: unifying DM session scripts, handling of ~/.xsession, etc. The bug is > closed but I think some things mentioned there haven't been fixed. This is sort of the same as #26326 . I think the RH approach of using xinitrc.d as a place to unify startup scripts is a workable solution. I'd like the X11 teams input on this however, since the X11 /etc layout and history behind it is largely unknown to me. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Session/.desktop WM compatibility, DM unification
On Mon, 2006-03-27 at 22:25 +0200, Dan Armak wrote:
> Assume the install prefix problem is fixed somehow. What items are displayed
> in each WM's menu?
>
> Option 1: KDE only displays KDE apps, Gnome only Gnome apps. How do we decide
> what is displayed in both ('neutral' apps)
> Can the user edit the menu, and
> include some things we don't include by default, in a WM-neutral way? What
> should WMs other than KDE and Gnome display by default?
>
> Option 2: always display everything. Problems: huge menu. KDE and Gnome and
> others use different categorization. A change of the status quo, so user
> community should get a chance to veto. And when using descriptions as primary
> menu text (e.g. 'Text editor' instead of 'kwrite'/'gedit') some KDE and Gnome
> programs have similar or identical descriptions, which looks bad to new
> users.
I'm aware of the issues surrounding menus, but the spec gives a lot of
options. As said, we haven't dealt with it, because it is not a snag
that we hit currently.
I think we can basically have several menu setups fit for different
tasks/DEs and either let loginmanagers choose on startup or users choose
on install.
I don't know what the future plans are of KDE regarding it's slotting,
but if it intends to use syswide (fdo) specs like mime/icons the install
alternate root is going to be the main hurdle to tackle.
- foser
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [last rites] media-gfx/sodipodi
Hey, just added a mask for media-gfx/sodipodi. It has been forked into inkscape and sodipodi development subsequently has stagnated. I intend to remove sodipodi in about 7 days. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] up for removal timeframe
On Wed, 2006-03-29 at 18:55 -0500, Mark Loeser wrote: > With that being said, is there any reason that the package should be > removed so quickly? Not really, but in my experience packages up for removal are quite obviously so. Meaning that usually there's little question that it should go. In this case for example, there has been no upstream activity for a long time now (a year at least), the project got forked before that and now really has a second life as inkscape. I was even thinking about adding a move statement for it when removing. On the other hand, I don't mind waiting 30 days either. It's just that most removals right now give a 1-2 week period react time, I just kept to that. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] gtk2 use flag must die
On Sun, 2006-04-02 at 15:28 -0400, Mike Frysinger wrote: > last time i recall following the gtk/gtk2 stuff, the idea was that in the > future to move to a gtk/gtk1 situation ... but this was back when Spider was > The Man, so i guess people forgot about that That was never the case. We actually saw the gtk2 flag only as a transitional tool during the initial release of gnome 2, too bad it stuck around as long as it did. > > it should be more the question, if there's anyone supporting > > Gtk1 upstream with regards to security issues etc.. > > and when such a situation arises, the solution may to simply drop the > optional > support. such a situation has not arose, so using such hypothetical examples > is meaningless. Already security related issues have been dropped by upstream for the simple reason that it hasn't been maintained since the day gtk went 2.0 . The only reason there has been some minimal support are the bling distros like RH and the fact that Debian was stuck in the stone age. Let's be realistic, if an application hasn't been ported to gtk+-2 yet it is not maintained or it is an internal to some commercial business. I don't think gtk 1 will leave the tree soon, but at least we can try to make it unneeded on most users systems. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] gtk2 use flag must die
On Sun, 2006-04-02 at 15:16 -0400, Mike Frysinger wrote: > and if there are no bugs filed ? this sort of stance is like the "lets > remove > packages from portage because upstream is dead" ... it benefits no one Sure it does, in my experience unmaintained packages tend to depend on unmaintained libs, which depend on other libs in older slotted versions. Usually parts of such a dependency chain have open bugs, that have been open for years and that are not going to be solved by anyone, because frankly nobody cares about that old crap, but isn't bothered enough to try and remove it and all of its reverse deps and take the flak for that, because just one guy in this world is still a frantic user of said package and will let the world know within 3 months after it has been removed. If you find something that hasn't been updated in 2-3 years, you are bound to find a trail of bugs and tree garbage leading away from it. Get rid of it, keep it clean. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] gtk2 use flag must die
On Mon, 2006-04-03 at 00:43 +0300, Mart Raudsepp wrote: > Delaying GNOME-2.14 for non-GNOME packages using gtk2 USE flag is mildly > funny to me, too. These two things are not related, 2.14 is not delayed whatsoever. Jakub's call was just to get attention to the bugs and didn't originate from the gnome team at all. > Some two weeks have passed from 2.14 release, I would have expected it > to be in x86 at least a week ago... but I'm living in a utopian land. I don't know where these expectations come from, but we intend to iron out the major known issues before we put stuff in ~arch . 2 weeks is rather short for a volunteer team of 2-3 active people for something the size of gnome. It is the same sort of nonsense we got with earlier releases, where people expect things to be in stable the day upstream declares it release day. People seem to expect the impossible, if you come from Debian the Gentoo cycle seems perfect, but as soon people are used to Gentoo the complaining starts anew. Get a grip and try to help out in constructive ways. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] adding a code of conduct
On Mon, 2006-04-03 at 17:38 -0400, Mike Frysinger wrote: > i dont see how anyone can be against this (unless you're a terrorist!), For someone who's promoting 'ubuntu' like conduct, your choice of words is rather Patriot Act-ish. If this two-facedness reflects the intentions of people behind this semi-civilized means of minority-control, I'll pass on it. The wording of certain phrases in this 'code of conduct' is really dubious : specific enough to be used for any purpose and vague enough to hold none of those in control responsible. Take for example the 'Repeated disruptive behaviors..' paragraph. If you really want to make a serious attempt at a code of conduct, you keep it simple, you keep it clean. You let the community decide on contents and don't mix rules with punishments in one and the same document. If you guys really had understood the Ubuntu contract you would've never dropped this 'constitution' on -dev like this, especially not at this time (you know what I mean). - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] adding a code of conduct
On Tue, 2006-04-04 at 00:54 -0400, Mike Frysinger wrote: > you lost your sense of humor please go find it, END-OF-OFF-TOPIC-SUB-THREAD As usual your answer fails to deal with the real issues stated and zooms in on something largely irrelevant to the discussion. How typical. If someone lost anything here, it's credibility. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] adding a code of conduct
On Tue, 2006-04-04 at 01:51 -0400, Mike Frysinger wrote: > so we're clear, this thread was not started "because of Ciaran". in other > words, this is not just about Ciaran. i can think of other people who need > to be told to stop being a dick. So can I, after reading some of your reactions on this thread. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] slots and libraries.
On Wed, 2006-04-12 at 17:27 +0200, Paul de Vrieze wrote: > While this also does not stand any chance to win a beauty contest, this > would also be acceptable to me. The only thing I want is things not > starting to fail without a good reason. A new version of a library is on > itself not a good enough reason. It is just a matter of fact that a few upstream authors don't really get libtool versioning right, but to say a new .so nr. means a new slot version is wrong. Packages should only be slotted if every single bit of them is versioned, check glib, gtkhtml, etc. The proper course of action is making upstream aware of how they should do libtool versioning. Adding workarounds like preserve_old_lib* should only be a temporary measure. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites for dev-util/cccc
On Sat, 2006-04-15 at 02:54 -0400, Mike Frysinger wrote: > -3.1.4 now in portage Why did you add that, without adding metadata ? That is just wrong. It is better to remove it if there is no maintainer, you upping it without adding yourself as maintainer is no form of maintenance. This is exactly why we get complaints about a stale tree. I still say it should be removed in 30 days. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites for dev-util/cccc
On Sat, 2006-04-15 at 14:24 -0400, Mike Frysinger wrote: > and it helps no one to go around cutting packages that have no outstanding > issues with them Sure it helps keep Gentoo clean and up-to-date, the load of packages that are outdated are often unmaintained as well. The one leads to the other. Anyway, nobody would know about outstanding issues that popped up, because there is no maintainer to assign them to. > there was an outstanding issue with , but i resolved that How do you know you resolved it, you don't get bugreports on it do you ? I mean, you aren't the maintainer. And there is still the outstanding issue that it is unmaintained in Gentoo, are you going to fix that or not ? Otherwise it should be masked and removed. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites for dev-util/cccc
On Sun, 2006-04-16 at 16:42 -0400, Mike Frysinger wrote: > well the logical thing would be to go to bugzilla and search for "" ... > and guess what ? no more open bug reports I already did that when I wrote it, actually there still is an open bug for it. So I guess you didn't actually go trough these proposed steps yourself. Anyway, it is completely besides the point, because you or anyone else won't check a week or a month from now if there's bug filed against , that is what maintenance is about. > > I mean, you aren't the maintainer. And there is still the outstanding > > issue that it is unmaintained in Gentoo, are you going to fix that or > > not ? Otherwise it should be masked and removed. > > this is the same argument as already made and rejected ... Where was this rejected and by whom ? By you I guess ? That just doesn't cut it, errors made in the past are no reason to make them again in the future. > feel free to mask > and remove the hundreds of other packages that have no maintainer So now we do have your blessing ? is then up for removal as of this moment. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites for dev-util/cccc
On Tue, 2006-04-18 at 14:11 +0100, Chris Bainbridge wrote: > Are you suggesting that all packages with long standing open bug > reports should be removed? There are thousands that fit that > description. If not, then what is your definition of "maintained"? It > could be argued that since Mike fixed the bug, it is maintained, > even though he isn't the maintainer. Likewise, there are hundreds of > packages that have a maintainer listed, or are assigned to a herd, > where bug reports are essentially ignored. Should those also be > removed? No, I don't know why you jump to that conclusion. There are people responsible there, you can contact them if you feel things are ignored. Or better, you can try and help out on those outstanding bugs and solve them, so the maintainers would only need to apply a fix. > Did you read the previous discussion link I provided? The argument has > been rejected in the past because it would lead to hundreds of > otherwise working packages being removed. You get a lot more out of that thread than I do, I guess it's a matter of interpretation. > Maybe you aren't a native English speaker; it was clear from Mike's > post that he would rather you didn't go ahead with removing hundreds > of packages. I don't know how this relates to my mother tongue, but I'm not speaking of a mass removal or anything. You make it into that all the time, maybe you should let go of that mindset. I think that if we come across cases like this the goal should be to clear up the confusion. Either find a maintainer or clean it out. That way eventually 'hundreds' becomes 'dozens' of unmaintained packages and maybe some day even less, it's a gradual process. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites for dev-util/cccc
On Tue, 2006-04-18 at 10:22 -0400, Mike Frysinger wrote: > either you have a policy of cutting unmaintained packages or you dont ... you > cant have some vague middle ground Hide behind policy if you can't do it with common sense. The policy is to add valid metadata.xml data to packages that do not have it, that has not been done here. Adding 'maintainer-needed' (or 'no-herd') as a way out is not sufficient and was never intended policy when metadata/herds got introduced. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites for dev-util/cccc
On Tue, 2006-04-18 at 10:53 -0400, Mike Frysinger wrote: > dont know what policy you're referring to seeing as how we dont have any > concerning unmaintained packages Still hiding... c'mon you are better than this. > sure, for new packages ... isnt a new package The policy concerning metadata makes no difference between new/(un)maintained. It just says that every package should have one. So if you come across a pack that doesn't and you touch it, you need to fix that. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites for dev-util/cccc
On Tue, 2006-04-18 at 17:56 +0300, Philippe Trottier wrote: > If no one has an objection, I'll pick up that package, I think it is fun, > never > tought I'd use it, but I have so much code written I'd like how much I have > really done. > > If there is no objection I'll make the update needed, create metadata, make > repoman happy. Go right ahead. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Thu, 2006-06-08 at 11:12 -0400, Alec Warner wrote: > It is my understanding the the Sunrise overlay is not open to "anyone to > commit", so it is not a contrib/ The sunrise project is the owner of > the overlay and they are responsible for it's contents. The people > commiting are responsible for what they commit. The point of the > Sunrise project as I understand it is to aid in the development of > ebuilds in maintainer-wanted, such that they may improve and be added to > the tree; as well as to give frequent 'not quite a dev' and 'I don't > have a bunch of time but would like to help' people a place to commit to. I don't think the problem with maintainer-wanted ebuilds is that they are crappy, but that there is no dev willing to maintain them and ensure their quality over time. 'sunrise' (who came up with that name ? cheap asian poetry attempt) doesn't change that by adding it to an 'official' overlay. Instead of tackling the real problem -the lack of maintainers to deal with all requests- 'sunrise' is trying to create a backdoor for unreliable maintained stuff to enter the tree. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.
On Tue, 2006-06-13 at 11:10 -0500, Grant Goodyear wrote: > Over the years we've had a fairly consistent stream of suggestions that > we should open up the e-build maintaining process to users instead of > just devs. The main arguments against it are the security issues and an > expectation that it would add to developer workloads. The former is > certainly a real problem, although signing (assuming a reasonable > web-of-trust) could mitigate that some (at least we'd know who to > blame). The latter, however, is conjecture, and the only good way to > verify it would be to actually try it and see what happens. Oh, and > there's also a very real fear that if things go horribly wrong, that > Gentoo's reputation would suffer quite badly. Perhaps I'm naive, but I > tend to think that if we were to advertise project sunrise as > experimental, temporary, use-at-your-own-risk, and > might-break-your-system, and even put it on hardware without a > gentoo.org address and add a portage hook that warns whenever the > project sunrise overlay is used, then our reputation isn't really likely > to suffer even if it's a complete disaster. > > So, Chris, what have I failed to address that would make this a really > bad idea? That this describes break-my-gentoo, that it is as old as Gentoo itself and that it only creates problems for the 'supported' tree : the unexplained bugs, the weird errors, the continuous suspicion devs need to have on reported errors. Keep that stuff separated, don't mingle it with Gentoo. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Sunrise: way forward, semi-official, review
On Sat, 2006-06-17 at 17:05 +0200, Stefan Schweizer wrote: > And that is what we are doing now. We have moved the overlay to > gentoo-sunrise.org to analyze, improve and hash out the details. So the > Sunrise project is now "semi-official". While being an official Gentoo > Project run by Gentoo developers it is not currently hosted on gentoo.org. It doesn't become an official Gentoo project by being run by 'official' Gentoo developers. There is no such thing as 'semi-official' and as such the move away from the gentoo domain indicates it has nothing to do with Gentoo and makes this part of the several third-party Gentoo ebuild sites around. Good luck with that, but don't try to put a Gentoo stamp-of-approval on it. - foser signature.asc Description: This is a digitally signed message part
[gentoo-dev] Sunrise contemplations
Hello, since I've not really been involved in the whole Sunrise discussion I'd like to give my view in a condensed form, instead of spreading it out over 20 replies in the ongoing discussion. Also I hope to summarize the main points a bit, but I know this mail is far from objective and as such not much of good summary. There are really 2 big discussion points in the whole Sunrise discussion as far as I can see. First there is the purpose of Sunrise and how that ties into Gentoo and secondly there's how it came into being. I would also like to discuss how I think Sunrise will influence the work of developers. Let's tackle them one by one. * The purpose of Sunrise The purpose of Sunrise as far as I can distill them from their goals : 1. Make stale ebuilds in bugzilla accessible 2. Provide some level of QA for user contributed ebuilds in bugzilla 3. Lower the step to becoming a developer Let's handle them. 1. Stale ebuilds are often stale for a reason, there is obviously not enough interest to add and maintain them. Not just on the developer side, but also on the user side. If someone really cared enough he/she would go trough the process of becoming a dev. As far as I know most maintainer-wanted stuff just belongs in the category WONTFIX, but the real problem is telling that to the user who sweated on it. I think most of the devs have gone trough a close-reopen cycle on some ebuilds that really added nothing useful to the tree and know how uncomfortable this can make you feel. Then what is a solution to these ebuilds ? I for one would like to see them go upstream, like rpm's and deb's . That would make it clear that these ebuilds are not Gentoo approved, but would provide a starting point for the user who would want to use such a package. I think that was always the main idea when overlays got introduced to portage. Sunrise just lowers the step to get these often mediocre ebuilds, people can get them right now, just not as easy. 2. QA for ebuilds is not just a question of making a package build, but also knowing what it does and how it would tie into Gentoo. The fact that some ebuild is semantically correct doesn't mean it is doing the right thing. Very few of the newly proposed ebuilds I handled and eventually committed was actually without major flaws. This was because the submitters lacked specific knowledge of either the eclasses to use and the environment it belonged in. In my case : any gnome ebuild fits in a larger set of applications/libraries that got more complex as time went by, it is not trivial to understand all the interactions that take place. Even Gentoo developers not in the gnome team make serious mistakes in this sense in my experience. Therefore I do not believe that QA for a tree that is as extensive as Sunrise done by a few 'official' developers amounts to much real world quality. 3. Although I agree Sunrise may lower the step to becoming a dev, I doubt it will have a serious positive impact on our developer base and as such there is no reason to support Sunrise officially. I think the people attracted to Sunrise development are the ones that fall in the category 'want to be there, but don't really have the time/skills'. Those people will not evolve to real developers; they either will stick it out in Sunrise for a short while or keep to a very small subset of it. My prediction is that Sunrise will see a high turnover of 'developers', either because they are there for one specific package (probably fresh and included in the main tree when mature) or find out they lack the time to really invest in learning the full extent of ebuilding. Also 'junior' devs on Sunrise might not take that extra step towards devhood because they got the influence they want, as such we might lose out on devs that never develop beyond Sunrise contributors. As a developer I would not really think of Sunrise developers any different than someone coming 'fresh' to Gentoo developing. I would still require them to work on real bugs for a good while to see their intentions/devotion over time before I would even consider submitting them for real developership. In that sense Sunrise would only lengthen the time a wannabe dev has to spend in the no-mans land between active user and official developer. In conclusion these 3 points come together here : being a dev is not about adding new ebuilds to the tree, it is about maintaining what is already there. Dealing with bugs and users. That aspect of Sunrise is not at all tackled in its goals. What are the longterm prospects of ebuilds in the Sunrise tree ? That is what QA is about, providing a stable base to work on. I do not think that devs who mainly add ebuilds and new packages to the tree are good devs, the real job is maintenance and bughandling. In that sense Sunrise might be giving the wrong impression to wannabe devs. * The rise of project Sunrise Now for the second big point concerning Sunrise : how it came into being. I checked back on the initi
[gentoo-dev] The gnome king is dead, long live the gnome king
Hello dear followers, tonight after a some deliberation I have decided to step down as gnome lead in favor of AllanonJL. As far as I am concerned AllanonJL has been the acting lead for quite a while now, while I was too busy to devote much time to Gentoo and as such it was the only logical next step. This doesn't mean I will leave Gentoo, it just means I'm going to get myself out of a few herds and positions I don't belong in anymore. Trying to focus on the things I can still do to keep Gentoo the one distro I love to use. I'd like to say thanks to Spider, Obz, Leonardop, Dang, Compnerd, AllanonJL, Zaheer and all the other contributors over time on bugzilla and IRC for bringing gnome on Gentoo where it currently is. Also I'd like to invite everyone interested in helping gnome on Gentoo to join #gentoo-desktop on freenode IRC, mail us directly or triage bugs on bugzilla. We can certainly use more help on pretty much any level, from user-testing to full blown fresh developers getting their hands dirty. thanks for your time, Marinus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Sunrise contemplations
On Tue, 2006-08-01 at 16:05 +0200, Kevin F. Quinn wrote: > > 2. [...] Therefore I do not believe that QA for a tree that is as > > extensive as Sunrise done by a few 'official' developers amounts to > > much real world quality. > > I would expect that over time, the Sunrise developers will learn more > and more how to write quality ebuilds (as hopefully do we all). Since > they'll be working with a diverse set of stuff, they could become better > than most devs at this. Remember that since they have custody of the > stuff in the Sunrise overlay, they will be hit with whatever issues > arise from their work. I expect the developers involved to be able to write quality ebuilds right now, otherwise they shouldn't be developers. However, I don't expect them to write quality ebuilds for everything in the tree, there are a lot of packages that need specific knowledge to make a correct ebuild. That is why we got the herd system, that is why we have a couple of hundred ebuilders who all have their own specific parts of the tree to take care of. > What it does give you is a track record you can look through - in much > the same way you might have watched what someone did on bugzilla or > IRC. Indeed I'd suggest that the history in Sunrise SVN would be > useful to indicate whether someone is learning how to write ebuilds > properly, or just continues to make the same errors. Ebuilding is such a small part of the job I wouldn't seriously take it into account, to me much more important is the bughandling skills of a potential developer. Is he/she able to distill the right information from a report, ask for the right additional info and come to a practical and neat solution ? - Marinus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Sunrise contemplations
On Wed, 2006-08-02 at 12:00 +0200, Thierry Carrez wrote: > So you can create projects by creating a directory in > gentoo/xml/htdocs/proj/en, you don't have to announce it (but it's > polite to do so), and it may well conflict with other projects, that's okay. > > You can't blame them for following the right rule. You can blame the > rule, though. I deliberately added '(GLEP?)' with question mark because I know projects in general do not fit the GLEP structure. However, in this case the project has potentially the kind of impact on the tree and other developers that discussing it beforehand would've been the right thing to do. The way the announcement was written makes me think the developers involved in the project were well aware of this. It seems to me creating a project is now officially a loophole to do as you please under the umbrella of Gentoo. - Marinus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Handling of LINGUAS
I recently ran into a similar issue regarding font ebuilds using LINGUAS to select fonts to install (see acroread-asianfonts). I personally think this is not the way to go, since LINGUAS is about language, not script, support. Any comments on that issue ? - foser -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Committing straight to stable
On Sun, 2005-04-24 at 21:29 +0100, Paul Waring wrote: > Why not have a three strike rule - anyone who commits something > straight to stable 3 times in a given period (say 6 months) has their > CVS access revoked. It's not California here. You completely ignore the fact that some people commit more than others and as such are more likely to trip over such a rule anyway and the people who do commit a lot are usually the same people you don't want to revoke the access from. It's just a reminder, don't make up some unenforceable policy just because people make mistakes from time to time. 1 strike, you are out. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Proposal: sys-pam category
On Sun, 2005-06-05 at 18:34 +0200, Jonas Geiregat wrote: > I do agree with you but some package just have completely wrong place > within portage, such package placements migh confuse the user. > To give an example: mzscheme was placed in dev-lisp while portage had a > dev-scheme directory. The current set-up isn't user-browseable anyway and hasn't been for a long time. I don't think the focus should be on correcting that in the tree, the user tools should be improved really. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ekeyword and ordering
On Tue, 2005-06-07 at 18:18 -0400, Aron Griffis wrote: > Ciaran would have something to say about this, along the lines of some > packages sitting idle in ~arch state because the maintainer isn't > really paying attention. In that case, who can really blame an arch > team for moving ahead on their own? Arch teams still have no reason to move ahead if they did not try to contact the maintainer(s). Sure, some packages may get 'lost' in large herds at times, but then the arches who do notice that particular pack have an extra responsibility to make the maintainer aware of it's state. Then if the maintainer still remains unresponsive there is sufficient reason for the arch to act on their own. In short, arches have to be able to strongly defend their actions if they are to interfere with the maintainers responsibilities. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: ekeyword and ordering
On Mon, 2005-06-06 at 18:43 -0400, Michael Sterrett -Mr. Bones.- wrote: > The games team has been alphabetizing keywords for some time. Just an > added datapoint. The fact that several developers have been doing things the 'alpha way' for no particular reason is no reason in itself to adopt this as policy. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ekeyword and ordering
On Tue, 2005-06-07 at 00:47 +0200, Lars Weiler wrote: > * Aron Griffis <[EMAIL PROTECTED]> [05/06/06 18:26 -0400]: > > alpha > > - > > - looks nicer (subjective) > > - easier to tell at a glance if a given keyword is in the list > > I'm for this. You can easily compare two ebuilds' KEYWORDS, > when you have the same order. I assume you mean comparison between versions, what happens a lot when doing ebuild updates. In that case order doesn't matter as long as it stays consistent. What happens right now is that order is far from consistent with some developers applying their own devised alpha ordering whenever they touch a package. So the problem is not so much what ordering is preferable, but that people change order without discussing it. > maintainer's arch should be stored in the metadata, if there > is a need for. Maintainer's arch could be ebuild/slot specific. I'm not yet convinced metadata is the right place. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ekeyword and ordering
On Tue, 2005-06-07 at 22:58 +0200, Danny van Dyk wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Luca Barbato schrieb: > > Stephen P. Becker wrote: > > > >>alpha++ > > > > > > alpha++ > > > once again, alpha++ It's not a vote, it's a discussion. You guys--. As vapier indicates he's the whole reason this ever became a problem. He was the one who started arbitrarily ordering keywords around creating a keywords mess for people who did depend on order to perform tasks. I guess the lesson here is if you just do things 'your way' (wr/l)ong enough, people pick it up and it spreads. The point is that with his reordering implicit information was lost for no particular purpose. There was no added value in ordering keywords, there's was no reason whatsoever to make the ordering inconsistent within packages, it was an utterly pointless exercise in creating more traffic on the servers. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ekeyword and ordering
On Thu, 2005-06-09 at 11:50 -0400, Stephen P. Becker wrote: > Whoever said we were voting? I was just showing my support for > alphabetical keyword ordering. Remember, alphabetical keywording is > *already* implemented in ekeyword, and we are discussing whether or not > to revert it. As the threadstarter indicated, this was done without discussing it and in the knowledge that there was no agreement on this issue. As said before, the fact that something gets done some way, doesn't mean it's right to do it that way. > foser-- In the response to that particular expression -especially by the 'guys' implied- you can see at least you try to defend your position now, that's more discussion like. > If everyone starts using ekeyword now with the alphabetical ordering > built in, everything will be consistent, and there shouldn't be a problem. See earlier replies : unneeded arbitrarily introduced inconsistency. I don't know why people are defending that move, even vapier indicates that there really is no reason to do it alphabetically, except maybe that he now knows to look in the keywords string, which is of course a bit far fetched with all arch keywords not being set for all different packs (so he still has to look at different points in different packs) and was not brought up as a defence of his particular move at the time he started doing this. > I guess by "creating more traffic" you mean the one time when updating > the ebuilds with the new ordering during rsync for each user. Even if > this is significant over the whole tree, once everything is updated with > keyword ordering and everyone has done an emerge sync, there won't be > any more trouble, and we can just stay happy with the consistent > alphabetical ordering enforced by ekeyword. Oh no doubt, I'm concerned about the inconsistency mostly. The maintainers arch is a concept that I do not necessarily associate with the keywords ordering anymore (although it may have been a reasonable indicator in the past), it actually really makes this discussion fuzzier than it has to be. My point is more about how this got 'introduced' as a mindset and that such unguided behaviour gets reinforced by this discussion, now up to IUSE ordering changes and next we'll tackle inheritance order. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ekeyword and ordering
On Fri, 2005-06-10 at 12:33 -0400, Mike Frysinger wrote: > consistency is one advantage (which i'm sure you'll say is pointless) I've been the one talking consistency, something you've knowingly broken for a long time here. > as for the rest of the ramble you posted here it's really quite wrong ... you > must have missed the class where they teach you the ins & outs of > alphabetical sorting because it really does allow you to quickly scan a list > and figure out if the item you're looking for is there or not First of all this is speculative and may not apply to this particular situation to begin with. Arch keywords are concepts and as such may not primarily be dealt as a an alphabetical list but as words in a sentence, there is no abc order in sentences. If you have to search, you'll have to scan anyway, exact position is not a guarantee for certainty because not every pack is available on every arch, it's not like you can go without scanning. Last, this only holds to some extent true for people in countries with alphabetic scripts, outside that limited part of the globe people are not as proficient in ordering alphabetically. I think you are just going out of your way to justify something you've done for ages for no other reason than your own preference. But I must grant you, you come with better arguments now than you've ever done in the past concerning this issue. Of course you had a lot of time to think about it. > if you ever had to do arch-specific KEYWORDing on a frequent basis (and i'm > 99% sure you have nfc we support other arches than x86 if we use > arch-specific breakage in GNOME depends as any sort of track record), If there was ever arch specific breakage -this btw is a baseless claim, so it shouldn't have been put up here, but I guess that's what populism is about-, then it is most likely because someone screwed up the ordering inside one package dir, making it inconsistent and as such a pain to deal with. Now for my list of 3 letter IRC abbreviations to make a point : wtf, wth, imo, lol, nfw, fyi, otw. Keep it clean. > you'd > know that scattered KEYWORDS is a pita to deal with ... i've seen cases where > a specific arch was duplicated in KEYWORDS; once near the beginning and once > near the end ... normally it wasnt anything bad, but there was a case where > one KEYWORD was stable while the other was unstable Again something I'd only expect to happen in cases where someone is reordering keywords at will inside a package. A certain amount of uncertainty in order actually might prove to be effective in having everyone who deals with keywords actually really check all keywords and not depend on assumptions, which both 'error' cases you mention seem to be caused by. Anyway, my feud is with the inconsistency within packages and how it got introduced, not with whatever order is preferred by some. Now tell me how this happened again? - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ekeyword and ordering
On Sat, 2005-06-11 at 17:28 +0900, Jason Stubbs wrote: > By lack of policy? Well I'm sort of concerned by the fact that I have to state the obvious, but really by people reordering them for no reason. It's not the lack of policy that is the problem here, it's the use of some self defined not uniform policy. There was no need for policy or regulation until some people set their own rules to play by, I really don't understand why that move gets defended by anyone. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: RFC: qt.eclass
On Fri, 2005-07-01 at 18:33 +0300, Dan Armak wrote: > > calling a function in a global scope is a bad idea. it leads to lots of > > unneccessary (and timely) computations > Necessary in the case of kde split ebuilds. Take a look at > kde-functions.eclass::deprange(). So you create functions to do things portage really should do ? Wouldn't pushing the portage team to finally implement a major feature like depranges be a better idea ? The gnome team has been dealing with these things forever, but we have a preference for a global solution instead of inventing our own wheel. - foser signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: RFC: qt.eclass
On Fri, 2005-07-01 at 11:15 +0200, Paul de Vrieze wrote: > Wouldn't this be a good time to implement actual dependency ranges in > portage. Btw. I normally use the following hack that portage might > actually be made to understand: > > DEPEND=" signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ekeyword and ordering
On Sat, 2005-06-11 at 14:46 -0400, Aron Griffis wrote: > foser wrote: [Sat Jun 11 2005, 04:15:22AM EDT] > > Arch keywords are concepts and as such may not primarily be dealt as > > a an alphabetical list but as words in a sentence, there is no abc > > order in sentences. > > Foser, no offense intended, but you started out in this thread making > a couple good points. However this is completely off the wall. The > KEYWORDS list isn't a sentence. The post I replied to was full of far-fetched reasoning, I just made a similar post. > > If you have to search, you'll have > > to scan anyway, exact position is not a guarantee for certainty because > > not every pack is available on every arch, it's not like you can go > > without scanning. > > Doesn't change the point that scanning in alpha order is easier than > scanning append order. > > > Last, this only holds to some extent true for people > > in countries with alphabetic scripts, outside that limited part of the > > globe people are not as proficient in ordering alphabetically. > > AFAIK, all Gentoo developers are fluent English speakers, even if for > some it isn't their first language. Fluent, right. Try some of the cjk people. Not really. Anyway, it doesn't matter, if you didn't grown up with the alphabet, you really don't know the ordering by heart like western people do. In spoken language it doesn't matter what the order is, it is totally arbitrary. Also, realistically it's probably only 1st language for maybe half of the devs these days. > > A certain amount of uncertainty in order actually might prove to be > > effective in having everyone who deals with keywords actually really > > check all keywords and not depend on assumptions, which both 'error' > > cases you mention seem to be caused by. > > Maintaining a behavior that encourages mistakes, in hopes that the > extra effort required will prevent those mistakes? This cannot > possibly be a good approach... You assume here suddenly that it encourages mistakes, there is no such evidence presented here or ever was, there is however evidence to the contrary where the continues shifting of orders (within packages) caused problems (the thing I disliked about this whole situation to begin with). I actually suggest that the opposite might be true, a certain degree of uncertainty (between packages) prompts caution and might prove to be more error-free. Sure it's all a bit far fetched, but so was the post that suggested that there was some grand ergonomic idea behind this arbitrary change. I did not in this thread challenge the ordering (who made that up?), I challenged the way it got 'introduced'. I just got ticked off by the 'scientific basis' that suddenly was presented as the big reason behind it. To recap, it was the arbitrary /ordering change/ of a select group of individuals that created problems within packages, not the one or the other /order/. - foser signature.asc Description: This is a digitally signed message part
