Re: [gentoo-dev] Response to a "friendly note" about changing bug reports
On 08/07/2013 01:57 AM, Andreas K. Huettel wrote:
> Am Dienstag, 6. August 2013, 23:46:08 schrieb Jeroen Roovers:
>> 23:37:25 rej, you have notes! [21:13] Let me
>> rephrase this: Just a friendly notice to please refrain from rephrasing
>> bug summaries from "Stabilize ${P}" to "${P} stable req". This just
>> adds unneeded noise to the bug. I don't want this on bugs I've reported
>> or am assigned to.
>>
>>
>> This is my equally short and "friendly" note: It's not going to happen.
>> Forget about it. They are not "your" bug reports and anyone is
>> actually /welcome/ to improve them. Get used to it.
>>
>> To get technical on the "improvement" bit, we have agreed time on time
>> that stating the atom and then the action is the way to go. The main
>> reasons is that it helps people who need to regularly read /lists/ of
>> bug summaries sort them better. Until we get a specific [Atoms] field
>> implemented, it will need to stay this way.
>>
>
> Jer,
>
> please stop making whitespace noise on bugs that you have absolutely no
> relation to. It just causes unnecessary bugmail. If maintainers care they
> will
> change it themselves.
>
> Cheers,
> Andreas
Hi,
with all due respect Andreas but I think you missed the point of Jer's
mail. There's absolutely nothing like "relation to bug" or "bug
maintainership".
"Your" bug can only mean that you're responsible for fixing the issue
that was reported, not that you *own* that particular bit of bugzilla's
database...
Not so hypothetical situation: someone files a bug: "Fancy KDE mail
program fails with my gcc", you fix it and live happily ever after.
How on earth am I supposed to find it when porting/stabilizing newer
version of gcc?
I expect (as many others) something similar to "=kde-base/kmail-4.8.10
fails to build with gcc-4.8"
I deeply respect the work of people who fix bugzilla subjects to conform
to "atom: issue" format. It saves me a great deal of time.
Cheers,
Kacper
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Response to a "friendly note" about changing bug reports
Am Mittwoch, 7. August 2013, 10:46:04 schrieb Kacper Kowalik:
> On 08/07/2013 01:57 AM, Andreas K. Huettel wrote:
> > Am Dienstag, 6. August 2013, 23:46:08 schrieb Jeroen Roovers:
> >> 23:37:25 rej, you have notes! [21:13] Let me
> >> rephrase this: Just a friendly notice to please refrain from rephrasing
> >> bug summaries from "Stabilize ${P}" to "${P} stable req". This just
> >> adds unneeded noise to the bug. I don't want this on bugs I've reported
> >> or am assigned to.
> >>
> >
> > Jer,
> >
> > please stop making whitespace noise on bugs that you have absolutely no
> > relation to. It just causes unnecessary bugmail. If maintainers care they
> > will change it themselves.
> >
> > Cheers,
> > Andreas
>
[...]
>
> Not so hypothetical situation: someone files a bug: "Fancy KDE mail
> program fails with my gcc", you fix it and live happily ever after.
> How on earth am I supposed to find it when porting/stabilizing newer
> version of gcc?
> I expect (as many others) something similar to "=kde-base/kmail-4.8.10
> fails to build with gcc-4.8"
>
> I deeply respect the work of people who fix bugzilla subjects to conform
> to "atom: issue" format. It saves me a great deal of time.
That's fine, bug wranglers are doing a great job there.
However, I'm also sick of getting bugmail because $RANDOM_DEV thinks
* TRACKER is better than Tracker,
* every atom needs a "=" in front, and
* "Please stabilize XXX" should always be replaced by "XXX stabilization".
Remeber, I've been talking about effective whitespace noise.
--
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfri...@gentoo.org
http://www.akhuettel.de/
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Vanilla sources stabilization policy change
On Wed, 24 Jul 2013 16:09:11 -0700 Greg KH wrote: > Please > tell me exactly how you are going to evaluate which fixes I make are > security fixes, and you know which to pick and choose from. Some kind of annotation with tags would make this kind of thing easy; I'm not saying it is your task to apply such annotations to commits, but it would rather be the task of the person who makes an individual patch. This would benefit multiple people; it would benefit users to know the amount of patches that are security and code fixes, new features and see them separately. It would also benefit distributions and system admins to filter them out, they could for instance drop new feature patches so they just get the fixes they need. It puts the power in the user's hands; allowing them to evaluate, pick and choose according to their own demands and needs. Implementation wise, I don't think this is any harder than the already existing annotations; work wise, adding a tag is easy to do. Maybe I should write up something more technical and throw it at the upstream kernel ML for people to consider. Is there someone whom I need to CC in specific if I do that? -- 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] Vanilla sources stabilization policy change
On Wed, 24 Jul 2013 23:17:36 +0100 Markos Chandras wrote: > This thread derailed as usual. The kernel team made a decision. Perhaps it did, perhaps it didn't; I do not intend to discuss this but to rather clarify the decision that was made, as a matter of support. The reason the reply was on the ML is so it benefits more people. Granted, the ML isn't the right place for support though; if anyone has further doubts we invite them to mail the kernel herd about 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Vanilla sources stabilization policy change
On Sat, 27 Jul 2013 15:32:39 +0200 Manuel Rüger wrote: > On 07/27/2013 03:28 PM, Alexander Berntsen wrote: > > On 27/07/13 10:56, Chí-Thanh Christopher Nguyễn wrote: > >> How about dropping vanilla-sources and adding a "vanilla" USE flag > >> to gentoo-sources? > > Then we might as well just have a Linux package with a bunch of USE > > flags -- gentoo, hardened, libre, tuxonice, ck, etc. > > > > This is not a good idea, I'd like to have different kernel flavours of > the same version installed in parallel. If people think both ideas are good, consider having both? Adding USE flags without dropping the packages is also an option; the mere reason we will be bringing the experimental patches [1] soon is to spare out on some of the duplicate work that is being done, if people want to continue to maintain a separate package then nothing prohibits them from doing so. Not the experimental patches [1] idea, and not the addition of USE flags. That being said, I expressed earlier that USE flags feel like a bad idea though; I want you to keep in mind that, if you add USE flags, you effectively have a double opt-in since you need to enable the USE flag and then after that toggle the options in the menuconfig as well. Is the gain of adding USE flags really worth the burden it causes? [1]: http://article.gmane.org/gmane.linux.gentoo.kernel/740 -- 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] Response to a "friendly note" about changing bug reports
On 08/07/2013 11:04 AM, Andreas K. Huettel wrote:
> Am Mittwoch, 7. August 2013, 10:46:04 schrieb Kacper Kowalik:
>> On 08/07/2013 01:57 AM, Andreas K. Huettel wrote:
>>> Am Dienstag, 6. August 2013, 23:46:08 schrieb Jeroen Roovers:
23:37:25 rej, you have notes! [21:13] Let me
rephrase this: Just a friendly notice to please refrain from rephrasing
bug summaries from "Stabilize ${P}" to "${P} stable req". This just
adds unneeded noise to the bug. I don't want this on bugs I've reported
or am assigned to.
>>>
>>> Jer,
>>>
>>> please stop making whitespace noise on bugs that you have absolutely no
>>> relation to. It just causes unnecessary bugmail. If maintainers care they
>>> will change it themselves.
>>>
>>> Cheers,
>>> Andreas
>>
> [...]
>>
>> Not so hypothetical situation: someone files a bug: "Fancy KDE mail
>> program fails with my gcc", you fix it and live happily ever after.
>> How on earth am I supposed to find it when porting/stabilizing newer
>> version of gcc?
>> I expect (as many others) something similar to "=kde-base/kmail-4.8.10
>> fails to build with gcc-4.8"
>>
>> I deeply respect the work of people who fix bugzilla subjects to conform
>> to "atom: issue" format. It saves me a great deal of time.
>
> That's fine, bug wranglers are doing a great job there.
>
> However, I'm also sick of getting bugmail because $RANDOM_DEV thinks
> * TRACKER is better than Tracker,
This is pointless, indeed
> * every atom needs a "=" in front, and
> * "Please stabilize XXX" should always be replaced by "XXX stabilization".
Those two are actually useful. There are many scripts used by ATs that
parse title field. One could argue: "Fix your damn scripts" but in the
end it's your "bugspam" vs predicting all possible ways someone could
express an atom.
I seriously doubt that people are changing bug reports cause they break
their sense of aesthetics (/me waves to all OCDs out there). Most of the
changes have some underlying technical reason. Even if it's whitespace,
'=' or ordering.
Cheers,
Kacper
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Response to a "friendly note" about changing bug reports
On 07/08/13 11:46, Kacper Kowalik wrote: Not so hypothetical situation: someone files a bug: "Fancy KDE mail program fails with my gcc", you fix it and live happily ever after. How on earth am I supposed to find it when porting/stabilizing newer version of gcc? I expect (as many others) something similar to "=kde-base/kmail-4.8.10 fails to build with gcc-4.8" I deeply respect the work of people who fix bugzilla subjects to conform to "atom: issue" format. It saves me a great deal of time. +1, all package related bugs should be with $summary of '=category/package-version: problem'
Re: [gentoo-dev] Re: [gentoo-dev-announce] OpenRc-0.12 is coming soon
On Sat, 3 Aug 2013 10:28:59 -0500 William Hubbs wrote: > Markos, to answer your question, there are folks on the team, and at > least one user, using OpenRc from git without issues, so as far as I > know there shouldn't be any breakage. A few team developers is not a large enough test base for an important package that is to be installed and ran on _hundreds to thousands_ of user systems; I think you could reword future warnings to invite people to unmask and test this important package version bump, and then state it will be unmasked in X days if nothing bad gets reported. You might get away this time, but what if hell breaks loose next time? Besides that, as stated by others, such announcements are appreciated. Thank you for the heads-up! > I guess I was a little more harsh than I should have been, because I > know there are users out here who want ~arch to be rock solid, and I > have caught flack before from some of that crowd. Exactly, ~arch isn't the new stable; it isn't the new masked either. -- 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
[gentoo-dev] Re: Response to a "friendly note" about changing bug reports
On 7/08/2013 20:34, Kacper Kowalik wrote: * every atom needs a "=" in front, and * "Please stabilize XXX" should always be replaced by "XXX stabilization". Those two are actually useful. There are many scripts used by ATs that parse title field. One could argue: "Fix your damn scripts" but in the end it's your "bugspam" vs predicting all possible ways someone could express an atom. I seriously doubt that people are changing bug reports cause they break their sense of aesthetics (/me waves to all OCDs out there). Most of the changes have some underlying technical reason. Even if it's whitespace, '=' or ordering. Cheers, Kacper Which scripts require these rules? AT scripts have worked for a long time just fine, and adding "=" seems to be only fairly recent. I have started to summaries like "=foo-bar/baz-1.2.3 version bump" and even "=foo-bar/baz-1.2.3 new package". I don't see how changes like this add any value.
[gentoo-dev] Re: Response to a "friendly note" about changing bug reports
On 7/08/2013 07:46, Jeroen Roovers wrote: Besides the finer technical points of bug maintenance, it simply infuriates me that anyone would think of bug reports in the possessive. This is not the way to improve the distro. You're on the wrong track there. And you weren't being friendly. In this case, a bug is like a package. Nobody "owns" a package, but one or more people maintain it, and do so deliberately in a certain way. While there are general guidelines to follow, it's rude to barge in and change everything the way you want without asking. As for improving the distro, I am sure there are better ways to improve how we handle bugs instead of bickering about arbitrary bug changes. How we classify bugs is very inconsistent, and if anyone could formulate a good plan for Bugzilla improvements, it would be you. The atoms field you mentioned would be a great start. No kind regards to the sender, Please keep comments like that to yourself. They are both unprofessional and completely unnecessary.
Re: [gentoo-dev] Re: [gentoo-dev-announce] OpenRc-0.12 is coming soon
On Wed, Aug 7, 2013 at 6:44 AM, Tom Wijsman wrote: > On Sat, 3 Aug 2013 10:28:59 -0500 > William Hubbs wrote: > >> Markos, to answer your question, there are folks on the team, and at >> least one user, using OpenRc from git without issues, so as far as I >> know there shouldn't be any breakage. > > A few team developers is not a large enough test base for an important > package that is to be installed and ran on _hundreds to thousands_ of > user systems; I think you could reword future warnings to invite people > to unmask and test this important package version bump, and then state > it will be unmasked in X days if nothing bad gets reported. If a maintainer thinks that such a testing period is warranted they're welcome to call for it. However, I certainly wouldn't make it a requirement for putting a package into ~arch - even a system package. If hundreds to thousands of users are running ~arch, then that means that we have hundreds to thousands of users who don't mind their systems occasionally not booting after an upgrade. Besides, who does an emerge -u world without first checking to see what will be updated? If I see openrc on the list I certainly don't run the upgrade over ssh while I'm on vacation, and I always make a binary package with config before doing so. ~arch is for testing. That's what you sign up for if you run it. You ARE the volunteer. Rich
Re: [gentoo-dev] Response to a "friendly note" about changing bug reports
On Wed, 7 Aug 2013 11:04:28 +0200 "Andreas K. Huettel" wrote: > That's fine, bug wranglers are doing a great job there. > > However, I'm also sick of getting bugmail because $RANDOM_DEV thinks > * TRACKER is better than Tracker, > * every atom needs a "=" in front, and This is wrong btw. Some people already closed some bugs like 'rekeyword =cat/pkg-version' because said version was not in tree anymore. Heck, this was months later and there was a newer version. Now I just fill 'rekeyword latest cat/pkg' and expect people not to mess with summary. Alexis.
Re: [gentoo-dev] Response to a "friendly note" about changing bug reports
On Tue, 6 Aug 2013 23:46:08 +0200
Jeroen Roovers wrote:
> 23:37:25 rej, you have notes! [21:13] Let me
> rephrase this: Just a friendly notice to please refrain from
> rephrasing bug summaries from "Stabilize ${P}" to "${P} stable req".
> This just adds unneeded noise to the bug. I don't want this on bugs
> I've reported or am assigned to.
>
> This is my equally short and "friendly" note: It's not going to
> happen. Forget about it. They are not "your" bug reports and anyone is
> actually /welcome/ to improve them. Get used to it.
This note doesn't really hold well; if two people, not necessarily the
reporter or assignee of a bug, want to do opposing improvements then
you get an edit war as a result. In mrueg's words, "unneeded noise".
The concern is valid; if a person is bothered by changes you make, that
person won't get used to those changes at all if they can be undone.
-> Why do you think there's only one way of doing it?
While I don't know how to search for such change; the last unneeded
noise I remember you doing to a bug is adding or removing the dot at
the end of a bug summary, doing nothing else to the bug.
There are sites, like Stack Exchange, where you are forced to edit
multiple characters and type out a summary that explains what you did,
as well as providing an easy rollback option; to avoid unneeded edits.
It's hand holding because almost anyone can edit on such site; from
what I've saw, it really works out well but shouldn't be necessary.
-> What does such small unimportant change gain you?
Not that I'm bothered, because that was just one extra mail; but
repetitively doing stuff similar to this generates much more than just
one extra mail, so I get to see multiple mails of this type over the
place. And while you're just one person, there are others too; it adds
up, up to the point that it's really just a waste of time.
-> Why do you think the burden generated from this is worth it?
> To get technical on the "improvement" bit, we have agreed time on time
> that stating the atom and then the action is the way to go.
Who is "we"? Why is it the "way to go"? If you use such language you
need to link to the actual evidence; otherwise, despite the reasoning
you give, it will be seen as an authoritative contradiction instead of
an actual counterargument. You and I know when that was decided, but a
new developer doesn't; well, at least I know of the last time it did:
http://article.gmane.org/gmane.linux.gentoo.devel/85647
You do the same thing there with "we agreed a little while ago"; and
upon request of djc, phajdan.jr and myself there appears to have been
no response, only to later be answered by someone else that knows:
http://www.gossamer-threads.com/lists/gentoo/dev/173889
As far as I know, there is no requirement to read the entire mail
archives and this is undocumented; so, as it is not always as easy to
search matters like this (wrong search terms, result on last page, ...)
it would help a lot if things were referred to.
Otherwise people might simply ignore your statements, discuss it again
or just apply the opposite changes; neither of which is what you want.
> The main reasons is that it helps people who need to regularly
> read /lists/ of bug summaries sort them better. Until we get a
> specific [Atoms] field implemented, it will need to stay this way.
Has someone already filed a bug with a request for this?
> Besides the finer technical points of bug maintenance, it simply
> infuriates me that anyone would think of bug reports in the
> possessive.
It's actually more natural. Again using Stack Exchange as an example, a
lot of question titles there tend to be an actual question because
some people think it reads much better; I don't think that this is
necessarily a good idea for bug summaries, but just want to point out
that it is a possibility.
Putting the atom first focuses on a summary that feels a bit more
machine readable; whereas if you put it into a sentence, it gives a bit
more freedom to express it as an actual sentence. It's weird to think
about the other way if you're used to one way; but, I consider the end
result rather equal, which you probably do as well as it is easy to
change between the formats.
We can go on for this for a long time, but that would be bike shedding;
s,o I just wanted to demonstrate that there are at actually at least two
sides on the matter. As agreed in earlier threads, the list readability
is indeed a valid reason until a more proper field becomes implemented.
Besides that, I think there are much bigger concerns; let me take a
random bug title "dnsmasq systemd unit file improvement" and point out
that it bothers me more not knowing what the improvement is, let's say
you have another bug like this then how would you tell them apart?
Knowing which improvements the bug consists of, helps to process the list.
> This is not the way to improve the distro. You're on the
> wrong track there. And you weren't being friendly.
Have
Re: [gentoo-dev] Response to a "friendly note" about changing bug reports
On Wed, 07 Aug 2013 10:46:04 +0200 Kacper Kowalik wrote: > Not so hypothetical situation: someone files a bug: "Fancy KDE mail > program fails with my gcc", you fix it and live happily ever after. > How on earth am I supposed to find it when porting/stabilizing newer > version of gcc? > I expect (as many others) something similar to "=kde-base/kmail-4.8.10 > fails to build with gcc-4.8" We usually take it a step further, putting the actual error there; if the maintainer reads the error, it will be clear it failed to build: "=kde-base/kmail-4.8.10 with GCC 4.8 - File:Line:Char: Error: Reason" > I deeply respect the work of people who fix bugzilla subjects to > conform to "atom: issue" format. It saves me a great deal of time. Thank you. As a side note, I believe the separator for this format isn't defined; I see people as well as myself commonly use " - " as a separator, so I'm not sure where the ": " separator came from and don't see it as something to conform to (neither do I see " - " as such). This mail isn't meant to start a bike shed, but I just don't want either format to be seen as the definitive format; unless of course, there has been a prior consensus on what the separator should be. If there has been a prior discussion, and this is why I reply, I would like to know. -- 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] Response to a "friendly note" about changing bug reports
On Wed, 7 Aug 2013 11:04:28 +0200 "Andreas K. Huettel" wrote: > However, I'm also sick of getting bugmail because $RANDOM_DEV thinks > > * every atom needs a "=" in front, and > * "Please stabilize XXX" should always be replaced by "XXX > stabilization". For these two I've been guilty; but, that shouldn't actually matter in case of my edits as I always try to combine them with another useful change. I agree with you that sole edits just to change that aren't really useful. I'm not sure about others, I think it would help if some of these bug mails where quoted; such that it is a bit more clear. But if it is combined with other useful edits it helps to make the summaries more consistent in general, a lot of new mail that gets assigned to maintainers comes through the bug wranglers so if there's one place we can fight for consistency then it is there. Unless combined with necessary changes, bug wranglers shouldn't make such changes on already assigned bugs; as it is not their terrain. -- 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] Response to a "friendly note" about changing bug reports
On 08/06/2013 11:46 PM, Jeroen Roovers wrote:
> 23:37:25 rej, you have notes! [21:13] Let me
> rephrase this: Just a friendly notice to please refrain from rephrasing
> bug summaries from "Stabilize ${P}" to "${P} stable req". This just
> adds unneeded noise to the bug. I don't want this on bugs I've reported
> or am assigned to.
>
>
> This is my equally short and "friendly" note: It's not going to happen.
> Forget about it. They are not "your" bug reports and anyone is
> actually /welcome/ to improve them. Get used to it.
>
> To get technical on the "improvement" bit, we have agreed time on time
> that stating the atom and then the action is the way to go. The main
> reasons is that it helps people who need to regularly read /lists/ of
> bug summaries sort them better. Until we get a specific [Atoms] field
> implemented, it will need to stay this way.
>
> Besides the finer technical points of bug maintenance, it simply
> infuriates me that anyone would think of bug reports in the possessive.
> This is not the way to improve the distro. You're on the wrong track
> there. And you weren't being friendly.
>
>
I don't see any issue here. You are a bug wrangler and should have the
authority to mess with anything in bugzilla.
However, if you have scripts that rely on such specific form of bug
title, then they are broken.
If you have issues to sort/read use a proper mail client with filtering
options.
On 08/07/2013 11:04 AM, Andreas K. Huettel wrote:
> However, I'm also sick of getting bugmail because $RANDOM_DEV thinks
> * TRACKER is better than Tracker,
> * every atom needs a "=" in front, and
> * "Please stabilize XXX" should always be replaced by "XXX stabilization".
>
> Remeber, I've been talking about effective whitespace noise.
>
And here too: How you set up your mail client is your own problem.
Seems people are more interested in bikesheddings threads than those
that point out problems no one has addressed in years.
[gentoo-dev] Gnome Stabilization 3.6 or 3.8
Greetings, Gnome Herd decided to target stablilization of 3.8 [1] which requires systemd. What are the reasons to stable 3.8 and not 3.6, a version w/o this restriction, enabling all non systemd users to profit from this eye-candy as well. I raise the freedom of choice card here. And deliberately choosing an uncooperative version doesn't shine a good light. Facts, pls! Michael [1] https://bugs.gentoo.org/show_bug.cgi?id=478252 -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
[gentoo-dev] Re: Response to a "friendly note" about changing bug reports
On 7/08/2013 22:18, Tom Wijsman wrote: We usually take it a step further, putting the actual error there; if the maintainer reads the error, it will be clear it failed to build: "=kde-base/kmail-4.8.10 with GCC 4.8 - File:Line:Char: Error: Reason" Is there any benefit to adding = in this case?
[gentoo-dev] Re: Response to a "friendly note" about changing bug reports
On 7/08/2013 22:41, hasufell wrote: You are a bug wrangler and should have the authority to mess with anything in bugzilla. Don't forget that anybody can start a project, even if it conflicts with other projects. While Jeroen's experience certainly gives him a more insight regarding bugzilla issues, making anyone the ultimate authority on anything does not fit in with our current metastructure.
Re: [gentoo-dev] Re: [gentoo-dev-announce] OpenRc-0.12 is coming soon
On Wed, 7 Aug 2013 08:00:51 -0400 Rich Freeman wrote: > On Wed, Aug 7, 2013 at 6:44 AM, Tom Wijsman wrote: > > On Sat, 3 Aug 2013 10:28:59 -0500 > > William Hubbs wrote: > > > >> Markos, to answer your question, there are folks on the team, and > >> at least one user, using OpenRc from git without issues, so as far > >> as I know there shouldn't be any breakage. > > > > A few team developers is not a large enough test base for an > > important package that is to be installed and ran on _hundreds to > > thousands_ of user systems; I think you could reword future > > warnings to invite people to unmask and test this important package > > version bump, and then state it will be unmasked in X days if > > nothing bad gets reported. > > If a maintainer thinks that such a testing period is warranted they're > welcome to call for it. --- TL;DR, clarifying intention --- True, I'm merely outlining the possibility for them to consider. > However, I certainly wouldn't make it a requirement for putting a > package into ~arch - even a system package. This should indeed be no requirement, there isn't really a group of packages you could simply label "must be tested as masked"; taking this thread an example you could say 0.11.x -> 0.12 could use testing whereas 0.12.0 -> 0.12.1 or a future 0.14.x -> 0.15 might/will need not. It kind of depends on the details of the change log; but when a maintainer announces that things might break and only a very small amount of people tested it, it is worth a concern and consideration. --- Reasoning, feel free to ignore --- > If hundreds to thousands of users are running ~arch, then that means > that we have hundreds to thousands of users who don't mind their > systems occasionally not booting after an upgrade. Still, why do we need to break hundreds to thousands of users with something that is easily avoided by first letting some more people test it before releasing it to the masses. Let's say you release it to the masses; there appears to be something heavily broken disallowing a wide enough share of people to not be able to boot their system, then you apply the package mask after the fact. You just got a lot of people to install something that is broken and gets masked just the day after release causing a downgrade again; something that could have been added as masked right away, because really, the maintainer didn't know if it was ready for wide testing. In terms of machine and man power, there's still a huge considerable difference between breaking the system of a few users and some hundreds users; if you can avoid the latter, why not do it? "Broken" is free for interpretation; while most people don't mind that their system does not boot after the upgrade, the story gets somewhat different if their system got in an inconsistent state where a simple downgrade doesn't appear to work. Please note that some people run ~ because they can't mix non-~ and ~, because they need to run GNOME 3, because they find the stable gap too big or are bothered by packages that don't get stabilized on time. Anyhow, discussing the borders is bike shedding; it's just a suggestion. > Besides, who does an emerge -u world without first checking to see > what will be updated? If I see openrc on the list I certainly don't > run the upgrade over ssh while I'm on vacation, and I always make a > binary package with config before doing so. Some people do, but that's not what this is about. > ~arch is for testing. That's what you sign up for if you run it. You > ARE the volunteer. When a maintainer says "might be broken", it means that the maintainer doesn't know whether the package belongs to ~ or package.mask; so, that also means not enough testing has been done to consider adding it to ~. It's at the maintainer's decision to go ahead or not; there's nobody going to stop the maintainer from adding it to ~. But there are people that going to complain (users), take action (QA), ... when hell does break loose because of careless maintenance; putting something in package.mask for some days doesn't hurt people, big breakage does. -- 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] Gnome Stabilization 3.6 or 3.8
On Wed, 2013-08-07 at 14:45 +0200, Michael Weber wrote: > Greetings, > > Gnome Herd decided to target stablilization of 3.8 [1] which requires > systemd. > > What are the reasons to stable 3.8 and not 3.6, a version w/o this > restriction, enabling all non systemd users to profit from this > eye-candy as well. > > I raise the freedom of choice card here. And deliberately choosing an > uncooperative version doesn't shine a good light. > > Facts, pls! > >Michael > > [1] https://bugs.gentoo.org/show_bug.cgi?id=478252 To stabilize gnome-3.6, we would need 1. one or (preferably) two *active* gentoo developers; 2. who are familiar with gnome's internals and are able to backport bugfixes from 3.8/3.10 without support from upstream developers; and 3. who volunteer to run openrc+gnome-3.6 for a long time on their main machines so that they can give a stable 3.6 the support that the word 'stable' implies. We do not have such people on the gnome team.
Re: [gentoo-dev] Re: Response to a "friendly note" about changing bug reports
On Wed, 07 Aug 2013 22:45:55 +1000 Michael Palimaka wrote: > On 7/08/2013 22:18, Tom Wijsman wrote: > > We usually take it a step further, putting the actual error there; > > if the maintainer reads the error, it will be clear it failed to > > build: > > > > "=kde-base/kmail-4.8.10 with GCC 4.8 - File:Line:Char: Error: > > Reason" > > Is there any benefit to adding = in this case? Quoted that from his reply; but I confess I add this to summaries because it makes it an acceptable package atom, for scripts to use. Just an example: > # emerge 'sys-devel/gcc-4.8' > !!! 'sys-devel/gcc-4.8' is not a valid package atom. > !!! Please check ebuild(5) for full details. > > # emerge '=sys-devel/gcc-4.8' > > These are the packages that would be merged: I think the logic to automatically add '=' is not as easy as checking the first character and requires some more effort to implement; so, having usable atoms sounds like a more handy approach. If package atoms had their separate atom(s) field then this would no longer be a requirements; but until then, we can only help this way. Not sure if people actually run scripts against Bugzilla; but working towards that way should be something to consider, because it would ease to run scripts against it. One that comes to mind is to check the entire bug list (you can download those [1]) for package atoms which can no longer be satisfied; that way, you could detect some things: 1. Typos in package names, this improves searching for those bugs. 2. Versions no longer in the Portage tree, this helps find old bugs; as well as allows a tester to test those bugs in specific to see if they still happen for newer versions. Or ask the user to test again. 3. Bugs that have already been fixed, some bugs are canonical and always use the same syntax as they are filed by other scripts; for such bugs we could check if the bug still occurs by doing a build test for them. The resources needed for this is questionable, but it's just one idea of many; all what package atoms can help do. [1]: https://bugs.gentoo.org/bots.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 signature.asc Description: PGP signature
Re: [gentoo-dev] Response to a "friendly note" about changing bug reports
On Wed, 07 Aug 2013 14:41:14 +0200 hasufell wrote: > I don't see any issue here. You are a bug wrangler and should have the > authority to mess with anything in bugzilla. As far as I know people in that project are no different from people out of that project; you could start a similar project, or something totally different but that doesn't give you extra authority or permissions. If such thing has been written down for the bug wranglers project then I would like to see; but until then, this is merely an unreferenced contradiction and not an an actual counter argument. There is an issue. > However, if you have scripts that rely on such specific form of bug > title, then they are broken. I wish summaries were collaboratively made that way; until then, we can only fight for some consistency in places where we don't create noise or have to explain our reasoning again and again and ... > If you have issues to sort/read use a proper mail client with > filtering options. By those lists mail clients aren't necessarily meant; there is https://bugs.gentoo.org/bots.html as well as the option to send whine mails, which aren't necessarily as easy as to process as what you have on mind. Especially not since no proper package atoms are used as well as it isn't fool proof to decide whether a part of a sentence is a package atom or not; when you're dealing with error output from compiler and what not, you can't simply assume */* syntax to suffice. > On 08/07/2013 11:04 AM, Andreas K. Huettel wrote: > > However, I'm also sick of getting bugmail because $RANDOM_DEV > > thinks > > * TRACKER is better than Tracker, > > * every atom needs a "=" in front, and > > * "Please stabilize XXX" should always be replaced by "XXX > > stabilization". > > > > Remeber, I've been talking about effective whitespace noise. > > > > And here too: How you set up your mail client is your own problem. Yes and no, how does my mail client know the border line between an useful and an useless change; while NLP goes some way, it isn't fool proof and it will be a problem for everyone. It's not a good solution. > Seems people are more interested in bikesheddings threads than those > that point out problems no one has addressed in years. Agreed, we could use and force some more constructiveness; until then, we will need to be selective in what we read, respond and ignore. -- 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] Response to a "friendly note" about changing bug reports
On Wed, Aug 7, 2013 at 8:07 AM, Alexis Ballier wrote: > On Wed, 7 Aug 2013 11:04:28 +0200 > "Andreas K. Huettel" wrote: >> That's fine, bug wranglers are doing a great job there. >> >> However, I'm also sick of getting bugmail because $RANDOM_DEV thinks >> * TRACKER is better than Tracker, >> * every atom needs a "=" in front, and > > This is wrong btw. Some people already closed some bugs like 'rekeyword > =cat/pkg-version' because said version was not in tree anymore. Heck, > this was months later and there was a newer version. Now I just fill > 'rekeyword latest cat/pkg' and expect people not to mess with summary. I think the proper workflow in a situation like this is: 1. (Optional) Random interested party sends bug to maintainer asking for keywording. That one is not tagged with a version for the reasons you state. 2. Maintainer agrees and picks a stable candidate, and modifies the subject to include a specific version. At the appropriate time archs are CC'ed. If you want to STABLEREQ a package you can't just target the "latest version" - maintainers should be picking stable targets and many maintainers bump packages weekly and drop the old version so that none of them hit the 30-day threshold. Maintainers should be cooperative in getting packages stabilized as long as it makes sense (some packages are inherently incompatible with the stable concept, such as ones dependent on some cloud API that changes without warning). Rich
Re: [gentoo-dev] Re: Response to a "friendly note" about changing bug reports
On Wed, 07 Aug 2013 22:55:45 +1000 Michael Palimaka wrote: > On 7/08/2013 22:41, hasufell wrote: > > You are a bug wrangler and should have the > > authority to mess with anything in bugzilla. > > Don't forget that anybody can start a project, even if it conflicts > with other projects. While Jeroen's experience certainly gives him a > more insight regarding bugzilla issues, making anyone the ultimate > authority on anything does not fit in with our current metastructure. And if there's a disagreement (that's not a bike shed and thus has a valid reasoning); things need to be discussed, documented and acted. In that order. [1] What we're seeing here is the lack of documentation; so, people act without having something _simple_ to refer to which causes some extra effort to explain or discuss the matter again whereas otherwise a simple link to a piece of documentation or policy would suffice. Not everything has to be documented; but really, it's like the third or more time already that we've been talking about this. It would be nice to see this being written up and placed in a place we can refer to. I'm not sure what the right place would be though; the bug wrangling project, developer handbook (policy section) or perhaps something else? [1]: For completeness, with council matters add "decided" as second. -- 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: Response to a "friendly note" about changing bug reports
On Wed, Aug 7, 2013 at 8:55 AM, Michael Palimaka wrote: > On 7/08/2013 22:41, hasufell wrote: >> >> You are a bug wrangler and should have the >> authority to mess with anything in bugzilla. > > Don't forget that anybody can start a project, even if it conflicts with > other projects. While Jeroen's experience certainly gives him a more insight > regarding bugzilla issues, making anyone the ultimate authority on anything > does not fit in with our current metastructure. Having two bug wrangler projects whose main function ends up being fighting revert wars over subject line formatting and writing policies denouncing the other project is counter-productive. If you have strong feelings and want to contribute to how bugs are managed, join the bug wranglers. The bug wranglers project does need to hold elections for leads per the policy you just cited. It is better for people to first try to work together before they just dig in and start fighting each other. If things are out of hand ask the Council to step in. My two cents - I think that what Jer is doing is mostly a value-add. I wouldn't go changing subject lines to just remove a period, but more substantive edits should be welcome if it improves consistency. It might be nice if we could somehow flag such revisions so that emails are either suppressed or marked as trivial edits, so that everybody could filter their bugspam accordingly. Don't get me wrong - I like GLEP 39 and the idea of allowing "competing projects." However, the intent of that wasn't really to endorse wars over things that are basically indivisible, like bugzilla. If you wanted to start up your own alternative next-gen bugzilla go ahead, though the distro should probably treat it like an experiment until it is ready to go. OpenRC is an example of where starting over was a big improvement. However, the point is that we didn't have two projects fighting over commits to baselayout-1 - we recognized the opportunities of starting over. Also, starting over simply to avoid the need to cooperate is dumb - it might not be forbidden, but it is dumb. When we start something over it should be because it just makes sense to do it that way. Rich
Re: [gentoo-dev] Re: [gentoo-dev-announce] OpenRc-0.12 is coming soon
On Wed, Aug 7, 2013 at 9:01 AM, Tom Wijsman wrote: > It's at the maintainer's decision to go ahead or not; there's nobody > going to stop the maintainer from adding it to ~. But there are people > that going to complain (users), take action (QA), ... when hell does > break loose because of careless maintenance; putting something in > package.mask for some days doesn't hurt people, big breakage does. We're basically on the same page, so I won't respond to most of your email. However, in general I'm not a big fan of putting heads on pikes when their only sin was a failure to be lucky. Careless maintainers should be corrected. However, if we're accepting the right level of risk then occasional problems in ~arch should be expected. They should be rare, but when individual problems come up we need to be careful before we assign blame to the maintainer. If they were generally accepting the right level of risk and they're just the guy who drew the short straw this time, we should simply move on. If we're not happy with the overall level of risk then that is something that requires a change distro-wide. Whether we're at the right level of risk is best measured distro-wide. I have to say that QA on Gentoo is FAR better than it ever has been in the past. I can't remember the last time I had widespread breakage as the result of an upgrade. I think the biggest thing that slipped through recently that I took notice of was a pre-mature stabilization of apache-2.4 (for a day or so before being reverted). It worked just fine, but required substantial config changes and lacked appropriate news/docs/etc. I'm not inviting a reduction in QA. However, right now I don't think we need to crack the whip on it either. Let's hold the line, but for the most part maintainers can use discretion. Rich
Re: [gentoo-dev] Response to a "friendly note" about changing bug reports
On Wed, 2013-08-07 at 09:35 -0400, Rich Freeman wrote: > On Wed, Aug 7, 2013 at 8:07 AM, Alexis Ballier wrote: > > On Wed, 7 Aug 2013 11:04:28 +0200 > > "Andreas K. Huettel" wrote: > >> That's fine, bug wranglers are doing a great job there. > >> > >> However, I'm also sick of getting bugmail because $RANDOM_DEV thinks > >> * TRACKER is better than Tracker, > >> * every atom needs a "=" in front, and > > > > This is wrong btw. Some people already closed some bugs like 'rekeyword > > =cat/pkg-version' because said version was not in tree anymore. Heck, > > this was months later and there was a newer version. Now I just fill > > 'rekeyword latest cat/pkg' and expect people not to mess with summary. > > I think the proper workflow in a situation like this is: > > 1. (Optional) Random interested party sends bug to maintainer asking > for keywording. That one is not tagged with a version for the reasons > you state. > > 2. Maintainer agrees and picks a stable candidate, and modifies the > subject to include a specific version. At the appropriate time archs > are CC'ed. > > If you want to STABLEREQ a package you can't just target the "latest > version" - maintainers should be picking stable targets and many > maintainers bump packages weekly and drop the old version so that none > of them hit the 30-day threshold. Maintainers should be cooperative > in getting packages stabilized as long as it makes sense (some > packages are inherently incompatible with the stable concept, such as > ones dependent on some cloud API that changes without warning). > > Rich Alexis was talking about KEYWORDREQ, not STABLEREQ. When asking to readd a keyword, you almost always want that keyword for whatever is the highest version in a specific slot, even if that version has been in the tree for three days, and you filed the keywording bug two months ago.
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Wed, 07 Aug 2013 09:14:14 -0400 Alexandre Rostovtsev wrote: > On Wed, 2013-08-07 at 14:45 +0200, Michael Weber wrote: > > > What are the reasons to stable 3.8 and not 3.6, a version w/o this > > restriction, enabling all non systemd users to profit from this > > eye-candy as well. > > > > I raise the freedom of choice card here. And deliberately choosing > > an uncooperative version doesn't shine a good light. > > To stabilize gnome-3.6, we would need > > 1. one or (preferably) two *active* gentoo developers; > 2. who are familiar with gnome's internals and are able to backport > bugfixes from 3.8/3.10 without support from upstream developers; and > 3. who volunteer to run openrc+gnome-3.6 for a long time on their main > machines so that they can give a stable 3.6 the support that the word > 'stable' implies. > > We do not have such people on the gnome team. There's going to be a lot of complaints and rant about this, some of which has already started in some places like the forums; as far as I see I barely see people raising their hands to put in the work. At most I recall some work here and there by one or two individuals, but in all seriousness I don't think that's enough to pull it off. While people can scream, complaint and rant all they want about choice; it isn't going to happen if nobody is going to implement it, until that happens following whatever upstream does is the only reasonable thing to do. Or if you really want to help, help implement the choice... :) It's not enough to just re-introduce support as well as to port back part of that support, which they don't seem to even have currently for 3.8; it goes a lot further than that, as mentioned by tetromino, the fixes have to be ported back as well. Let's say if they ignore all that and do stabilize 3.6; then they are just moving this problem, because then they won't end up getting 3.8 or later stabilized in the future because of the same objection. Using systemd and GNOME 3.8.3 on a daily basis, I haven't been able to run the entire 3.6 and 3.8 until a late fix [1] that took me weeks to find in all the seas of debugging information I have enabled; there are some other reports of users having similar and other issues, so I deem fixes like those are necessary for stabilization. Because really, they shouldn't be stabilizing something they know is heavily broken for some users; thus in its current state, 3.6 isn't really a good candidate. [1]: https://bugzilla.gnome.org/show_bug.cgi?id=704286 -- 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] Response to a "friendly note" about changing bug reports
On Wed, Aug 7, 2013 at 9:55 AM, Alexandre Rostovtsev wrote: > Alexis was talking about KEYWORDREQ, not STABLEREQ. When asking to readd > a keyword, you almost always want that keyword for whatever is the > highest version in a specific slot, even if that version has been in the > tree for three days, and you filed the keywording bug two months ago. ++
Re: [gentoo-dev] Re: Response to a "friendly note" about changing bug reports
On Wed, 7 Aug 2013 09:46:49 -0400 Rich Freeman wrote: > Having two bug wrangler projects whose main function ends up being > fighting revert wars over subject line formatting and writing policies > denouncing the other project is counter-productive. Whether you have two individuals or two projects, that's not going to make any difference; they'll still be fighting, that's why the matter needs to be discussed, (decided,), documented and then acted upon. > If you have strong feelings and want to contribute to how bugs are > managed, join the bug wranglers. Asked several times to be added, I'm still not listed; and as far as I am aware, people aren't eligible to just ask themselves to the page without acknowledgment. > The bug wranglers project does need to hold elections for leads per > the policy you just cited. It is better for people to first try to > work together before they just dig in and start fighting each other. The lead has final words on the project, things like the alias and the project documentation; but that doesn't give the lead final words on how things should go on Bugzilla, which needs to be agreed (or at least opposed for trivial matters) with by other developers. > If things are out of hand ask the Council to step in. The things we're discussing are too trivial, I really hope this isn't necessary; but yeah, there's going to come a point we need to do that if it keeps going on like this. > My two cents - I think that what Jer is doing is mostly a value-add. > I wouldn't go changing subject lines to just remove a period, but more > substantive edits should be welcome if it improves consistency. Same thought here, but it's the flip side of that what we're discussing; the noise that it brings, perhaps we should aim for a solution where the noise can be filtered out. Perhaps create a permission group whom gets a checkbox option to not send a mail; then list the changes made with that checkbox option on a separate easy to skim page, such that they can still be processed to check for tampering if it is suspected. I'll be happy to massively apply changes people have agreed on; but, I currently don't do such thing because of the amount of mails it generates. As well as the amount of people that are unaware of the decision thus requiring the extra work to explain the matter. > It might be nice if we could somehow flag such revisions so that > emails are either suppressed or marked as trivial edits, so that > everybody could filter their bugspam accordingly. Hmm, haven't read your full mail; I see now that you suggest something similar. So, let's just say I agree verbosely with trivial edit filter. > Don't get me wrong - I like GLEP 39 and the idea of allowing > "competing projects." However, the intent of that wasn't really to > endorse wars over things that are basically indivisible, like > bugzilla. When I read words like "wars" I'd hope you consider good faith from people; I don't thing anyone here is really trying to make war on purpose, as in trying to overtaking the lead of a project or forcing something particular. On the other hand, I think there are some people assuming that they have more priveleges and permissions than they really have; which causes some changes to happen that might be perceived as competing / war while they really are meant to do good. > If you wanted to start up your own alternative next-gen > bugzilla go ahead, though the distro should probably treat it like an > experiment until it is ready to go. Possibly, but it be just another experiment waiting in a slowly progressing queue; the one the CVS --> Git move is in. We have to be fair, while experiments are neat and all that; they have hardly became successful lately, it's as if our base is somewhat stable and we're afraid to change it. Thinking it through, it's more worth it to fork than to fight something which doesn't happen any time soon; and perhaps might never happen in the future. That's just my perceived view; there are possibly some other views, like lack of man power, as well... > Also, starting over simply to avoid the need to cooperate is dumb - > it might not be forbidden, but it is dumb. When we start something > over it should be because it just makes sense to do it that way. Not really; I would love to see Portage heavily refactored or rewritten, because its Portage tree recalculation is getting slower and slower with time and with upcoming EAPI features as well as problems like not being able to parallelize it it is becoming worse and worse. Do you think zmedico will collaborate if I start sending massive patches that break possibly all other patches filed against him, or that I would ever finishing refactoring or rewriting if I have to port all those patches; I don't think so, sometimes you need to throw things overboard and start over without any form of collaboration. Some of the greatest efforts are done alone, not by a team but by an individual; because unnecessary col
Re: [gentoo-dev] Re: [gentoo-dev-announce] OpenRc-0.12 is coming soon
On Wed, 7 Aug 2013 09:55:05 -0400 Rich Freeman wrote: > We're basically on the same page, so I won't respond to most of your > email. Same. > I have to say that QA on Gentoo is FAR better than it ever has been in > the past. It is definitely very good; the only thing that currently bothers me, is not in terms of breakage but rather in terms of news and docs / wiki. There are some cases here and there where some headaches, rant and such could be prevented with a simple news item explaining how to deal with a particular change in the Portage tree and explaining why the particular change happened; currently I feel the news items are used to sparingly, but that's a thing on its own. I'll try to catch these occurences in the future and attempt to bring them to the mailing list to show what I mean; but well, they're usually not so big problems. As for big breakage, it hasn't happened lately; I just don't want to see it again. I believe there's going to become a day it happens, because people just don't care because it hasn't happened for some time; at which point it would have been easier to prevent than to cover up. > I'm not inviting a reduction in QA. However, right now I don't think > we need to crack the whip on it either. Let's hold the line, but for > the most part maintainers can use discretion. Yeah, no change required; maybe my advice ends up being useless, or not. -- 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: Response to a "friendly note" about changing bug reports
On Wed, 7 Aug 2013 16:23:22 +0200 Tom Wijsman wrote: > > If you have strong feelings and want to contribute to how bugs are > > managed, join the bug wranglers. > > Asked several times to be added, I'm still not listed; This appears to have been a communication problem, in specific with what the words "bug wrangler" mean, I intended them as project member when asking which does not reflect reality; I take these words back. > and as far as I am aware, people aren't eligible to just ask > themselves to the page without acknowledgment. There appears to be no policy on this as far as I am aware of and others told me; so, it's often more of a politeness thing. -- 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: Response to a "friendly note" about changing bug reports
On Wed, Aug 7, 2013 at 10:23 AM, Tom Wijsman wrote: > Possibly, but it be just another experiment waiting in a slowly > progressing queue; the one the CVS --> Git move is in. We have to be > fair, while experiments are neat and all that; they have hardly became > successful lately, it's as if our base is somewhat stable and we're > afraid to change it. I think that could describe MANY of the issues we've been facing. Gentoo is a ricer distro that aims to be useful. There, I said it. :) There is a natural conflict between having everything "just work" and progress, especially when you don't have a lot of manpower. Many of our remaining cvs->git issues, for example, stem from our wanting to improve on the status quo. If we just wanted a git repo that devs can push to, we could have that today. We already have the infrastructure running our overlays, and we already have a git migration process that seems to be working fine. However, there are a lot of value-adds that will take time to implement (figuring out tree-signing, verification, if we can ditch changelogs and manifests, etc). There is also some back-end work that needs to be done where few have access to the code to work on it. I believe Robin announced that he was going to make that a big focus of his work in the coming months, for which we should be grateful. Rich
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
El mié, 07-08-2013 a las 14:45 +0200, Michael Weber escribió: > Greetings, > > Gnome Herd decided to target stablilization of 3.8 [1] which requires > systemd. > > What are the reasons to stable 3.8 and not 3.6, a version w/o this > restriction, enabling all non systemd users to profit from this > eye-candy as well. > > I raise the freedom of choice card here. And deliberately choosing an > uncooperative version doesn't shine a good light. > > Facts, pls! > >Michael > > [1] https://bugs.gentoo.org/show_bug.cgi?id=478252 Gnome 3.6 is not maintained by upstream now -> bugs are being fixed in 3.8 and 3.9. Also, stabilizing 3.6 will point Gnome2 users to this two options: - Run gnome-shell - Run 3.6 fallback mode -> 3.6 fallback mode is using old gnome-panel stuff that was dropped in 3.8 because it wasn't really maintained They will also be able to run 3.6 with openrc... but that will be the last version "working" with it, we will hit the same problem again when we want to stabilize 3.8 (well, 3.10 is going to be released in October, I think we have been waiting enough) Also, I think we should stop spending a lot of time trying to keep it working with openrc, we simply don't have resources to do that at the moment (even Debian/Ubuntu people are stick with systemd-204 because they don't have resources to keep logind working without systemd in newer versions). Now, we are needing to put a lot of effort on trying to provide unit files and provide systemd related fixes in the tree because we haven't (in general) pay attention to systemd at all => I think we should put more efforts on it than trying to work on hacks to prevent systemd dependency.
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Wed, Aug 7, 2013 at 9:56 AM, Tom Wijsman wrote: > While people can scream, complaint and rant all they want about choice; > it isn't going to happen if nobody is going to implement it, until that > happens following whatever upstream does is the only reasonable thing > to do. Or if you really want to help, help implement the choice... :) > ++ If somebody wants to do the work to create another choice and others get in their way I'm all for helping to clear the roadblocks (in a reasonable way). However, just standing up and demanding choice isn't going to get anybody anywhere, especially not with me. The Gnome team isn't required to support any particular configuration. Heck, they're not even required to maintain Gnome at all (though obviously if they don't it will get treecleaned). Upstream Gnome has tied their fates to systemd. Patching it to enable other configs is noble, but nothing that anybody should be forced to do. If anybody wants to maintain Gnome sans systemd knock yourself out. Rich
Re: [gentoo-dev] renaming gentoo-oldnet
On Tue, Aug 06, 2013 at 11:26:16AM -0500, William Hubbs wrote: > On Mon, Aug 05, 2013 at 10:09:54PM +, Robin H. Johnson wrote: > > I'm replying the start of this thread, rather than picking a single > > person to respond to. I DO want more brainstorming on ideas for the > > naming of the package, and I think people need to cast a wider net for > > naming ideas. > > Robin, I would like the decision to be made soon. I need to release > OpenRc-0.12 in the next day or so, and if I do not have the answer I > will have to do the split in OpenRc-0.13. > > I thought of a name based on your last suggestion and a comment on the > list. Instead of networkrc, maybe netifrc (network interface rc). > > So, my choices, in no particular order, would be, netifrc, networkrc or, > if neither of those fly, keep gentoo-oldnet. All, Robin hasn't responded, so my choice for this is netifrc (network interface rc). Someone made a comment about "rc" implying "old school", RC means "run control". I'm not sure an implication of "old school" is a big concern. William signature.asc Description: Digital signature
Re: [gentoo-dev] Response to a "friendly note" about changing bug reports
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 08/06/2013 11:46 PM, Jeroen Roovers wrote:
> 23:37:25 rej, you have notes! [21:13] Let me
> rephrase this: Just a friendly notice to please refrain from
> rephrasing bug summaries from "Stabilize ${P}" to "${P} stable
> req". This just adds unneeded noise to the bug. I don't want this
> on bugs I've reported or am assigned to.
>
>
> This is my equally short and "friendly" note: It's not going to
> happen. Forget about it. They are not "your" bug reports and anyone
> is actually /welcome/ to improve them. Get used to it.
>
> To get technical on the "improvement" bit, we have agreed time on
> time that stating the atom and then the action is the way to go.
> The main reasons is that it helps people who need to regularly read
> /lists/ of bug summaries sort them better. Until we get a specific
> [Atoms] field implemented, it will need to stay this way.
>
> Besides the finer technical points of bug maintenance, it simply
> infuriates me that anyone would think of bug reports in the
> possessive. This is not the way to improve the distro. You're on
> the wrong track there. And you weren't being friendly.
>
>
> No kind regards to the sender, jer
>
Hello Jeroen,
first of all I welcome and appreciate the work all members of the
other bug wranglers project[1] and you do.
But please let's tell the whole story from the beginning, so we get a
better picture.
https://bugs.gentoo.org/show_bug.cgi?id=442442
Arches were added before.
Jeroen Roovers 2013-08-06 12:46:43 UTC
Summary: Stabilize net-print/foomatic-db-4.0.20120831,
net-print/foomatic-db-ppds-20120831,
net-print/foomatic-db-engine-4.0.8 →
net-print/foomatic-db-4.0.20120831 net-print/foomatic-db-ppds-20120831
net-print/foomatic-db-engine-4.0.8 stable request
Jeroen Roovers 2013-08-06 12:48:22 UTC
Summary: net-print/foomatic-db-4.0.20120831
net-print/foomatic-db-ppds-20120831 net-print/foomatic-db-engine-4.0.8
stable request → net-print/foomatic-db-4.0.20120831
net-print/foomatic-db-ppds-4.0.20120831
net-print/foomatic-db-engine-4.0.8 stable request
rej: for the future: please don't change the summary field in
my bugs. thank you.
mrueg: I have no idea what you are talking about.
mrueg: I have no idea what you mean by "[your] bugs" so I'll
keep ignoring that.
I wasn't able to respond, because you were offline and I sent you the
note, that you've already quoted, via willikins. That my second note
was a bit harsh, emerged from the fact, that you seemed to be
unwillingly to discuss this ("ignoring").
But before we get to the core, let's check some preliminaries:
a) The bug wranglers project states their goal (I stressed the
important things) as following:
"The goal of the Bug Wranglers project is to clarify how _new_ bugs on
Gentoo's bug tracker should be handled. This document describes the
rules to bug _assignment_, CC'ing herd teams, maintainers, the role of
metadata.xml and herds.xml, who are bug wranglers and how one should
contact them." [1]
b) "Possessing bugs":
I'm aware of the fact that bugs aren't possesed by me (although
there's a bug search link called "My Bugs"), but I don't want to
neglect the fact, that I have certain responsibilites when bugs are
assigned to me or I've reported them. Both require the effort to
provide information to get the bug fixed. Under no circumstances this
effort should be disturbed.
c) "Improvements"
I like the fact that you and all other who have the possibility to
change bug summaries, use their power to add _more_ information to the
bug summary. But I feel the strong need to stress the word "more".
Anything else is just noise and should be avoided.
d) "Agreements"
I think it is a good idea to create a certain format for bug
summaries, when they include default tasks like keywording or
stabilization.
To make the long story short:
I conclude from a), that the responsiblities of the bug wranglers
project end, when the assignee field is set to another one than
bug-wranglers@g.o. If this is wrong or outdated, please change the
goals of the bug-wranglers or create a new project for these goals.
I conclude from a) and b), although you are the lead of the bug
wranglers project, you have _no_ responsibilities regards this bug as
there exists no relationship between you and this bug (Except for your
membership in hppa (which was added to CC), but I'd say it is not main
task of an arch team to adjust bug summaries and I hope you're
d'accord with this one.).
I conclude from d), that there exists some kind of documentation
(gentoo-dev does not count as a documentation) you could have pointed
me at (instead of telling me you ignore my comment), as you might have
noticed that I joined the project recently.
If this doc does not exist, I'd like you to respect my way to work at
b.g.o and the wish, that I don't want to see any future noise (as
described in c) ) on bugs that I'm related to (as assignee or reporter).
Thank you very much for your understanding
Re: [gentoo-dev] Response to a "friendly note" about changing bug reports
On Wed, 07 Aug 2013 19:07:55 +0200 Manuel Rüger wrote: [...] I appreciate the kinder tone. > first of all I welcome and appreciate the work all members of the > other bug wranglers project[1] and you do. This is where you start to slip. I am not just a bug wrangler. - I maintain many hundreds of ebuilds in the portage repository - I do architecture testing, keywording and development (mainly for HPPA). - I regularly file bug reports as and when I find bugs. - I also regularly support users in #gentoo and elsewhere. In all these and other roles, I regularly need to find specific descriptions in the often very long lists of bug reports that bugzilla presents to me. Bug-wrangling is just the tip of the iceberg. > Arches were added before. See above. > a) The bug wranglers project states their goal (I stressed the > important things) as following: Go on. Try again. jer
Re: [gentoo-dev] Response to a "friendly note" about changing bug reports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/07/2013 08:01 PM, Jeroen Roovers wrote: > On Wed, 07 Aug 2013 19:07:55 +0200 Manuel Rüger > wrote: > > [...] > > I appreciate the kinder tone. > >> first of all I welcome and appreciate the work all members of >> the other bug wranglers project[1] and you do. > > This is where you start to slip. I am not just a bug wrangler. > > - I maintain many hundreds of ebuilds in the portage repository - I > do architecture testing, keywording and development (mainly for > HPPA). - I regularly file bug reports as and when I find bugs. - I > also regularly support users in #gentoo and elsewhere. > > In all these and other roles, I regularly need to find specific > descriptions in the often very long lists of bug reports that > bugzilla presents to me. Bug-wrangling is just the tip of the > iceberg. > >> Arches were added before. > > See above. > >> a) The bug wranglers project states their goal (I stressed the >> important things) as following: > > Go on. Try again. > > > jer > Hello Jeroen, nothing of the taks you've listed enables you to proceed as you're doing right now without an existing (i.e. written down) policy. As we both seem to miss a common basis for discussion, I'd like to express my request again and hope for your understanding: Please respect me as an equal member of the project and don't change any fields of bugs, that I've reported or am assigned to and that are not related to you, without asking me first. If you want to standardize things as summary fields, because it annoys you to skip through big lists of bugs: Please use the common way which you and I have get to know during the time as a mentee (see [1], [2]). Thank you so much. With kind regards Manuel [1] https://www.gentoo.org/proj/en/glep/glep-0001.html [2] https://www.gentoo.org/proj/en/glep/glep-0039.html -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJSApK5XxSAAC4AKGlzc3Vlci0uLi5Abm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1 OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcNJIP/RmUk1RFO9SEiO42bmQzumTd Gg+lXk2OQ5x8TYUiFN+TjdLqLajGBNL0C2cibAHkrxHq5VbHNbo02sHZegQ4RF4D 8tQm64jRaTi1Rq1/Itlieh0tXSSr2QYwrj+pCXOSA/EaOEuByWsNwuASYBiQKRcA kHoKZVndGq61yJTRz1oWGevWBtBOAEVNxVOGv67DnOSThqdQk1sBRDqoXV9xrAr0 Kgcv8sfurOVLRmOFsPWPmuwjbAtyD36pWPRQgpkcII0TyhUy0c+hBneNRvDcjNxy 3CfFg00g3FzUiIYLRdaGPogVuIryU6T+FSTwuREot6N5JGUea8w/pESTn7w/2bZC xkwj/8loqZQsT2R02AoBf6MjMKly9IyjpWEyqV14sR87T8B6Ycp3Pc53t1DZe1Rw oEvYr9rAxEhUpZWooZobnR2ldAU2fHzvt3L2+QSu3G5qRhORSg9tydzCWlv3dDj2 RQvyhvS3JH4ZJI5VYP/mMswRoUwNe/cmodEqNhQet4hG5fv8ji89wMfFtz7OYPxj SAIeSV3n2366rd8NCgF6jjRGLi5h7v19ALxxiSnqlwI0Gl0bd0KM8Lpp2DVcyAsx WKYLoErDJlFSYdSTBmgr/N2cA8tkucTrbNwZkAbzwhandGiehgAkuT9x5sdMVv9T dkU2jpopduzzhBljibUC =drR/ -END PGP SIGNATURE-
Re: [gentoo-dev] Response to a "friendly note" about changing bug reports
On Wed, Aug 7, 2013 at 2:32 PM, Manuel Rüger wrote: > nothing of the taks you've listed enables you to proceed as you're > doing right now without an existing (i.e. written down) policy. > I think this is the main concern being voiced here. Jer - can you perhaps consolidate your conventions around bugs into some kind of document and circulate it on -dev/project? Then we can make some kind of decision and: 1. Everybody knows what the policy is so that we can beat up anybody who violates it. 2. Complainers can be sent to the policy and complaints can go to /dev/null (unless they want to propose a change). 3. Everybody else can pitch in and help out so that you're not having to reformat all those bugs on your own. By all means propose whatever makes the most sense to you personally. It will no doubt be bikeshed to death but we don't need 100% consensus to move forward. If necessary the council can bless it, but I suspect that most will see the logic of your arguments, and perhaps together we'll even improve on it a little. Rich
Re: [gentoo-dev] renaming gentoo-oldnet
On Wed, Aug 07, 2013 at 12:00:57PM -0500, William Hubbs wrote: > > So, my choices, in no particular order, would be, netifrc, networkrc or, > > if neither of those fly, keep gentoo-oldnet. > Robin hasn't responded, so my choice for this is netifrc (network > interface rc). Someone made a comment about "rc" implying "old school", > RC means "run control". I'm not sure an implication of "old school" is a > big concern. Long live netifrc! (networkrc is already used) -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Re: [gentoo-dev-announce] OpenRc-0.12 is coming soon
Tom Wijsman wrote: > what if hell breaks loose next time? We fix it. //Peter pgpoxOD8NPi7O.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] OpenRc-0.12 is coming soon
Tom Wijsman wrote: > > Besides, who does an emerge -u world without first checking to see > > what will be updated? > > Some people do They deserve a broken system. //Peter pgp8bIGEpU77h.pgp Description: PGP signature
Re: [gentoo-dev] Response to a "friendly note" about changing bug reports
On Wed, 07 Aug 2013 20:32:25 +0200 Manuel Rüger wrote: > nothing of the taks you've listed enables you to proceed as you're > doing right now without an existing (i.e. written down) policy. I don't know what a taks is, but nothing in this volunteer project stops me from correcting your mistakes, whether trivial or indeed grave (see below). Oh, and now we can't do anything without an existing policy? Good thing you decided to grace this project with your attention, or we wouldn't get anything done, like: Jeroen Roovers 2013-08-06 12:46:43 UTC Summary: Stabilize net-print/foomatic-db-4.0.20120831, net-print/foomatic-db-ppds-20120831, net-print/foomatic-db-engine-4.0.8 → net-print/foomatic-db-4.0.20120831 net-print/foomatic-db-ppds-20120831 net-print/foomatic-db-engine-4.0.8 stable request Jeroen Roovers 2013-08-06 12:48:22 UTC Summary: net-print/foomatic-db-4.0.20120831 net-print/foomatic-db-ppds-20120831 net-print/foomatic-db-engine-4.0.8 stable request → net-print/foomatic-db-4.0.20120831 net-print/foomatic-db-ppds-4.0.20120831 net-print/foomatic-db-engine-4.0.8 stable request Did you notice how I FIXED THE VERSION NUMBER for you? Apparently that isn't what you wanted. You wanted the WRONG VERSION. OK. > As we both seem to miss a common basis for discussion, I'd like to > express my request again and hope for your understanding: > Please respect me as an equal member of the project and don't change > any fields of bugs, that I've reported or am assigned to and that are > not related to you, without asking me first. I already told you, you can absolutely forget about that happening. It's preposterous and dangerous. I would ridicule you for it if you weren't so obviously serious about the whole thing. > If you want to standardize things as summary fields, because it annoys > you to skip through big lists of bugs: Please use the common way which > you and I have get to know during the time as a mentee (see [1], [2]). Why don't you stop assuming for a second? GLEPs were not the subject of my mentorship period, nor of the quizzes. jer
Re: [gentoo-dev] Re: [gentoo-dev-announce] OpenRc-0.12 is coming soon
On Wed, 7 Aug 2013 21:01:06 +0200 Peter Stuge wrote: > Tom Wijsman wrote: > > Some people do, but that's not what this is about. > > They deserve a broken system. Some people do, but that's not what this is about. > Tom Wijsman wrote: > > what if hell breaks loose next time? > > We fix it. Fixes are not a reason to not mask 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Response to a "friendly note" about changing bug reports
On Wed, 7 Aug 2013 14:43:12 -0400 Rich Freeman wrote: > 3. Everybody else can pitch in and help out so that you're not having > to reformat all those bugs on your own. This will increase the noise, we're still going to need to implement some kind of trivial edit flag and list to allow this to be filtered. > By all means propose whatever makes the most sense to you personally. > It will no doubt be bikeshed to death but we don't need 100% consensus > to move forward. The discussion, at least on the bug this thread is about; was already done, so, it doesn't need another discussion and has to be documented. I don't think we care too much about the other trivial edits... > If necessary the council can bless it, but I suspect > that most will see the logic of your arguments, and perhaps together > we'll even improve on it a little. If really really needed, that's the way to go; but I don't think people object, unless mrueg intents to really object the actual change other than stating it is undocumented and noise. He hasn't stated reasoning on why it is objected though, so there's no reason to pursue that yet. If we go that road, we'll have to take it to the council again later if we introduce an atom field in Bugzilla; I see in #gentoo-bugs that kensington has done some preliminary work on that, so we might be seeing this in some near future. -- 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] status of security improvments (GLEPs 57-61)
On Tue, Aug 06, 2013 at 10:32:39AM -0400, Alex Xu wrote: > AFAIK, the status is "unimplemented, and nobody's working on it". No, I did post implementation patches for much of it back when the GLEPs were in process. The overwhelming message from other devs at the time was that it should happen at the same time or shortly after the Git migration, and that in the short-term, if you needed that security, you should be using the signed portage snapshot tarballs. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Response to a "friendly note" about changing bug reports
On Wed, Aug 7, 2013 at 3:44 PM, Tom Wijsman wrote: > On Wed, 7 Aug 2013 14:43:12 -0400 > Rich Freeman wrote: >> If necessary the council can bless it, but I suspect >> that most will see the logic of your arguments, and perhaps together >> we'll even improve on it a little. > > If really really needed, that's the way to go; but I don't think people > object, unless mrueg intents to really object the actual change other > than stating it is undocumented and noise. He hasn't stated reasoning > on why it is objected though, so there's no reason to pursue that yet. The key words being "if necessary." I would hope that this wouldn't require the Council to get involved, but neither is fighting WWIII over something so trivial. Rich
Re: [gentoo-dev] status of security improvments (GLEPs 57-61)
On 08/07/2013 09:55 PM, Robin H. Johnson wrote: > On Tue, Aug 06, 2013 at 10:32:39AM -0400, Alex Xu wrote: >> AFAIK, the status is "unimplemented, and nobody's working on it". > No, I did post implementation patches for much of it back when the GLEPs > were in process. The overwhelming message from other devs at the time > was that it should happen at the same time or shortly after the Git > migration, and that in the short-term, if you needed that security, you > should be using the signed portage snapshot tarballs. > So the git migration IS actually a blocker? Do we really expect it to happen? Should we wait? Why? I'd say let's push for it. I am willing to do a lot of testing.
Re: [gentoo-dev] Response to a "friendly note" about changing bug reports
Guys, please, if you want to bikeshed about bug summary, please do it in a constructive way and get the automated bug assignment project going. http://permalink.gmane.org/gmane.linux.gentoo.devel/66279 Otherwise, please reimburse the time I've spent reading this useless thread, TIA ;) (For the record, I fully support jer's work, my OCD doesn't look so bad we he gets summaries fixed for me beforehand). -- Gilles Dartiguelongue Gentoo
Re: [gentoo-dev] Re: [gentoo-dev-announce] OpenRc-0.12 is coming soon
Dnia 2013-08-07, o godz. 21:02:30 Peter Stuge napisał(a): > Tom Wijsman wrote: > > > Besides, who does an emerge -u world without first checking to see > > > what will be updated? > > > > Some people do > > They deserve a broken system. Please keep your comments to yourself and do not add them to the volume of this list. Thanks. And please don't reply. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] renaming gentoo-oldnet
Dnia 2013-08-07, o godz. 12:00:57 William Hubbs napisał(a): > On Tue, Aug 06, 2013 at 11:26:16AM -0500, William Hubbs wrote: > > On Mon, Aug 05, 2013 at 10:09:54PM +, Robin H. Johnson wrote: > > > I'm replying the start of this thread, rather than picking a single > > > person to respond to. I DO want more brainstorming on ideas for the > > > naming of the package, and I think people need to cast a wider net for > > > naming ideas. > > > > Robin, I would like the decision to be made soon. I need to release > > OpenRc-0.12 in the next day or so, and if I do not have the answer I > > will have to do the split in OpenRc-0.13. > > > > I thought of a name based on your last suggestion and a comment on the > > list. Instead of networkrc, maybe netifrc (network interface rc). > > > > So, my choices, in no particular order, would be, netifrc, networkrc or, > > if neither of those fly, keep gentoo-oldnet. > > Robin hasn't responded, so my choice for this is netifrc (network > interface rc). Someone made a comment about "rc" implying "old school", > RC means "run control". I'm not sure an implication of "old school" is a > big concern. Well, it sounds totally like motif to me but that doesn't really matter :D. Though I'd cut it down to 'netif' unless that's taken. Without the 'rc' is more nicely pronounced. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Vanilla sources stabilization policy change
On Wed, Aug 07, 2013 at 11:37:21AM +0200, Tom Wijsman wrote: > On Wed, 24 Jul 2013 16:09:11 -0700 > Greg KH wrote: > > > Please > > tell me exactly how you are going to evaluate which fixes I make are > > security fixes, and you know which to pick and choose from. > > Some kind of annotation with tags would make this kind of thing easy; > I'm not saying it is your task to apply such annotations to commits, but > it would rather be the task of the person who makes an individual patch. I am not going to impose an additional burden on developers to get their patches into the stable kernel releases like this, sorry. Can you judge which bug fixes are security ones, and which are not? And do so for 100+ patches a week? 52 weeks a year? Great, please do so, as no one has ever been able to do this (others have tried.) Hint, the line between a bugfix and a security fix is not always obvious, or even known at all. And what about all of the fixes I merge in, that _are_ really security fixes, yet we do not want to shout it out to the world at the moment? How would one properly "tag" that? > This would benefit multiple people; it would benefit users to know the > amount of patches that are security and code fixes, new features and > see them separately. It would also benefit distributions and system > admins to filter them out, they could for instance drop new feature > patches so they just get the fixes they need. > > It puts the power in the user's hands; allowing them to evaluate, pick > and choose according to their own demands and needs. > > Implementation wise, I don't think this is any harder than the already > existing annotations; work wise, adding a tag is easy to do. See above for why it is not easy at all, and, why even if we do know some fixes are security ones, we would not tag them as such anyway. So that kind of makes that whole idea fall apart, right? :) sorry, greg k-h
Re: [gentoo-dev] Vanilla sources stabilization policy change
Greg KH wrote: > See above for why it is not easy at all, and, why even if we do know > some fixes are security ones, we would not tag them as such anyway. I think this supports the argument that the better kernel is always the one with the most fixes. Rather than separating "bug fixes" from "security fixes" maybe it's wiser to think about separating "fixes" from "features" - this may be easier, but still not neccessarily easy. //Peter
Re: [gentoo-dev] renaming gentoo-oldnet
On Thu, Aug 08, 2013 at 12:01:14AM +0200, Michał Górny wrote: > Well, it sounds totally like motif to me but that doesn't really > matter :D. Though I'd cut it down to 'netif' unless that's taken. > Without the 'rc' is more nicely pronounced. "netif" is taken unfortunately, it's hard to differentiate in Google between: NETIF - Nepal Environment and Tourism Initiative Foundation netif.h in lwip net/if.h in the core POSIX/XNS specs. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Vanilla sources stabilization policy change
On Thu, Aug 08, 2013 at 12:50:32AM +0200, Peter Stuge wrote: > Greg KH wrote: > > See above for why it is not easy at all, and, why even if we do know > > some fixes are security ones, we would not tag them as such anyway. > > I think this supports the argument that the better kernel is always > the one with the most fixes. That's what us kernel developers have been saying for 10+ years, nice to see it's finally getting some traction :) > Rather than separating "bug fixes" from "security fixes" maybe it's > wiser to think about separating "fixes" from "features" - this may > be easier, but still not neccessarily easy. For stable kernel releases, that type of thing should be quite easy for someone to do, if they want to do it, as the only type of "features" I take for them are new device ids. But I fail to see how marking 5 patches out of 100 as "features" is really doing to do much for anyone, do you? thanks, greg k-h
Re: [gentoo-dev] status of security improvments (GLEPs 57-61)
On Wed, Aug 07, 2013 at 10:47:15PM +0200, hasufell wrote: > On 08/07/2013 09:55 PM, Robin H. Johnson wrote: > > On Tue, Aug 06, 2013 at 10:32:39AM -0400, Alex Xu wrote: > >> AFAIK, the status is "unimplemented, and nobody's working on it". > > No, I did post implementation patches for much of it back when the GLEPs > > were in process. The overwhelming message from other devs at the time > > was that it should happen at the same time or shortly after the Git > > migration, and that in the short-term, if you needed that security, you > > should be using the signed portage snapshot tarballs. > So the git migration IS actually a blocker? > > Do we really expect it to happen? Should we wait? Why? The computational cost to generating the layers of MetaManifest is significantly eased with git. But the best argument was actually taking advantage of thin Manifests. When we move to Git, all the per-package Manifests are going to be thin-Manifest (DIST) entries only. If we KEEP them intact, and put ALL of the other (git-implicit) entries in the MetaManifest, we only need to inject very few files into the rsync tree. > I'd say let's push for it. I am willing to do a lot of testing. The code support shouldn't be held up by the Git migration however. The code for it needs to be done, I doubt my old patches even apply anymore; Portage has changed significantly since I wrote them. You also asked about PMS, and I'm wondering if PMS specifies the Manifest contents at all, and/or if it needs updates for MetaManifest. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On 08/07/2013 09:14 PM, Alexandre Rostovtsev wrote: > On Wed, 2013-08-07 at 14:45 +0200, Michael Weber wrote: >> Greetings, >> >> Gnome Herd decided to target stablilization of 3.8 [1] which requires >> systemd. >> >> What are the reasons to stable 3.8 and not 3.6, a version w/o this >> restriction, enabling all non systemd users to profit from this >> eye-candy as well. >> >> I raise the freedom of choice card here. And deliberately choosing an >> uncooperative version doesn't shine a good light. >> >> Facts, pls! >> >>Michael >> >> [1] https://bugs.gentoo.org/show_bug.cgi?id=478252 > > To stabilize gnome-3.6, we would need > 1. one or (preferably) two *active* gentoo developers; > 2. who are familiar with gnome's internals and are able to backport > bugfixes from 3.8/3.10 without support from upstream developers; and > 3. who volunteer to run openrc+gnome-3.6 for a long time on their main > machines so that they can give a stable 3.6 the support that the word > 'stable' implies. > > We do not have such people on the gnome team. > Seeing the noise in #gentoo from people getting whacked in the kidney by the systemd sidegrade ... that's a very optimistic decision. It'll cause lots of pain for users that suddenly can't start lvm properly and other nasty landmines hidden in the "upgrade path". By stabilizing this early you're causing lots of extra work for others. I hope you understand that some of us will be very rude and just suggest to unmerge gnome on all support requests as it now moves outside our support range ... Have a nice day, Patrick
Re: [gentoo-dev] status of security improvments (GLEPs 57-61)
On 08/08/2013 04:47 AM, hasufell wrote: > On 08/07/2013 09:55 PM, Robin H. Johnson wrote: >> On Tue, Aug 06, 2013 at 10:32:39AM -0400, Alex Xu wrote: >>> AFAIK, the status is "unimplemented, and nobody's working on it". >> No, I did post implementation patches for much of it back when the GLEPs >> were in process. The overwhelming message from other devs at the time >> was that it should happen at the same time or shortly after the Git >> migration, and that in the short-term, if you needed that security, you >> should be using the signed portage snapshot tarballs. >> > > So the git migration IS actually a blocker? No, there's many things that need to be done that are unrelated to the VCS used. It's just chasing a white unicorn that has been just around the next corner for the last err years > > Do we really expect it to happen? Should we wait? Why? Orthogonal problems shouldn't be coupled > > I'd say let's push for it. I am willing to do a lot of testing. > Good plan. I hope I find some time to figure out a roadmap so we have an idea what needs to be done - or someone else might just want to read through some old threads and do the same.
[gentoo-dev] Removing support for Python 2.5, 3.1 and PyPy 1.9
Hello, fellow developers. On behalf of Python team, I would like to announce that we're officially discontinuing support for Python 2.5, Python 3.1 and PyPy 1.9. If you still actively use any of those implementations, please migrate to a newer version. We have ensured already that no in-tree package doesn't support one of the newer implementations. I have just committed a package.mask and use.mask entries for them and unless anybody objects strongly, we will remove them in 30 days from now. After the removal, we will disable the support for them in the eclasses and proceed with semi-automated update of PYTHON_COMPAT. Any questions shall arise, please do not hesitate to reply to gentoo-dev@ or discuss in bug #480070 [1] that is dedicated to the issue. [1]:https://bugs.gentoo.org/show_bug.cgi?id=480070 A short rationale: The Python team is finding it difficult to maintain the old Python implementations. Since we tend to run the newest versions, the old ones don't receive proper testing and we can either rely on the tests (which not all packages have) or simple manual testing that consumes a lot of time. Furthermore, upstreams tend to test their packages with newer versions, and therefore the test failures are much more common with the old versions. Addressing those usually involves much more effort than benefit. Python 2.5 dates back to 2006. It had last security fix mid-2011 as v2.5.6 but the newest in the tree is v2.5.4 which proves that it's unmaintained. The following version -- 2.6 -- has much better support for Python3 compatibility and therefore projects aiming at supporting both Python2 & Python3 are often dropping support for 2.5. This became especially visible when dev-python/pil has been introduced to the tree, as a replacement for dev-python/imaging. Since PIL supports 2.6 up to 3.3 and imaging 2.5 up to 2.7, it became no longer possible to easily have all the listed implementations enabled. That's why most of developers simply disabled 2.5 and it stopped receiving any testing. Python 3.1 dates back to 2009. It's the second Python3 'slot', that has serious improvements over 3.0. However, it's still not as good as 3.2 and therefore most of effort on switching to Python3 focuses on 3.2+. I've been told that this version has some API incompatibilities that make it hard to write portable Py2+3 code that works in 3.1, and that's why a number upstreams doesn't support it. I have no strong proof of that. Additionally, a first alpha of Python 3.4 has been released a few days ago. Considering that, we will be getting a new Python 3 version to maintain soon enough and we should make some space for it. PyPy support is still mostly experimental and buggy. All PyPy versions so far reuse the standard library from Python 2.7, therefore there is no specific reason to keep multiple slots. Moreover, PyPy 2.1 was just released and we'll be adding it soon; and PyPy3 2.1 (Python3 variant) will be released soon. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Removing support for Python 2.5, 3.1 and PyPy 1.9
On Thu, Aug 08, 2013 at 01:56:58AM +0200, Michał Górny wrote: > Hello, fellow developers. > > On behalf of Python team, I would like to announce that we're > officially discontinuing support for Python 2.5, Python 3.1 > and PyPy 1.9. Could you please update: http://www.gentoo.org/proj/en/Python/python-r1/policy-guide.xml I think 3.0 should be added back to there, with a new group for unsupported implementations that have been fully cleaned from the tree. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Vanilla sources stabilization policy change
On Wed, 7 Aug 2013 15:44:34 -0700 Greg KH wrote: > On Wed, Aug 07, 2013 at 11:37:21AM +0200, Tom Wijsman wrote: > > > Some kind of annotation with tags would make this kind of thing > > easy; I'm not saying it is your task to apply such annotations to > > commits, but it would rather be the task of the person who makes an > > individual patch. > > I am not going to impose an additional burden on developers to get > their patches into the stable kernel releases like this, sorry. As I said, it's not your task; so, what you impose doesn't matter. > Can you judge which bug fixes are security ones, and which are not? > And do so for 100+ patches a week? 52 weeks a year? Great, please > do so, as no one has ever been able to do this (others have tried.) Yes, that is easy on the premise that they are annotated. > Hint, the line between a bugfix and a security fix is not always > obvious, or even known at all. The developer knows; and if not, he can probably just mark it as a fix. > And what about all of the fixes I merge in, that _are_ really security > fixes, yet we do not want to shout it out to the world at the moment? For known security bugs, being aware of a fix earlier helps. > How would one properly "tag" that? That's explained below, and would be explained in technical details. > > This would benefit multiple people; it would benefit users to know > > the amount of patches that are security and code fixes, new > > features and see them separately. It would also benefit > > distributions and system admins to filter them out, they could for > > instance drop new feature patches so they just get the fixes they > > need. > > > > It puts the power in the user's hands; allowing them to evaluate, > > pick and choose according to their own demands and needs. > > > > Implementation wise, I don't think this is any harder than the > > already existing annotations; work wise, adding a tag is easy to do. > > See above for why it is not easy at all, and, why even if we do know > some fixes are security ones, we would not tag them as such anyway. Neither seems to be a problem. > So that kind of makes that whole idea fall apart, right? :) The kernel ML will tell whether it does or not. :) -- 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] Vanilla sources stabilization policy change
On Wed, 7 Aug 2013 16:19:43 -0700 Greg KH wrote: > On Thu, Aug 08, 2013 at 12:50:32AM +0200, Peter Stuge wrote: > > Greg KH wrote: > > > See above for why it is not easy at all, and, why even if we do > > > know some fixes are security ones, we would not tag them as such > > > anyway. > > > > I think this supports the argument that the better kernel is always > > the one with the most fixes. Define "better"; because 3.10.0 has also been worse than the last 3.9 release in some ways, despite it having more fixes than the last 3.9. > > Rather than separating "bug fixes" from "security fixes" maybe it's > > wiser to think about separating "fixes" from "features" - this may > > be easier, but still not neccessarily easy. > > For stable kernel releases, that type of thing should be quite easy > for someone to do, if they want to do it, as the only type of > "features" I take for them are new device ids. > > But I fail to see how marking 5 patches out of 100 as "features" is > really doing to do much for anyone, do you? Preferably this would be done for any release, a release like 3.10.0 doesn't have to be an exception; it does contain a lot more features. -- 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] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 8, 2013 at 2:49 AM, Patrick Lauer wrote: > On 08/07/2013 09:14 PM, Alexandre Rostovtsev wrote: > > On Wed, 2013-08-07 at 14:45 +0200, Michael Weber wrote: > >> Greetings, > >> > >> Gnome Herd decided to target stablilization of 3.8 [1] which requires > >> systemd. > >> > >> What are the reasons to stable 3.8 and not 3.6, a version w/o this > >> restriction, enabling all non systemd users to profit from this > >> eye-candy as well. > >> > >> I raise the freedom of choice card here. And deliberately choosing an > >> uncooperative version doesn't shine a good light. > >> > >> Facts, pls! > >> > >>Michael > >> > >> [1] https://bugs.gentoo.org/show_bug.cgi?id=478252 > > > > To stabilize gnome-3.6, we would need > > 1. one or (preferably) two *active* gentoo developers; > > 2. who are familiar with gnome's internals and are able to backport > > bugfixes from 3.8/3.10 without support from upstream developers; and > > 3. who volunteer to run openrc+gnome-3.6 for a long time on their main > > machines so that they can give a stable 3.6 the support that the word > > 'stable' implies. > > > > We do not have such people on the gnome team. > > > > Seeing the noise in #gentoo from people getting whacked in the kidney by > the systemd sidegrade ... that's a very optimistic decision. > > It'll cause lots of pain for users that suddenly can't start lvm > properly and other nasty landmines hidden in the "upgrade path". By > stabilizing this early you're causing lots of extra work for others. > > I hope you understand that some of us will be very rude and just suggest > to unmerge gnome on all support requests as it now moves outside our > support range ... > > Have a nice day, > > Patrick > Although I understand your frustration, I don't see any other options for the Gentoo gnome team. People who don't like this should take their complaints upstream. -- Alex Alexander + wired + www.linuxized.com + www.leetworks.com
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On 08/07/2013 10:16 AM, Pacho Ramos wrote: > Also, I think we should stop spending a lot of time trying to keep it > working with openrc, we simply don't have resources to do that at the > moment (even Debian/Ubuntu people are stick with systemd-204 because > they don't have resources to keep logind working without systemd in > newer versions). Now, we are needing to put a lot of effort on trying to > provide unit files and provide systemd related fixes in the tree because > we haven't (in general) pay attention to systemd at all => I think we > should put more efforts on it than trying to work on hacks to prevent > systemd dependency. I agree that there's no point in hacking software that voluntarily ties itself to systemd to *not* be tied to it, but dependency on any single init system is a bad idea. There are multiple kernels, multiple libc's, multiple device management layers, multiple inits, etc. Preventing dependency on certain things is a good way to enforce software diversity. Granted, in systemd's case Gentoo's not the place to do it. It's the upstreams that should be convinced or told not to depend on a single init system. Forgive me if my interpretation is wrong; it just seemed to me that you were all for vertical integration (systemd dependency as a whole) and the systemd creep is one of the reasons I came to Gentoo. I'd hate to see developers abandoning their work on OpenRC or other Gentoo projects to embrace the Red Hat campaign.
[gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8
Alex Alexander posted on Thu, 08 Aug 2013 05:51:38 +0300 as excerpted: > On Thu, Aug 8, 2013 at 2:49 AM, Patrick Lauer wrote: > >> On 08/07/2013 09:14 PM, Alexandre Rostovtsev wrote: >> > On Wed, 2013-08-07 at 14:45 +0200, Michael Weber wrote: >> >> >> >> Gnome Herd decided to target stablilization of 3.8 [1] which >> >> requires systemd. >> >> >> >> What are the reasons to stable 3.8 and not 3.6, a version w/o this >> >> restriction, enabling all non systemd users to profit from this >> >> eye-candy as well. >> > >> > To stabilize gnome-3.6, we would need [people willing to do it]. >> > We do not have such people on the gnome team. >> > >> Seeing the noise in #gentoo from people getting whacked in the kidney >> by the systemd sidegrade ... that's a very optimistic decision. >> >> It'll cause lots of pain for users that suddenly can't start lvm >> properly and other nasty landmines >> I hope you understand that some of us will be very rude and just >> suggest to unmerge gnome on all support requests as it now moves >> outside our support range ... >> > Although I understand your frustration, I don't see any other options > for the Gentoo gnome team. People who don't like this should take their > complaints upstream. That reads to me like resigned acceptance. Gentoo/gnome is simply working with what upstream gnome gives them, which for gentoo/gnome users now means a choice between gnome with systemd and if no systemd, no gnome either. Upstream decision that gentoo/gnome is dealing with too. ... [Those uninterested in gentoo/kde can stop reading here, as the rest of the post is a complaint about that project not taking the same position.] Gentoo/kde users would be so lucky! As a gentoo/kde-er, I *WISH* the gentoo/kde team was as similarly willing to continue support for the options kde upstream *ARE* still providing -- kde4 with the semantic-desktop options turned off. Yes, this does mean doing without kdepim, but that has been the case for several versions, no upstream change there for 4.11, at least not for kde's base packages as necessary to run a kde desktop, yet gentoo carried support for building kde without semantic-desktop in 4.10, and doesn't in 4.11. Meanwhile, while the same build-time options that worked in 4.10 still work in 4.11 (I know, as I put a lot of work into patching the ebuilds here when gentoo/kde removed the options despite upstream continuing to have them), the gentoo/kde project has decided to force the semantic- desktop option ON for gentooers even where upstream continues to provide the option to turn it off! None-the-less, I do understand the problem of a gentoo project supporting an option no devs on the project are actually interested in running. Testing would be left to users, and quality would suffer a bit as a result, but I know for a fact that there's users out there DOING that testing, even with the additional cost of having to maintain ebuild patches themselves to do it, because I'm one of them! Further, I'm running 4.11.49. live-branch and was running the betas before the branch from trunk, so there's at least one user actually doing that testing early enough to catch a good share of that feature's problems before they get anywhere close to ~arch, let alone stable. Despite, or perhaps /because/ of, all the previous pain kde upstream has caused its users with the 4.x bump (which unlike the 4.10/4.11 bump was at LEAST a major version bump) and with kdepim's switch to akonadi mid-4.x (which unfortunately was NOT a major version bump), this time there's no indication of upstream kde changing semantic-desktop horses mid-stream and mid-major-version and forcing it on like that; it's gentoo/kde that's doing it, pure and simple. And I've already posted that regardless of what upstream kde or gentoo/kde does, after all the trouble I went thru to rid my system of semantic- desktop earlier in the kde4 series, I'm not ABOUT to enable it again now, yes indeed, even if that means I unmerge the kde desktop entirely and switch to something else -- which after all I've already done for major portions of kde, including switching kmail->claws-mail when kdepim unfortunately jumped the shark mid-major-version. So as I said, gentoo/kde-ers would be so lucky, if the gentoo/kde project took the same position gentoo/gnome's taking here, that they support what upstream offers, that gentoo/gnome's only forcing systemd because upstream gnome's forcing it. Were that the case, semantic-desktop wouldn't be forced by gentoo/kde in kde 4.11, where upstream still offers the same options they did in 4.10, where gentoo/kde offered the option as well. Meanwhile, I guess I know what the kde-sunset users felt like now... except in that case as well as the gentoo/gnome case but unlike this one, upstream WAS dropping support, and the gentoo project was simply following upstream... -- Duncan - List replies preferred. No HTML msgs. "Every non
Re: [gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8
On 08/08/2013 01:21 AM, Duncan wrote: > Alex Alexander posted on Thu, 08 Aug 2013 05:51:38 +0300 as excerpted: > >> On Thu, Aug 8, 2013 at 2:49 AM, Patrick Lauer wrote: >> >>> On 08/07/2013 09:14 PM, Alexandre Rostovtsev wrote: On Wed, 2013-08-07 at 14:45 +0200, Michael Weber wrote: > > Gnome Herd decided to target stablilization of 3.8 [1] which > requires systemd. > > What are the reasons to stable 3.8 and not 3.6, a version w/o this > restriction, enabling all non systemd users to profit from this > eye-candy as well. To stabilize gnome-3.6, we would need [people willing to do it]. We do not have such people on the gnome team. >>> Seeing the noise in #gentoo from people getting whacked in the kidney >>> by the systemd sidegrade ... that's a very optimistic decision. >>> >>> It'll cause lots of pain for users that suddenly can't start lvm >>> properly and other nasty landmines > >>> I hope you understand that some of us will be very rude and just >>> suggest to unmerge gnome on all support requests as it now moves >>> outside our support range ... >>> >> Although I understand your frustration, I don't see any other options >> for the Gentoo gnome team. People who don't like this should take their >> complaints upstream. > > That reads to me like resigned acceptance. > > Gentoo/gnome is simply working with what upstream gnome gives them, which > for gentoo/gnome users now means a choice between gnome with systemd and > if no systemd, no gnome either. Upstream decision that gentoo/gnome is > dealing with too. > > ... > > [Those uninterested in gentoo/kde can stop reading here, as the rest of > the post is a complaint about that project not taking the same position.] > > Gentoo/kde users would be so lucky! > > As a gentoo/kde-er, I *WISH* the gentoo/kde team was as similarly willing > to continue support for the options kde upstream *ARE* still providing -- > kde4 with the semantic-desktop options turned off. Yes, this does mean > doing without kdepim, but that has been the case for several versions, no > upstream change there for 4.11, at least not for kde's base packages as > necessary to run a kde desktop, yet gentoo carried support for building > kde without semantic-desktop in 4.10, and doesn't in 4.11. > > Meanwhile, while the same build-time options that worked in 4.10 still > work in 4.11 (I know, as I put a lot of work into patching the ebuilds > here when gentoo/kde removed the options despite upstream continuing to > have them), the gentoo/kde project has decided to force the semantic- > desktop option ON for gentooers even where upstream continues to provide > the option to turn it off! > > > None-the-less, I do understand the problem of a gentoo project supporting > an option no devs on the project are actually interested in running. > Testing would be left to users, and quality would suffer a bit as a > result, but I know for a fact that there's users out there DOING that > testing, even with the additional cost of having to maintain ebuild > patches themselves to do it, because I'm one of them! Further, I'm > running 4.11.49. live-branch and was running the betas before the > branch from trunk, so there's at least one user actually doing that > testing early enough to catch a good share of that feature's problems > before they get anywhere close to ~arch, let alone stable. > > Despite, or perhaps /because/ of, all the previous pain kde upstream has > caused its users with the 4.x bump (which unlike the 4.10/4.11 bump was > at LEAST a major version bump) and with kdepim's switch to akonadi > mid-4.x (which unfortunately was NOT a major version bump), this time > there's no indication of upstream kde changing semantic-desktop horses > mid-stream and mid-major-version and forcing it on like that; it's > gentoo/kde that's doing it, pure and simple. > > And I've already posted that regardless of what upstream kde or gentoo/kde > does, after all the trouble I went thru to rid my system of semantic- > desktop earlier in the kde4 series, I'm not ABOUT to enable it again now, > yes indeed, even if that means I unmerge the kde desktop entirely and > switch to something else -- which after all I've already done for major > portions of kde, including switching kmail->claws-mail when kdepim > unfortunately jumped the shark mid-major-version. > > > So as I said, gentoo/kde-ers would be so lucky, if the gentoo/kde project > took the same position gentoo/gnome's taking here, that they support what > upstream offers, that gentoo/gnome's only forcing systemd because > upstream gnome's forcing it. Were that the case, semantic-desktop > wouldn't be forced by gentoo/kde in kde 4.11, where upstream still offers > the same options they did in 4.10, where gentoo/kde offered the option as > well. > > Meanwhile, I guess I know what the kde-sunset users felt like now... > except in that case as well as
[gentoo-dev] Re: Response to a "friendly note" about changing bug reports
On 8/08/2013 07:52, Gilles Dartiguelongue wrote: Guys, please, if you want to bikeshed about bug summary, please do it in a constructive way and get the automated bug assignment project going. I think at least one bug wrangler already uses a local script to do something similar to that. Any idea what is blocking it being implemented in Bugzilla? Infra being understaffed?
Re: [gentoo-dev] status of security improvments (GLEPs 57-61)
> On Wed, 7 Aug 2013, Robin H Johnson wrote: > You also asked about PMS, and I'm wondering if PMS specifies the > Manifest contents at all, and/or if it needs updates for > MetaManifest. PMS doesn't specify the Manifest format, but refers to GLEP 44, so probably this reference should be updated. Also, Manifest files are only mentioned in connection with package directories. Ulrich
