Re: [gentoo-dev] Add support for rsync patches
On Tuesday, February 04, 2014 22:25:00 Jauhien Piatlicki wrote: 04.02.14 20:53, Donnie Berkholz написав(ла): On 12:48 Tue 28 Jan , Michał Górny wrote: Dnia 2014-01-28, o godz. 11:59:33 Jauhien Piatlicki napisał(a): net-misc/rsync upstream provides a tarball with additional patches that can be useful for some users. I think it would be nice to have them handled automatically by portage using e.g. USE_EXPAND. Of course these patches can be just picked by user an applied using epatch_user, but I think it would be much easier and convenient to do this with just setting a use flag. ...and what do you want from gentoo-dev@? You need someone to file the bug for ya? This is not the level of friendliness that is going to welcome potential new contributors into our community. I'm reading this list for a long rime, so I'm quiet acquainted with this level of friendliness. So do not mind. being used to it does not make it acceptable I've wrote this list because potential changes I want to do include adding of new USE_EXPAND that should be discussed here anyway. And there can be reasons why this have not done, that I'm not aware of, and maintainer of rsync or somebody else could comment here. Anyway I still have not ended with those changes and hence still have not posted a bug. So do not mind once again. ;-) i don't see any patches in rsync-3.1.0. i'd be hesitant to add support for them even if they were there ... i added epatch_user to the ebuild years ago though, so you largely should be able to get the same functionality (albeit with a bit ore footwork on your side). -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
On Tue, Feb 4, 2014 at 10:15 PM, Steev Klimaszewski st...@gentoo.org wrote: You know what - this is pure and utter bullshit. Keeping it around for slower arches does NOT block progress. I have intimate knowledge with what ACTUALLY happens when people pull this bullshit - and that is a system that I can no longer actually work on. It isn't like deleted ebuilds magically disappear. You can always dig them out of CVS and stick them in an overlay. It just isn't the maintainer's problem. Any dev can also co-maintain a package and keep the old version around. Main issue I could see with that is stuff we don't stick in cvs/git, like large patches and non-upstream distfiles. That really does need a better solution as has come up before on-list, but I think this is really a different problem. I'm now going to take a break from Gentoo development because this thread has seriously caused my blood to boil based on comments from the peanut gallery (you) where things don't actually affect your day to day work, but your actions do affect mine. Email threads really aren't the venue for decision-making. They're a great place to suggest ideas, and you have to look at them that way. I've barely skimmed half the messages in this thread, mainly to look for actual solution suggestions, and sometimes the first reply to one contains some useful criticism. It looks like QA has actually intervened with an intended solution. If you don't like it anybody can ask the council to intervene (looks like there is less than a week to the next meeting). Simply debating the issues back and forth on an email list really isn't like to change things much, and as you and others have pointed out it can be an extremely frustrating activity. Rich
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
05.02.2014 09:41, Tom Wijsman пишет: On Tue, 4 Feb 2014 19:28:28 -0800 Matt Turner matts...@gentoo.org wrote: I've drafted and thrown away so many replies to Tom in this thread. What do you want to tell us about this thread? Thanks for putting up with it, but it's a huge waste of your time. Why? This discussion has a goal which we are trying to fulfill; if the current solution the QA team has formed is insufficient, feel free to let us know why such that we can reshape it to fit the situation better. Maybe we should change our sentence about dropping last stable keywords for slow arches ONLY if version, still marked stable for them is seriously broken? And removing old version ONLY on security issues or maintainer discretion. Cause it seems that not everybody agrees with policy that we are trying to make. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
On Wed, 05 Feb 2014 15:41:58 +0400 Sergey Popov pinkb...@gentoo.org wrote: Cause it seems that not everybody agrees with policy that we are trying to make. Because it's impossible to create a simple policy to solve complex problems. It's a waste of time and it's going to break more than you set out to fix. Use common sense = communicate = resolve issues individually. If you can't figure things out amongst yourselves, put the matter to this mailing list instead of bringing it to some kind of tribunal - more visibility gets you more attention from volunteers and gets actual work done more quickly. Gentoo users and developers (should) just want to scratch their itches - not have endless arguments about them. Can we go back to fixing bugs now? Regards, jer
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
On Wed, 05 Feb 2014 15:41:58 +0400 Sergey Popov pinkb...@gentoo.org wrote: Maybe we should change our sentence about dropping last stable keywords for slow arches ONLY if version, still marked stable for them is seriously broken? What does seriously broken mean? Maintainers will see that different; besides that, note that a part of that breakage is invisible, another part is left unfixed in a growing pile of bug fixes to be backported. Why do we drop other reasons (like maintenance costs, ebuild age, ...)? Let me quote some extracts from WilliamH's original mail ([...] snips): It is becoming more and more obvious that we do not have enough manpower [...], to keep up with stabilization requests. [...] this was affecting important packages and I felt that the arch teams should step up [...]. The arch team member disagreed unless the issue is a security bug. Keeping old software in the stable tree, I think we can agree, isn't good because newer software, besides having new features, will have bug fixes. Besides those already mentioned, there's one that didn't came up later: arch team members disagreeing to do important packages is a big concern. And removing old version ONLY on security issues We already do this by masking the version, then later removing it; given that stabilization is in a very slow state. Or at least, I hope we do... or maintainer discretion. The policy reads The maintainer may -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
On Wed, 5 Feb 2014 12:58:59 +0100 Jeroen Roovers j...@gentoo.org wrote: On Wed, 05 Feb 2014 15:41:58 +0400 Sergey Popov pinkb...@gentoo.org wrote: Cause it seems that not everybody agrees with policy that we are trying to make. Because it's impossible to create a simple policy to solve complex problems. Why is it impossible to do that? It's a waste of time Introduction of the complex problem is also a waste of time; should we stop stabilizing because of that? No, we'll waste our times instead. Let's waste it efficiently while we're at it, instead of holding up important packages with stabilization of packages that don't need it; it can turn that waste of time in much more useful time. and it's going to break more than you set out to fix. It's going to fix more than what was set out to break. Use common sense = communicate = resolve issues individually. Use proper reasoning = discuss respectfully = resolve in team spirit. If you can't figure things out amongst yourselves, put the matter to this mailing list That is exactly what was done here. instead of bringing it to some kind of tribunal - A tribunal is needed for decision making that leads to a resolution. more visibility gets you more attention from volunteers and gets actual work done more quickly. Gentoo users and developers (should) just want to scratch their itches - How many people have joined the arch teams since this thread? How many people have left since this thread? What about compared to the last time we had a thread like this? And the times before that? not have endless arguments about them. In respectful discussions arguments are not endless; besides that, a policy is in place now which prototypes one side of the arguments. If that is found to break things (with evidencing commits), or there is sufficiently backed up reasoning or a reasonable group of people objecting; then I'm pretty sure it can be turned around through QA, or when QA insists on not cooperating it can be done through the Council. Can we go back to fixing bugs now? Yes, here are 157 interesting open bugs filed more than 3 months ago: https://bugs.gentoo.org/buglist.cgi?f1=creation_tskeywords=STABLEREQkeywords_type=allwordso1=lessthanquery_format=advancedresolution=---v1=2013-10-05 Which are part of 559 open bugs filed all time (+ 31 missing STABLEREQ): https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMEDbug_status=CONFIRMEDbug_status=IN_PROGRESSfield0-0-0=keywordslimit=0type0-0-0=substringvalue0-0-0=STABLEREQ On top of that there are a lot more versions that are considerable for stabilization; which can be identified using `iamlate`, I guess just this mention here might get some people to check up what they maintain. Can we do something about our growing queue when fixing is insufficient? https://bugs.gentoo.org/chart.cgi?category=-All-datefrom=dateto=label0=All%20Openline0=320name=320subcategory=-All-action=wrap PS: As a bonus, here's a nice view of our stabilization queue over time: https://bugs.gentoo.org/chart.cgi?category=Gentoo+Linuxsubcategory=Keywording+and+Stabilizationname=639label0=All+Openline0=639datefrom=dateto=action-wrap=Chart+This+List Notice how the graph goes down near the dates the threads were made; although, if you would draw an average it would appear to be growing. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
[gentoo-dev] Re: dropping redundant stable keywords
Tom Wijsman posted on Wed, 05 Feb 2014 13:58:22 +0100 as excerpted: Can we do something about our growing queue when fixing is insufficient? https://bugs.gentoo.org/chart.cgi?category=-All-datefrom=dateto=label0=All%20Openline0=320name=320subcategory=-All-action=wrap PS: As a bonus, here's a nice view of our stabilization queue over time: https://bugs.gentoo.org/chart.cgi?category=Gentoo+Linuxsubcategory=Keywording+and+Stabilizationname=639label0=All+Openline0=639datefrom=dateto=action-wrap=Chart+This+List Notice how the graph goes down near the dates the threads were made; although, if you would draw an average it would appear to be growing. Both those links give me this: Sorry, you aren't a member of the 'editbugs' group, and so you are not authorized to use the New Charts feature. =:^( -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] February 2014 KDE team meeting
Hello all, The next KDE team meeting will take place on Feb 20 at 1900 UTC in #gentoo-meetings. Our agenda (yet to be filled in) can be found at https://wiki.gentoo.org/wiki/Project:KDE/Meeting/2014-02. All are welcome to attend. Chris Reffett signature.asc Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs
These packages are not used by anyone in the KDE herd, and they are not KDE-related, so they are now up for grabs. There are a few bugs open, but nothing major. net-misc/csync net-misc/mirall
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
Against my better judgment... On Wed, 2014-02-05 at 05:55 +0100, Tom Wijsman wrote: On Tue, 04 Feb 2014 21:15:47 -0600 Steev Klimaszewski st...@gentoo.org wrote: On Wed, 2014-02-05 at 02:48 +0100, Tom Wijsman wrote: On Tue, 04 Feb 2014 19:35:22 -0600 Steev Klimaszewski st...@gentoo.org wrote: Alright, well, I've tried my best, I give up. Instead of having something working we should just remove ebuilds of working packages. s/should/could/ s/ebuilds/stable keyword or last stable version/ It is at the maintainer's discretion; and such decision is to make it possible for a maintainer to move on when he or she can no longer guarantee a working ebuild, to stop being progress-blocked by it. You know what - this is pure and utter bullshit. Why is this pure and utter bullshit? Because I'm attempting to have a discussion with a brick wall. Keeping it around for slower arches does NOT block progress. Why is keeping it around for slower arches not blocking progress? Let's see... having the software at least available, versus not having access to it at all... which one is progress... THINK TOM THINK. I have intimate knowledge with what ACTUALLY happens when people pull this bullshit - and that is a system that I can no longer actually work on. That is also what happens when a maintainer keeps around old versions, as well as old bugs and support for those old versions; as by doing so, the attention towards newer versions is lost which causes much huger breakage than the one you have just brought up. Manpower is limited. And we attempted to come up with a solution for this, however due to the wording of a page on the interwebs that solution is 100% unacceptable *to you*, a person who is unaffected by it. And instead of working towards a fix that actually works for people who are ACTUALLY affected by the shitty policy, you hide behind definitions and pedantry. Why do you think this about the current and/or suggested solution(s)? I'm now going to take a break from Gentoo development because this thread has seriously caused my blood to boil based on comments from the peanut gallery (you) where things don't actually affect your day to day work, but your actions do affect mine. Why? How and why are your actions affected by the QA team's actions? Not the QA team's actions. YOURS. YOUR actions and responses in this thread. And the fact that the QA team allows you to continue to be on it, despite your obvious lack of interest in ACTUALLY having quality assurance. My actions are affected by it because I have to continue to attempt to discuss the issue with others who actually give a shit, and you just swoop in and say no, that absolutely is unacceptable as a solution (even though it doesn't affect me!) because this page here says that it can't - we can change that definition if you'd like. Instead of the line saying: The -* keyword is special. It is used to indicate package versions which are not worth trying to test on unlisted archs. Would changing it to read The -* keyword is special. It is used to indicate package versions which are not for use on unlisted archs. Would that make it acceptable?
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
On Wed, 2014-02-05 at 05:52 -0500, Rich Freeman wrote: On Tue, Feb 4, 2014 at 10:15 PM, Steev Klimaszewski st...@gentoo.org wrote: You know what - this is pure and utter bullshit. Keeping it around for slower arches does NOT block progress. I have intimate knowledge with what ACTUALLY happens when people pull this bullshit - and that is a system that I can no longer actually work on. It isn't like deleted ebuilds magically disappear. You can always dig them out of CVS and stick them in an overlay. It just isn't the maintainer's problem. Any dev can also co-maintain a package and keep the old version around. Main issue I could see with that is stuff we don't stick in cvs/git, like large patches and non-upstream distfiles. That really does need a better solution as has come up before on-list, but I think this is really a different problem. This is true, and normally I would have no problems digging out an old ebuild, although in this specific case, the old git ebuild will not work, and any ebuild that relies on the new git eclass will not work either... I understood the reason for the change, and it was and is definitely an unfortunate turn of events, though I finally opened a bug about it so we can hopefully track down why git 1.8+ doesn't work on arm uclibc (it works fine on x86/amd64 uclibc). I'm now going to take a break from Gentoo development because this thread has seriously caused my blood to boil based on comments from the peanut gallery (you) where things don't actually affect your day to day work, but your actions do affect mine. Email threads really aren't the venue for decision-making. They're a great place to suggest ideas, and you have to look at them that way. I've barely skimmed half the messages in this thread, mainly to look for actual solution suggestions, and sometimes the first reply to one contains some useful criticism. It looks like QA has actually intervened with an intended solution. If you don't like it anybody can ask the council to intervene (looks like there is less than a week to the next meeting). Simply debating the issues back and forth on an email list really isn't like to change things much, and as you and others have pointed out it can be an extremely frustrating activity. Rich There is more to it than that. Normally discussions can be good, but when you try to talk to a brick wall, it's absolutely pointless.
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
On Wed, 2014-02-05 at 13:58 +0100, Tom Wijsman wrote: Can we do something about our growing queue when fixing is insufficient? https://bugs.gentoo.org/chart.cgi?category=-All-datefrom=dateto=label0=All%20Openline0=320name=320subcategory=-All-action=wrap PS: As a bonus, here's a nice view of our stabilization queue over time: https://bugs.gentoo.org/chart.cgi?category=Gentoo+Linuxsubcategory=Keywording+and+Stabilizationname=639label0=All+Openline0=639datefrom=dateto=action-wrap=Chart+This+List Notice how the graph goes down near the dates the threads were made; although, if you would draw an average it would appear to be growing. There is far more to stabilizing than just closing the bugs. I've been working for over 2 months now on the GNOME stabilization on ARM. There has been a lot involved, including (but not limited to) rebuilding kernels for proper systemd integration, setting up systemd so that software would build (empathy won't build if systemd has no locale set (lol!) so much for systemd properly importing my settings from openrc) - building the software itself. Realizing that some things were built against the GPU opengl implementation instead of mesa's implementation, having to rebuild that software, and all it's dependencies. Then the process of actually attempting to get it to run, tracking down the junk in the logs - figuring out which messages can be ignored, which ones are actual errors (why exactly is it throwing an error message if that message can be ignored?) This is on multiple machines, because I'd like to cover softfp and hardfp. This takes time. Even if I were to build everything on my octa-core ARM server and just use the binpkgs, it still takes quite a bit of time to get through everything. And this is JUST for the default useflags. So you know what? I'm sick of hearing about slow arches - there's a LOT of shit that we have to do to make sure things ACTUALLY WORK, and based on your emails, you either have NO IDEA what all is involved in alternate arch work, or you're purposely being obtuse about it. Now, we COULD do like Ubuntu, and just say if it builds, it's stable. But I personally am against that, maybe that's okay with you. We used Ubuntu on ARM devices at my last job - I'm intimately familiar with their practices. We do not want to replicate that here in Gentoo land, or at least, I don't, not on ARM. Feel free to look at all the GL based apps that they have available on armel - and test how many of them actually run on the hardware. I'll wait for you to finish going through them all... Save the charts for upper management, they are the only ones who care what the pretty graphs look like instead of knowing the full details.
Re: [gentoo-dev] Add support for rsync patches
On 2014-02-05 00:13, Mike Frysinger wrote: i don't see any patches in rsync-3.1.0. i'd be hesitant to add support for them even if they were there ... They're in a different tarball [1], and yes I agree that it would be best to use epatch_user or similar. Tim [1]: http://rsync.samba.org/ftp/rsync/rsync-patches-3.1.0.tar.gz pgpwjbE9Ii_TQ.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
I'm firmly with Steev and Matt in this thread as well as in at least a few others where Tom has participated intensely. Tom Wijsman wrote: Thanks for putting up with it, but it's a huge waste of your time. Why? Because you seem to have a completely different mindset than everybody else, and not in a good way. :\ I told you on IRC that I don't think your approach is good for Gentoo but I was, and still am, unable to say exactly what is going on. At a minimum there is a severe communication problem but maybe there's also something else. //Peter
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
On Wed, 05 Feb 2014 10:55:59 -0600 Steev Klimaszewski st...@gentoo.org wrote: On Wed, 2014-02-05 at 13:58 +0100, Tom Wijsman wrote: Can we do something about our growing queue when fixing is insufficient? https://bugs.gentoo.org/chart.cgi?category=-All-datefrom=dateto=label0=All%20Openline0=320name=320subcategory=-All-action=wrap PS: As a bonus, here's a nice view of our stabilization queue over time: https://bugs.gentoo.org/chart.cgi?category=Gentoo+Linuxsubcategory=Keywording+and+Stabilizationname=639label0=All+Openline0=639datefrom=dateto=action-wrap=Chart+This+List Notice how the graph goes down near the dates the threads were made; although, if you would draw an average it would appear to be growing. There is far more to stabilizing than just closing the bugs. It is a sufficient indicator of how the amount of stabilization bugs, as well as the amount of overall bugs, is increasing over time. I've been working for over 2 months now on the GNOME stabilization on ARM. There has been a lot involved, including (but not limited to) rebuilding kernels for proper systemd integration, setting up systemd so that software would build (empathy won't build if systemd has no locale set (lol!) so much for systemd properly importing my settings from openrc) - building the software itself. Realizing that some things were built against the GPU opengl implementation instead of mesa's implementation, having to rebuild that software, and all it's dependencies. Then the process of actually attempting to get it to run, tracking down the junk in the logs - figuring out which messages can be ignored, which ones are actual errors (why exactly is it throwing an error message if that message can be ignored?) This is on multiple machines, because I'd like to cover softfp and hardfp. This takes time. Even if I were to build everything on my octa-core ARM server and just use the binpkgs, it still takes quite a bit of time to get through everything. And this is JUST for the default useflags. So you know what? I'm sick of hearing about slow arches - there's a LOT of shit that we have to do to make sure things ACTUALLY WORK, and based on your emails, you either have NO IDEA what all is involved in alternate arch work, or you're purposely being obtuse about it. Or it appears that some arches and people already skim down on all that work because of the huge amount of workload; as you have seen today, I gave an example of that on #gentoo-dev. I do have an idea; but, it appears that that idea is already no longer applied by some of us. I'm sick of important packages being affected this way; sorry WilliamH, we can't stabilize unless it's a security bug, *ouch*. Now, we COULD do like Ubuntu, and just say if it builds, it's stable. But I personally am against that, maybe that's okay with you. We used Ubuntu on ARM devices at my last job - I'm intimately familiar with their practices. We do not want to replicate that here in Gentoo land, or at least, I don't, not on ARM. Feel free to look at all the GL based apps that they have available on armel - and test how many of them actually run on the hardware. I'll wait for you to finish going through them all... You'll wait until we burn out in increasingly unimportant workloads. Save the charts for upper management, they are the only ones who care what the pretty graphs look like instead of knowing the full details. It demonstrates the actual problem this is all about; some of us do care about managing the future of Gentoo, as some of us do care to make sure the water tap is less open before mopping the floor. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
Re: [gentoo-dev] [OT] Re: Re: dropping redundant stable keywords
On Wed, 5 Feb 2014 21:18:46 +0100 Peter Stuge pe...@stuge.se wrote: Tom Wijsman wrote: Thanks for putting up with it, but it's a huge waste of your time. Why? Because you seem to have a completely different mindset than everybody else, and not in a good way. :\ That everybody else a broad generaliation, make a count and see how it is a rather small set of individuals; noteworthy with that, is that it is about different subtopics over this thread. Exactly, because different solutions were proposed by both sides; and thus, there's naturally some agreement (not so visual) and disagreement (more visual) going on here. That's a good thing, it works out those solutions. I told you on IRC that I don't think your approach is good for Gentoo but I was, and still am, unable to say exactly what is going on. At a minimum there is a severe communication problem but maybe there's also something else. Why? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
On Wed, 05 Feb 2014 10:07:22 -0600 Steev Klimaszewski st...@gentoo.org wrote: Against my better judgment... On Wed, 2014-02-05 at 05:55 +0100, Tom Wijsman wrote: On Tue, 04 Feb 2014 21:15:47 -0600 Steev Klimaszewski st...@gentoo.org wrote: On Wed, 2014-02-05 at 02:48 +0100, Tom Wijsman wrote: On Tue, 04 Feb 2014 19:35:22 -0600 Steev Klimaszewski st...@gentoo.org wrote: Alright, well, I've tried my best, I give up. Instead of having something working we should just remove ebuilds of working packages. s/should/could/ s/ebuilds/stable keyword or last stable version/ It is at the maintainer's discretion; and such decision is to make it possible for a maintainer to move on when he or she can no longer guarantee a working ebuild, to stop being progress-blocked by it. You know what - this is pure and utter bullshit. Why is this pure and utter bullshit? Because I'm attempting to have a discussion with a brick wall. Can you please keep yourself to responses about the subject as well as give reasoning for them? That way, we can make the discussion feel less solid and more fluent; I'll have to ask again, why a brick wall? Keeping it around for slower arches does NOT block progress. Why is keeping it around for slower arches not blocking progress? Let's see... having the software at least available, versus not having access to it at all... which one is progress... THINK TOM THINK. Yes, making the newest versions never available because the old versions sink all your time really stops progress to a dead halt. I have intimate knowledge with what ACTUALLY happens when people pull this bullshit - and that is a system that I can no longer actually work on. That is also what happens when a maintainer keeps around old versions, as well as old bugs and support for those old versions; as by doing so, the attention towards newer versions is lost which causes much huger breakage than the one you have just brought up. Manpower is limited. And we attempted to come up with a solution for this, however due to the wording of a page on the interwebs that solution is 100% unacceptable *to you*, a person who is unaffected by it. The last discussion has shown policy breach by bending words around. Can you tell why it is acceptable in a way that doesn't breach policy? And instead of working towards a fix that actually works for people who are ACTUALLY affected by the shitty policy, you hide behind definitions and pedantry. Why do you think this about the current and/or suggested solution(s)? I'm now going to take a break from Gentoo development because this thread has seriously caused my blood to boil based on comments from the peanut gallery (you) where things don't actually affect your day to day work, but your actions do affect mine. Why? How and why are your actions affected by the QA team's actions? Not the QA team's actions. YOURS. YOUR actions and responses in this thread. And the fact that the QA team allows you to continue to be on it, despite your obvious lack of interest in ACTUALLY having quality assurance. My actions are affected by it because I have to continue to attempt to discuss the issue with others who actually give a shit, and you just swoop in and say no, that absolutely is unacceptable as a solution The policy is made by the QA team; you are attempting to object to the policy, therefore this is the QA team's action. This is their action. It is rather that I ask question to clarify what you are trying to say as to get more useful and meaningful responses; but what I receive in return is pure and utter bullshit on a brick wall, maybe someone else would say no here but if you take a closer look this as well as the previous mail contains multiple questions for you. These questions show interest in assuring quality here; it's actually what makes up for a defensive style of discussion, making sure that we keep our quality as opposed to applying the first interesting solution that we come across. If you deem the QA team's policy doesn't do that, and that it has a detriment in quality; can you please let us know why? (even though it doesn't affect me!) because this page here says that it can't - we can change that definition if you'd like. Instead of the line saying: The -* keyword is special. It is used to indicate package versions which are not worth trying to test on unlisted archs. Would changing it to read The -* keyword is special. It is used to indicate package versions which are not for use on unlisted archs. Would that make it acceptable? Feel free to propose that to the QA team and / or the Gentoo Council. For this change, some questions come to mind: - How do we then identify it is not worth trying to test? - What does not for use really mean compared to a package.mask or leaving the
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
On Wed, 05 Feb 2014 10:26:01 -0600 Steev Klimaszewski st...@gentoo.org wrote: There is more to it than that. Normally discussions can be good, but when you try to talk to a brick wall, it's absolutely pointless. QA team's decisions require more than a flip of a dime; it takes a little more involvement, as well as solid evidence and reasoning. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
On Wed, 5 Feb 2014 22:50:57 +0100 Tom Wijsman tom...@gentoo.org wrote: On Wed, 05 Feb 2014 10:26:01 -0600 Steev Klimaszewski st...@gentoo.org wrote: There is more to it than that. Normally discussions can be good, but when you try to talk to a brick wall, it's absolutely pointless. QA team's decisions require more than a flip of a dime; it takes a little more involvement, as well as solid evidence and reasoning. Why? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/05/2014 04:48 PM, Tom Wijsman wrote: On Wed, 05 Feb 2014 10:07:22 -0600 Steev Klimaszewski st...@gentoo.org wrote: Against my better judgment... On Wed, 2014-02-05 at 05:55 +0100, Tom Wijsman wrote: On Tue, 04 Feb 2014 21:15:47 -0600 Steev Klimaszewski st...@gentoo.org wrote: On Wed, 2014-02-05 at 02:48 +0100, Tom Wijsman wrote: On Tue, 04 Feb 2014 19:35:22 -0600 Steev Klimaszewski st...@gentoo.org wrote: Alright, well, I've tried my best, I give up. Instead of having something working we should just remove ebuilds of working packages. s/should/could/ s/ebuilds/stable keyword or last stable version/ It is at the maintainer's discretion; and such decision is to make it possible for a maintainer to move on when he or she can no longer guarantee a working ebuild, to stop being progress-blocked by it. You know what - this is pure and utter bullshit. Why is this pure and utter bullshit? Because I'm attempting to have a discussion with a brick wall. Can you please keep yourself to responses about the subject as well as give reasoning for them? That way, we can make the discussion feel less solid and more fluent; I'll have to ask again, why a brick wall? Keeping it around for slower arches does NOT block progress. Why is keeping it around for slower arches not blocking progress? Let's see... having the software at least available, versus not having access to it at all... which one is progress... THINK TOM THINK. Yes, making the newest versions never available because the old versions sink all your time really stops progress to a dead halt. Your logic isn't flawed here, it's entirely missing. If version Y is stable on all arches but one, and that version is still using version X that doesn't affect any of the other arches at all. If the maintainer doesn't wish to support version X any longer then they can close bugs wontfix. Removing the last stable version on an arch from the tree is against policy. I have intimate knowledge with what ACTUALLY happens when people pull this bullshit - and that is a system that I can no longer actually work on. That is also what happens when a maintainer keeps around old versions, as well as old bugs and support for those old versions; as by doing so, the attention towards newer versions is lost which causes much huger breakage than the one you have just brought up. Manpower is limited. And we attempted to come up with a solution for this, however due to the wording of a page on the interwebs that solution is 100% unacceptable *to you*, a person who is unaffected by it. The last discussion has shown policy breach by bending words around. Can you tell why it is acceptable in a way that doesn't breach policy? And instead of working towards a fix that actually works for people who are ACTUALLY affected by the shitty policy, you hide behind definitions and pedantry. Why do you think this about the current and/or suggested solution(s)? I'm now going to take a break from Gentoo development because this thread has seriously caused my blood to boil based on comments from the peanut gallery (you) where things don't actually affect your day to day work, but your actions do affect mine. Why? How and why are your actions affected by the QA team's actions? Not the QA team's actions. YOURS. YOUR actions and responses in this thread. And the fact that the QA team allows you to continue to be on it, despite your obvious lack of interest in ACTUALLY having quality assurance. My actions are affected by it because I have to continue to attempt to discuss the issue with others who actually give a shit, and you just swoop in and say no, that absolutely is unacceptable as a solution The policy is made by the QA team; you are attempting to object to the policy, therefore this is the QA team's action. This is their action. Please don't claim you speak for the QA team when in fact, you have not discussed it with any of us, and the QA lead told you to cool it on irc hours ago. You are speaking for yourself here and no one else. There is NO policy that allows for dropping a stable ebuild without masks, discussion, and significant passage of time. It is rather that I ask question to clarify what you are trying to say as to get more useful and meaningful responses; but what I receive in return is pure and utter bullshit on a brick wall, maybe someone else would say no here but if you take a closer look this as well as the previous mail contains multiple questions for you. These questions show interest in assuring quality here; it's actually what makes up for a defensive style of discussion, making sure that we keep our quality as opposed to applying the first interesting solution that we come across. If you deem the QA team's policy doesn't do that, and that it has a detriment in quality; can you please let us know why? Again,
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
On Wed, 05 Feb 2014 17:05:08 -0500 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote: Yes, making the newest versions never available because the old versions sink all your time really stops progress to a dead halt. Your logic isn't flawed here, it's entirely missing. If version Y is stable on all arches but one, and that version is still using version X that doesn't affect any of the other arches at all. Can this be proven? Why are maintainers like WilliamH upset about this? Reference: http://article.gmane.org/gmane.linux.gentoo.devel/90063 If the maintainer doesn't wish to support version X any longer then they can close bugs wontfix. +1, but what about stabilization bugs that block other bugs? Removing the last stable version on an arch from the tree is against policy. The QA policy meant to override this; to avoid confusion, I mean including the proper workflow involved in this. But this has raised concerns on IRC today, as it was made clear what the reasons are that I was asking for; it's good that we do a new vote on this to properly reflect what we really intend, rather than some poor voting that went through a quick vote and didn't take everything in consideration. Not the QA team's actions. YOURS. YOUR actions and responses in this thread. And the fact that the QA team allows you to continue to be on it, despite your obvious lack of interest in ACTUALLY having quality assurance. My actions are affected by it because I have to continue to attempt to discuss the issue with others who actually give a shit, and you just swoop in and say no, that absolutely is unacceptable as a solution The policy is made by the QA team; you are attempting to object to the policy, therefore this is the QA team's action. This is their action. Please don't claim you speak for the QA team when in fact, you have not discussed it with any of us, We did discuss this QA policy during the QA meeting. and the QA lead told you to cool it on irc hours ago. That was minutes ago, you are replying to is written before that; furthermore, I believe things are cool. Why do you think otherwise? You are speaking for yourself here and no one else. I'm quoting QA team policy, agreed on by at least 8 individuals; that policy can be read at the following URL: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies If you still think so, can you show me where I did speak for myself? There is NO policy that allows for dropping a stable ebuild without masks, discussion, and significant passage of time. It is rather that I ask question to clarify what you are trying to say as to get more useful and meaningful responses; but what I receive in return is pure and utter bullshit on a brick wall, maybe someone else would say no here but if you take a closer look this as well as the previous mail contains multiple questions for you. These questions show interest in assuring quality here; it's actually what makes up for a defensive style of discussion, making sure that we keep our quality as opposed to applying the first interesting solution that we come across. If you deem the QA team's policy doesn't do that, and that it has a detriment in quality; can you please let us know why? Again, there is no policy that allows you to drop a stable package on an arch without a whole lot of things that I definitely never say happen. Honestly, if I even knew what you two were discussing in specific I'd likely be reverting the stupid drop instead of pointing out things in this thread which is wasting my time, and everyone else's. Indeed, there isn't; where did I say there is? Now that it has been said so on IRC, I see it can be misinterpreted. (even though it doesn't affect me!) because this page here says that it can't - we can change that definition if you'd like. Instead of the line saying: The -* keyword is special. It is used to indicate package versions which are not worth trying to test on unlisted archs. Would changing it to read The -* keyword is special. It is used to indicate package versions which are not for use on unlisted archs. Would that make it acceptable? Feel free to propose that to the QA team and / or the Gentoo Council. No changes are required. Everyone with 2 brain cells knows that -* means cannot work on other arches. Things like binary packages, etc. And thus -* is not a solution to this thread. Now, before you continue discussing this issue here on the list, perhaps you should turn around and talk to the QA team about what needs changed and discussed. +1 -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/05/2014 07:48 PM, Tom Wijsman wrote: On Wed, 05 Feb 2014 17:05:08 -0500 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote: Yes, making the newest versions never available because the old versions sink all your time really stops progress to a dead halt. Your logic isn't flawed here, it's entirely missing. If version Y is stable on all arches but one, and that version is still using version X that doesn't affect any of the other arches at all. Can this be proven? Why are maintainers like WilliamH upset about this? Reference: http://article.gmane.org/gmane.linux.gentoo.devel/90063 I've already voiced my concern on his bug: https://bugs.gentoo.org/show_bug.cgi?id=500014 If the maintainer doesn't wish to support version X any longer then they can close bugs wontfix. +1, but what about stabilization bugs that block other bugs? They stay open as a tracker, bugs track all arches. This doesn't prevent the work being done on the faster arches, all it does is leave bugs hanging around when certain devs think more closed bugs is more better. Removing the last stable version on an arch from the tree is against policy. The QA policy meant to override this; to avoid confusion, I mean including the proper workflow involved in this. But this has raised concerns on IRC today, as it was made clear what the reasons are that I was asking for; it's good that we do a new vote on this to properly reflect what we really intend, rather than some poor voting that went through a quick vote and didn't take everything in consideration. Nothing in the QA policy says ignore standard removal policy. Here is the standard removal policy, and I expect it to be followed: https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html When a doctor tells you go to the hospital as fast as you can he doesn't mean steal a faster car, speed as much as possible, and don't stop at red lights. Doing so would obviously be dangerous, and cause additional problems, just like ignoring the standard keyword/ebuild removal policy. Not the QA team's actions. YOURS. YOUR actions and responses in this thread. And the fact that the QA team allows you to continue to be on it, despite your obvious lack of interest in ACTUALLY having quality assurance. My actions are affected by it because I have to continue to attempt to discuss the issue with others who actually give a shit, and you just swoop in and say no, that absolutely is unacceptable as a solution The policy is made by the QA team; you are attempting to object to the policy, therefore this is the QA team's action. This is their action. Please don't claim you speak for the QA team when in fact, you have not discussed it with any of us, We did discuss this QA policy during the QA meeting. and the QA lead told you to cool it on irc hours ago. That was minutes ago, you are replying to is written before that; furthermore, I believe things are cool. Why do you think otherwise? You are speaking for yourself here and no one else. I'm quoting QA team policy, agreed on by at least 8 individuals; that policy can be read at the following URL: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies That policy doesn't permit removal of keywords/ebuilds without following gentoo standard policy, standard policy is available here: https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html If you still think so, can you show me where I did speak for myself? As I am also a member of the QA team, clearly there isn't a consensus on this topic. There is NO policy that allows for dropping a stable ebuild without masks, discussion, and significant passage of time. It is rather that I ask question to clarify what you are trying to say as to get more useful and meaningful responses; but what I receive in return is pure and utter bullshit on a brick wall, maybe someone else would say no here but if you take a closer look this as well as the previous mail contains multiple questions for you. These questions show interest in assuring quality here; it's actually what makes up for a defensive style of discussion, making sure that we keep our quality as opposed to applying the first interesting solution that we come across. If you deem the QA team's policy doesn't do that, and that it has a detriment in quality; can you please let us know why? Again, there is no policy that allows you to drop a stable package on an arch without a whole lot of things that I definitely never say happen. Honestly, if I even knew what you two were discussing in specific I'd likely be reverting the stupid drop instead of pointing out things in this thread which is wasting my time, and everyone else's. Indeed, there isn't; where did I say there is? Now that it has been said so on IRC, I see it can be misinterpreted. (even though it doesn't affect
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
On Wed, 5 Feb 2014 22:03:09 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 5 Feb 2014 22:50:57 +0100 Tom Wijsman tom...@gentoo.org wrote: On Wed, 05 Feb 2014 10:26:01 -0600 Steev Klimaszewski st...@gentoo.org wrote: There is more to it than that. Normally discussions can be good, but when you try to talk to a brick wall, it's absolutely pointless. QA team's decisions require more than a flip of a dime; it takes a little more involvement, as well as solid evidence and reasoning. Why? Because QA team's decisions are decided on during a QA team meeting that happens once a month, just like the Gentoo Council does; it requires us to talk about it and work towards a decision, otherwise a statement can't be formed and we can't vote on that statement. If we were brick walls, this policy would never get formed; exactly the opposite is happening here, after the reason that I was asking for here became clear in #gentoo-dev we are going to further discuss it to adapt. The solid evidence (that it can be misinterpreted) and reasoning (that its misinterpretations lead to situations that we don't want) both are sufficient to revise the policy. Without those, we get what you see in this thread; the lack of evidence and reasoning not showing why the policy in its current form would cause breakage, or why particular other solutions would work out well. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
On Wed, Feb 5, 2014 at 8:00 PM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: On 02/05/2014 07:48 PM, Tom Wijsman wrote: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies That policy doesn't permit removal of keywords/ebuilds without following gentoo standard policy, standard policy is available here: https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html So, I realize I'm repeating myself, but the purpose of the mailing list isn't to keep reposting the same arguments back and forth until everybody agrees. Post your argument once, and once it gets dull by all means appeal to QA/council/whatever but the bickering really doesn't add any value. For my part I promise not to let it be a whoever-makes-the-most-noise-sets-the-policy thing. I appreciate the concerns, arguments, and alternatives that were raised - they're helpful the first time they come up. To add something new, can the QA team please figure out what policy they actually intended to make and just communicate it? Having QA team members and everybody else openly speculating about what the policy is supposed to be on the list also adds no value. If the new policy does not in fact override the standard policy then I'm not really sure what it is trying to say since it only speaks to things that were already spoken to before, just in a different way. Thanks for updating the policy webpage with the note that the policy shouldn't be followed until clarified. One thing I haven't really seen in this thread is a better understanding of the demand for old version removal. I can understand the hypothetical issues having old versions creates, but is just WONTFIXing a bunch of old bugs a large burden in practice? Before we create new problems by fixing old problems, I'd like to get a sense for whether the old problems are actually problems. I imagine this becomes a matter of degree - keeping a package around for an extra 6-12 months probably isn't a big deal, but when half the tree contains 6-year-old versions it is a problem. Rich
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
On Wed, 05 Feb 2014 20:00:41 -0500 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote: Can this be proven? Why are maintainers like WilliamH upset about this? Reference: http://article.gmane.org/gmane.linux.gentoo.devel/90063 I've already voiced my concern on his bug: https://bugs.gentoo.org/show_bug.cgi?id=500014 Yes; there is some unclear wording causing misconceptions as well as that you oppose in a way that makes it worth to clarify and vote again, and I'll ACK hard enough to not discuss this without your presence. If the maintainer doesn't wish to support version X any longer then they can close bugs wontfix. +1, but what about stabilization bugs that block other bugs? They stay open as a tracker, bugs track all arches. This doesn't prevent the work being done on the faster arches, all it does is leave bugs hanging around when certain devs think more closed bugs is more better. My concern with this is that that list is growing; and when that happens, I'm not so much for closed bugs, but rather about shifting our priority to more important bugs, getting new people, better arch testing quality, and the list goes on... We could for example use Tinderbox and have it send success / failure results, build logs and binpkg(s) (for download) to the arch team, which makes the arch team just have to solely do a quick inspeciton of the build log and test the binpkg; this automation can cut down on a lot of manual testing. On top of that, you have Tinderbox's build log checking on top of that; which can catch some things the eye might not see at a first take. This was an example from #gentoo-dev yesterday. Removing the last stable version on an arch from the tree is against policy. The QA policy meant to override this; to avoid confusion, I mean including the proper workflow involved in this. But this has raised concerns on IRC today, as it was made clear what the reasons are that I was asking for; it's good that we do a new vote on this to properly reflect what we really intend, rather than some poor voting that went through a quick vote and didn't take everything in consideration. Nothing in the QA policy says ignore standard removal policy. Here is the standard removal policy, and I expect it to be followed: https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html We do however revisit it (subject of original thread); the workflow (masking, news, ...) of course should not be ignored, however we do ignore that it says not to remove the last stable ebuild. When a doctor tells you go to the hospital as fast as you can he doesn't mean steal a faster car, speed as much as possible, and don't stop at red lights. Doing so would obviously be dangerous, and cause additional problems, just like ignoring the standard keyword/ebuild removal policy. Consider that the person will however at least try to test the limits; and even with those limits in place and following them, the person can still slowly crash into something. Attention and thoughts are involved. Not the QA team's actions. YOURS. YOUR actions and responses in this thread. And the fact that the QA team allows you to continue to be on it, despite your obvious lack of interest in ACTUALLY having quality assurance. My actions are affected by it because I have to continue to attempt to discuss the issue with others who actually give a shit, and you just swoop in and say no, that absolutely is unacceptable as a solution The policy is made by the QA team; you are attempting to object to the policy, therefore this is the QA team's action. This is their action. Please don't claim you speak for the QA team when in fact, you have not discussed it with any of us, We did discuss this QA policy during the QA meeting. and the QA lead told you to cool it on irc hours ago. That was minutes ago, you are replying to is written before that; furthermore, I believe things are cool. Why do you think otherwise? You are speaking for yourself here and no one else. I'm quoting QA team policy, agreed on by at least 8 individuals; that policy can be read at the following URL: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies That policy doesn't permit removal of keywords/ebuilds without following gentoo standard policy, standard policy is available here: https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html Maybe, maybe not; that can be misinterpreted. But what does it permit? If you still think so, can you show me where I did speak for myself? As I am also a member of the QA team, clearly there isn't a consensus on this topic. So, there isn't an occasion where I spoke for myself? There is NO policy that allows for dropping a stable ebuild without masks, discussion, and significant passage of time. It is rather that I ask question to clarify what you are trying to say as
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
On Wed, 05 Feb 2014 10:07:22 -0600 Steev Klimaszewski st...@gentoo.org wrote: Why is this pure and utter bullshit? Because I'm attempting to have a discussion with a brick wall. I hit that problem immediately in another sub-thread. Are we on to something here? Regards, jer
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
On Wed, 5 Feb 2014 20:50:07 -0500 Rich Freeman ri...@gentoo.org wrote: So, I realize I'm repeating myself, but the purpose of the mailing list isn't to keep reposting the same arguments back and forth until everybody agrees. Post your argument once, and once it gets dull by all means appeal to QA/council/whatever but the bickering really doesn't add any value. For my part I promise not to let it be a whoever-makes-the-most-noise-sets-the-policy thing. I appreciate the concerns, arguments, and alternatives that were raised - they're helpful the first time they come up. +1 To add something new, can the QA team please figure out what policy they actually intended to make and just communicate it? Having QA team members and everybody else openly speculating about what the policy is supposed to be on the list also adds no value. This is a misconception; Rick was absent during the meeting, we've voted for it with 7 of 10, 1 person abstained, 2 were absent. A majority thus wants the statement as it was written; which has appeared fine up until the point that Rick addressed me in public with a misinterpretation of that policy (or might have been unaware of it), it's only after that point that it became clear of what I was asking Steev, that the current policy by the QA team is being misinterpreted. If the new policy does not in fact override the standard policy then I'm not really sure what it is trying to say since it only speaks to things that were already spoken to before, just in a different way. Exactly the point; note though to avoid confusion that there is a difference between policy and workflow here. We should still use mask messages, if needed even news and more; and not just plain out `rm ...`. However, just like you, I see no other way to read that policy than to override our existing policy that reads 'You should also not cause an unnecessary downgrade for any ~arch when removing ebuilds - ...' http://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance And to this extent I think Rick disagrees with the essence of it; but then again, there has also been mentions of improving the wording. Thus I don't really know if Rick wants to see it changed _or_ removed...; however, that'll become clear with more discussion and the meeting, which have happened, are happening and will happen on #gentoo-qa. Thanks for updating the policy webpage with the note that the policy shouldn't be followed until clarified. +1 for creffett doing that. One thing I haven't really seen in this thread is a better understanding of the demand for old version removal. I can understand the hypothetical issues having old versions creates. But is just WONTFIXing a bunch of old bugs a large burden in practice? It upsets stable users; and thinking of it, it doesn't get the actual stabilization problem across. Furthermore it is odd to show the user it is not maintained anymore while keeping that stable keyword and version around. Why mark it stable if the maintainer doesn't maintain it? Should it still be kept marked stable if the maintainer considers it to not really be stable? *Hey you, maintainer, it acts a bit buggy!* Before we create new problems by fixing old problems, I'd like to get a sense for whether the old problems are actually problems. I imagine this becomes a matter of degree - keeping a package around for an extra 6-12 months probably isn't a big deal, but when half the tree contains 6-year-old versions it is a problem. We should reconsider 90 days in this respect, it might be a bit on the low end; counting in years would indeed be more appropriate. Note that maybe (just guessing) those 6-year-old versions don't really exist; but, if the stable queue continues to grow (it grows on average) like this over time they eventually will get to exist in the future. And that'll come to be an actual problem; and to avoid scratching our heads by that time, it is nice to have our response in place in advance. Quoting my meeting agenda questions of last time that reflect this: How do we evaluate whether future stabilization improves or becomes worse? How bad is stabilization really at the moment? How can we make more users and/or developers interested in arch testing (and/or Gentoo)? Do we want to make a policy change now, or delay considering it till a later meeting in the future? ...? https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Agenda -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
On Thu, 6 Feb 2014 03:12:54 +0100 Jeroen Roovers j...@gentoo.org wrote: On Wed, 05 Feb 2014 10:07:22 -0600 Steev Klimaszewski st...@gentoo.org wrote: Why is this pure and utter bullshit? Because I'm attempting to have a discussion with a brick wall. I hit that problem immediately in another sub-thread. Are we on to something here? Yes, we are; for more details: http://www.paulgraham.com/disagree.html -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
why cant there be a second repository for all old source, ebuilds, and patches and the stable and testing repository can be rolling like it already is. slower archs can then sync the old repository and the new one. On Feb 5, 2014 5:54 PM, Tom Wijsman tom...@gentoo.org wrote: On Wed, 05 Feb 2014 20:00:41 -0500 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote: Can this be proven? Why are maintainers like WilliamH upset about this? Reference: http://article.gmane.org/gmane.linux.gentoo.devel/90063 I've already voiced my concern on his bug: https://bugs.gentoo.org/show_bug.cgi?id=500014 Yes; there is some unclear wording causing misconceptions as well as that you oppose in a way that makes it worth to clarify and vote again, and I'll ACK hard enough to not discuss this without your presence. If the maintainer doesn't wish to support version X any longer then they can close bugs wontfix. +1, but what about stabilization bugs that block other bugs? They stay open as a tracker, bugs track all arches. This doesn't prevent the work being done on the faster arches, all it does is leave bugs hanging around when certain devs think more closed bugs is more better. My concern with this is that that list is growing; and when that happens, I'm not so much for closed bugs, but rather about shifting our priority to more important bugs, getting new people, better arch testing quality, and the list goes on... We could for example use Tinderbox and have it send success / failure results, build logs and binpkg(s) (for download) to the arch team, which makes the arch team just have to solely do a quick inspeciton of the build log and test the binpkg; this automation can cut down on a lot of manual testing. On top of that, you have Tinderbox's build log checking on top of that; which can catch some things the eye might not see at a first take. This was an example from #gentoo-dev yesterday. Removing the last stable version on an arch from the tree is against policy. The QA policy meant to override this; to avoid confusion, I mean including the proper workflow involved in this. But this has raised concerns on IRC today, as it was made clear what the reasons are that I was asking for; it's good that we do a new vote on this to properly reflect what we really intend, rather than some poor voting that went through a quick vote and didn't take everything in consideration. Nothing in the QA policy says ignore standard removal policy. Here is the standard removal policy, and I expect it to be followed: https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html We do however revisit it (subject of original thread); the workflow (masking, news, ...) of course should not be ignored, however we do ignore that it says not to remove the last stable ebuild. When a doctor tells you go to the hospital as fast as you can he doesn't mean steal a faster car, speed as much as possible, and don't stop at red lights. Doing so would obviously be dangerous, and cause additional problems, just like ignoring the standard keyword/ebuild removal policy. Consider that the person will however at least try to test the limits; and even with those limits in place and following them, the person can still slowly crash into something. Attention and thoughts are involved. Not the QA team's actions. YOURS. YOUR actions and responses in this thread. And the fact that the QA team allows you to continue to be on it, despite your obvious lack of interest in ACTUALLY having quality assurance. My actions are affected by it because I have to continue to attempt to discuss the issue with others who actually give a shit, and you just swoop in and say no, that absolutely is unacceptable as a solution The policy is made by the QA team; you are attempting to object to the policy, therefore this is the QA team's action. This is their action. Please don't claim you speak for the QA team when in fact, you have not discussed it with any of us, We did discuss this QA policy during the QA meeting. and the QA lead told you to cool it on irc hours ago. That was minutes ago, you are replying to is written before that; furthermore, I believe things are cool. Why do you think otherwise? You are speaking for yourself here and no one else. I'm quoting QA team policy, agreed on by at least 8 individuals; that policy can be read at the following URL: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies That policy doesn't permit removal of keywords/ebuilds without following gentoo standard policy, standard policy is available here: https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html Maybe, maybe not; that can be misinterpreted. But what does it permit? If you still think so, can you show me where I did speak for
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
On Wed, 5 Feb 2014 19:04:56 -0800 Tyler Pohl tylerap...@gmail.com wrote: why cant there be a second repository for all old source, ebuilds, and patches and the stable and testing repository can be rolling like it already is. slower archs can then sync the old repository and the new one. There is one in place, the Graveyard overlay; it hasn't had much succes: http://gentoo.2317880.n4.nabble.com/Graveyard-overlay-was-Re-gentoo-dev-last-rites-games-strategy-x2-games-strategy-x2-demo-td258113.html https://wiki.gentoo.org/wiki/Project:Graveyard https://github.com/gentoo/graveyard It needs someone to revive it and make it happen, anyone up? PS; As a reminder, on mailing lists, consider to place your message below of that what you quote; in personal e-mail it is to follow what is being said as it is mostly a one-to-one conversation, however on mailing lists people want to see what is being replied to and we commonly read from top to bottom that way. My response is an example. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
Re: [gentoo-dev] Re: Re: dropping redundant stable keywords
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/05/2014 09:50 PM, Tom Wijsman wrote: On Wed, 5 Feb 2014 20:50:07 -0500 Rich Freeman ri...@gentoo.org wrote: So, I realize I'm repeating myself, but the purpose of the mailing list isn't to keep reposting the same arguments back and forth until everybody agrees. Post your argument once, and once it gets dull by all means appeal to QA/council/whatever but the bickering really doesn't add any value. For my part I promise not to let it be a whoever-makes-the-most-noise-sets-the-policy thing. I appreciate the concerns, arguments, and alternatives that were raised - they're helpful the first time they come up. +1 To add something new, can the QA team please figure out what policy they actually intended to make and just communicate it? Having QA team members and everybody else openly speculating about what the policy is supposed to be on the list also adds no value. This is a misconception; Rick was absent during the meeting, we've voted for it with 7 of 10, 1 person abstained, 2 were absent. A majority thus wants the statement as it was written; which has appeared fine up until the point that Rick addressed me in public with a misinterpretation of that policy (or might have been unaware of it), it's only after that point that it became clear of what I was asking Steev, that the current policy by the QA team is being misinterpreted. If the new policy does not in fact override the standard policy then I'm not really sure what it is trying to say since it only speaks to things that were already spoken to before, just in a different way. Exactly the point; note though to avoid confusion that there is a difference between policy and workflow here. We should still use mask messages, if needed even news and more; and not just plain out `rm ...`. However, just like you, I see no other way to read that policy than to override our existing policy that reads 'You should also not cause an unnecessary downgrade for any ~arch when removing ebuilds - ...' http://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance And to this extent I think Rick disagrees with the essence of it; but then again, there has also been mentions of improving the wording. Thus I don't really know if Rick wants to see it changed _or_ removed...; however, that'll become clear with more discussion and the meeting, which have happened, are happening and will happen on #gentoo-qa. Thanks for updating the policy webpage with the note that the policy shouldn't be followed until clarified. +1 for creffett doing that. One thing I haven't really seen in this thread is a better understanding of the demand for old version removal. I can understand the hypothetical issues having old versions creates. But is just WONTFIXing a bunch of old bugs a large burden in practice? It upsets stable users; and thinking of it, it doesn't get the actual stabilization problem across. Furthermore it is odd to show the user it is not maintained anymore while keeping that stable keyword and version around. Why mark it stable if the maintainer doesn't maintain it? Should it still be kept marked stable if the maintainer considers it to not really be stable? *Hey you, maintainer, it acts a bit buggy!* Before we create new problems by fixing old problems, I'd like to get a sense for whether the old problems are actually problems. I imagine this becomes a matter of degree - keeping a package around for an extra 6-12 months probably isn't a big deal, but when half the tree contains 6-year-old versions it is a problem. We should reconsider 90 days in this respect, it might be a bit on the low end; counting in years would indeed be more appropriate. Note that maybe (just guessing) those 6-year-old versions don't really exist; but, if the stable queue continues to grow (it grows on average) like this over time they eventually will get to exist in the future. And that'll come to be an actual problem; and to avoid scratching our heads by that time, it is nice to have our response in place in advance. Quoting my meeting agenda questions of last time that reflect this: How do we evaluate whether future stabilization improves or becomes worse? How bad is stabilization really at the moment? How can we make more users and/or developers interested in arch testing (and/or Gentoo)? Do we want to make a policy change now, or delay considering it till a later meeting in the future? ...? https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Agenda I really didn't want to get involved in this mess, but here goes: - -Due to concerns about the wording of the policy, it is currently on hold pending review at an upcoming QA team meeting. - -Any further input/attempts at interpretation by QA team members at this point would needlessly confuse the issue, therefore, I would appreciate it if the QA team would stop
[gentoo-dev] Re: dropping redundant stable keywords
Steev Klimaszewski posted on Wed, 05 Feb 2014 10:55:59 -0600 as excerpted: There is far more to stabilizing than just closing the bugs. I've been working for over 2 months now on the GNOME stabilization on ARM. There has been a lot involved, including (but not limited to) rebuilding kernels for proper systemd integration, setting up systemd so that software would build (empathy won't build if systemd has no locale set (lol!) so much for systemd properly importing my settings from openrc) - building the software itself. Realizing that some things were built against the GPU opengl implementation instead of mesa's implementation, having to rebuild that software, and all it's dependencies. Then the process of actually attempting to get it to run, tracking down the junk in the logs - figuring out which messages can be ignored, which ones are actual errors (why exactly is it throwing an error message if that message can be ignored?) This is on multiple machines, because I'd like to cover softfp and hardfp. This takes time. Even if I were to build everything on my octa-core ARM server and just use the binpkgs, it still takes quite a bit of time to get through everything. And this is JUST for the default useflags. So you know what? I'm sick of hearing about slow arches - there's a LOT of shit that we have to do to make sure things ACTUALLY WORK, and based on your emails, you either have NO IDEA what all is involved in alternate arch work, or you're purposely being obtuse about it. Now, we COULD do like Ubuntu, and just say if it builds, it's stable. But I personally am against that, maybe that's okay with you. We used Ubuntu on ARM devices at my last job - I'm intimately familiar with their practices. We do not want to replicate that here in Gentoo land, or at least, I don't, not on ARM. Feel free to look at all the GL based apps that they have available on armel - and test how many of them actually run on the hardware. That *IS* a lot of work and you definitely have my respect for even /trying/ to carry it out. But Tom's burn out in increasingly unimportant workloads seems apropos. Which, given the continuing onslaught of stabilizations and the acknowledged bottleneck, eventually means something /must/, /WILL/ break. Which is exactly what this thread is about. Maintainers are actually seeing that breakage now as the backlogs get untenable. So they're complaining. Given the bottleneck and the continuing onslaught, it's /already/ broken. The will break has for them become now has broken. The question then becomes what to do about that breakage, how to move it to the point of least disruption for gentoo as a whole. Thus the proposal, on bottleneck archs drop stable keywords for unimportant packages, reducing the working set to something tenable and thus reducing the bottleneck, allowing those archs to focus more strongly on core packages with the idea of keeping them stable and relatively current, even if it comes at the cost of a much smaller stable set. If the arch gets more resources in the future, it can expand that set, but right now it's an untenable bottleneck and /something/ must happen to break that bottleneck. If it isn't this, the problem will get worse and worse until that /something/ gets much worse, perhaps triggering a drop of the entire arch to experimental. The other alternatives include letting maintainers either reassign bugs for otherwise stale versions to the bottleneck arch in question, which just makes the problem worse as now the bottleneck has even MORE work piling up on it, or simply closing bugs filed against such stale versions as WONTFIX, perhaps with a note suggest the filer upgrade to something even half current, even if it's NOT stable on the arch and in fact is broken on the arch. Unfortunately, that last option is the current de-facto default, except that without a formal policy, bugs often remain ignored or closed WONTFIX without a useful explanation. IOW, for users and maintainers both the state is already broken, while arch-devs face an ever-increasing backlog and a bottleneck that's not going to get better. Now I'm admittedly a bit biased as I'm a kde guy who wonders what sort of self-respecting customization is king! gentooer would want to run our way is the ONLY CORRECT way and if you think otherwise you're just stupid! gnome in the first place, case in point being this apparent systemd requirement, but I'd certainly personally consider an after all non-core optional package set requiring *THAT* much additional stabilization work a prime candidate for first exercise of that keyword dropping policy. By your own statements that's two months of work for an optional non-core package set that you would have been able to skip, thus allowing you to focus more strongly on stabilizing other things, including gentoo's own default initsystem, openrc, which I think most would agree is
[gentoo-dev] Re: dropping redundant stable keywords
Tom Wijsman posted on Thu, 06 Feb 2014 03:53:24 +0100 as excerpted: On Thu, 6 Feb 2014 03:12:54 +0100 Jeroen Roovers j...@gentoo.org wrote: On Wed, 05 Feb 2014 10:07:22 -0600 Steev Klimaszewski st...@gentoo.org wrote: I'm attempting to have a discussion with a brick wall. I hit that problem immediately in another sub-thread. Are we on to something here? Yes, we are; for more details: http://www.paulgraham.com/disagree.html Thanks for the link. Certainly thought provoking and I agree. With it nicely laid out like that, I can now more concretely try to up the DH level of my own replies in the future. =:^) (OTOH, acknowledging that this is in itself DH2/tone or DH0/name-calling, tho with a counterargument to a slightly different point so I guess it's DH4, I'm compelled to observe that repeatedly asking Why? as a one-word reply calls to mind the young child's constant Why? stage... a bit after they get past the earlier constant NO! stage... As about any parent or children's care giver can certainly attest, it /does/ get frustrating at some point. Perhaps you were simply trying to up the DH level, but in that case, something beyond Why? could have been useful. Arguably simply and repeatedly asking Why?, without any indication even of what particular bit you're whying, must be a parallel form of DH1 or at best DH2, ad hominem or tone. Once was arguably useful, but after seeing it used multiple times in multiple replies, the usefulness was entirely gone and the single word question was no longer a useful contribution to the discussion. Please reconsider that technique in the light of your above link before repetitive use in the future, and at least make it a useful sentence, not simply the one word, because especially when repeated, that single one word really does look childish and tends to increase frustration and reduce the quality of the discussion.) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] [OT] Re: dropping redundant stable keywords
On Thu, 6 Feb 2014 05:21:51 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: (OTOH, acknowledging that this is in itself DH2/tone or DH0/name-calling, tho with a counterargument to a slightly different point so I guess it's DH4, I'm compelled to observe that repeatedly asking Why? as a one-word reply calls to mind the young child's constant Why? stage... a bit after they get past the earlier constant NO! stage... As about any parent or children's care giver can certainly attest, it /does/ get frustrating at some point. Perhaps you were simply trying to up the DH level, but in that case, something beyond Why? could have been useful. Arguably simply and repeatedly asking Why?, without any indication even of what particular bit you're whying, must be a parallel form of DH1 or at best DH2, ad hominem or tone. Once was arguably useful, but after seeing it used multiple times in multiple replies, the usefulness was entirely gone and the single word question was no longer a useful contribution to the discussion. Please reconsider that technique in the light of your above link before repetitive use in the future, and at least make it a useful sentence, not simply the one word, because especially when repeated, that single one word really does look childish and tends to increase frustration and reduce the quality of the discussion.) There's only a single occurrence of a single-word Why? without any other question on the line, there is another single occurence of a single-word Why? with a long How ...? on the same line; it was not used repetitively, and the Why? on its own is made when we're down a DH in this thread that's already extremely low in which point my DH isn't any more disrespectful than its context. However, pointing this single occurrence out in its own as well as nitpicking on it together is something I'd like to avoid here; let me instead just point out that most occurrences of those questions were in full text. And if we can't ask questions in full text anymore; then, I'm unable to see how a discussion can be held at all. Fwiw, the very same person I made that single one-word Why? to has previously appreciated that I asked him. You are welcome to point out where you think that I went to a lower DH; but when you do, please do it in private as to avoid extra noise. At least when we're talking here about doing this after the fact; when a natural discussion is ongoing, a proper respectful disagreement is of course welcome in which case you can do it in public with us. As long as it addresses the central point of the discussion... I've been considering a while not responding to messages of lower DH; just like the message you have jut made, but in doing so that would even be more disconstructive than to constructively try to make the best out of the thread. Some people will see this discussion as popcorn material, and rather useless; but out of this and the IRC communication that happened afterwards we've got at least (thanks to Rick): 1) clear there's a misunderstanding; 2) it being discussed and voted on again at the next Gentoo QA meeting; 3) Steev got to a discussion with the arm team, which lead to the idea to evaluate the usefulness of the stages and more; and there'll be more to come, to realize and to move Gentoo forward on. Consider what would have happened if we didn't go this far? It's scary. PS: Wrt. your other long response, I agree with a very large part of it. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
[gentoo-dev] Thank you
Hi. TL;DR, this is basically just a THANK YOU to the Gentoo devs, so you can go on your daily business if you don't want to read the rest of it. No biggie. I just want to say THANK YOU to all of our Gentoo developers. I've been using Gentoo since ca. 2002 (damn, that's more than a decade), and I've seen a lot of flamewars and bikeshedding on the -dev mailing list. However, you guys get the job done, and although there are some things that I would like to have sooner (or would have liked to have earlier), in the end the people working keep pushing the necessary changes so the distribution keeps going, and (if so desired) using new and interesting technologies. More importantly, the developers and the bureaucratic structures they have created don't get (too much) in the way of individual or small groups of developers pushing for progress. In general at least; there will be always someone resisting change, but in general Gentoo keeps advancing, and the council and the other bureaucratic structures don't punish people for just wanting to have more new and cool features in the distribution. I've never said Thank You to all our developers in all these years using Gentoo, but after seeing the discussion the Debian CTTE is having related to the default init they should use[1][2][3] (including bureaucratic maneuvers, dilatory tactics, legalese interpretation of their rulings, etc.), I think the time is long overdue for me to do it. Thank you for all the work you guys do and have done. Thank you for not penalize progress. Thank you for not being so rigid. Thank you for keeping the distribution moving and evolving. And finally, just thank you. From a proud Gentoo+systemd+GNOME 3 user, thank you. Regards. [1] https://lists.debian.org/debian-ctte/2014/01/threads.html [2] https://lists.debian.org/debian-ctte/2014/02/threads.html [3] http://lwn.net/Articles/584227/#Comments -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Thank you
On Thu, 6 Feb 2014 00:30:10 -0600 Canek Peláez Valdés can...@gmail.com wrote: Hi. TL;DR, this is basically just a THANK YOU to the Gentoo devs, so you can go on your daily business if you don't want to read the rest of it. No biggie. Hi. I just want to say THANK YOU to all of our Gentoo developers. I've been using Gentoo since ca. 2002 (damn, that's more than a decade), and I've seen a lot of flamewars and bikeshedding on the -dev mailing list. Have you seen this one? , __ \o ..=\ ___ | |___ --o / v \\---/ v \ ..=/ |--*--| |--*--| \_|_/\_|_/ It's a bike with flames; or well, if you can make that out of it. You can very well interpret it to be something else, maybe it looks like glasses or so with something on the side, I'm fine with that too. Maybe wearing this glasses would then make you be able to see the flames bike. Isn't Gentoo all about flamewars (a flame thrower burns things fast; we're wanting our system to be good at doing things fast, similar) and bikeshedding (we all want things our own way, which makes Gentoo what it is; a lot of possibilities giving you a lot of choice) anyway? However, you guys get the job done, and although there are some things that I would like to have sooner (or would have liked to have earlier), in the end the people working keep pushing the necessary changes so the distribution keeps going, and (if so desired) using new and interesting technologies. Which things would you like to see sooner? More importantly, the developers and the bureaucratic structures they have created don't get (too much) in the way of individual or small groups of developers pushing for progress. In general at least; there will be always someone resisting change, but in general Gentoo keeps advancing, and the council and the other bureaucratic structures don't punish people for just wanting to have more new and cool features in the distribution. It's a recipe for success I think; but we're not aiming for that as far as I know, or maybe some do (*shhh* Don't tell anyone that I or we do.), but as has came up once by someone, I think in the thread about automatically collecting information (eg. build logs) from users, Gentoo is there to just fulfill it for people whom have the need to it. Realistically I don't see Gentoo become a large distribution; or at least not by just doing what we're doing, however, we might see more people become interested in it. Who knows one day everyone needs it? I've never said Thank You to all our developers in all these years using Gentoo, Thank you too. :) but after seeing the discussion the Debian CTTE is having related to the default init they should use[1][2][3] (including bureaucratic maneuvers, dilatory tactics, legalese interpretation of their rulings, etc.), I think the time is long overdue for me to do it. Well, this makes me wonder if it is useful to have a default at all; probably it is, in the context of other distros. But for us, do we really need a default? I highly doubt it; we have OpenRC as a default because it simply is listed first, but how much does that really mean? It has come up a small few times that it might be interesting to have a systemd stage3 alongside the current OpenRC stage3; doing it this way, the user could pick in advance which init sytem the user wants as opposed to going through a painful migration to switch. Thank you for all the work you guys do and have done. Thank you for not penalize progress. Thank you for not being so rigid. Thank you for keeping the distribution moving and evolving. And finally, just thank you. From a proud Gentoo+systemd+GNOME 3 user, thank you. From a proud Gentoo+systemd+GNOME3 using developer, you're welcome. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
Re: [gentoo-portage-dev] [RFC] Location of Portage bash API (outside of ebuilds)
On Saturday, February 01, 2014 21:08:11 Arfrever Frehtes Taifersar Arahesis wrote: bin/isolated-functions.sh contains at least 1 useful function, which could be exposed for external consumers (without __ prefix), but must have private name (with __ prefix) when bin/isolated-functions.sh is used in ebuild environment. who are these mysterious external consumers ? what you propose means all funcs in there now become exported API and we now have to live with that. w/out any real background, i'm very hesitant to allow that. Possible solutions: 1. Make /usr/lib/portage/bin/isolated-functions.sh magically define non-private variants of useful functions when run in non-ebuild environment. this is a no-go. we should be cutting down on internal overhead. 2. Provide /usr/bin/portage.bash, which would source isolated-functions.sh (and maybe other files) and define non-private variants of useful functions. /usr/bin/portage.bash would be easier sourceable due to PATH. 3. Provide /usr/lib/portage.bash, which would source isolated-functions.sh (and maybe other files) and define non-private variants of useful functions. 4. Another location... (I would probably prefer solution #2.) sounds like a file that should be sourced only which imo bans it from $PATH. i'm aware of the magic shell behavior where `source` searches PATH, but that's not an acceptable reason imo. easy to add something like `portageq helpers-dir` that'd give you a path and then you use that to load the various scripts directly. -mike signature.asc Description: This is a digitally signed message part.
