Re: [gentoo-dev] Virtual default changes for old users, was: Heads up: libjpeg-turbo stabilization, becoming the default
On 06/01/2011 10:15 PM, Christopher Head wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Sun, 27 Mar 2011 11:33:03 +0300 > Samuli Suominen wrote: > >> libjpeg-turbo stabilization is happening for amd64/x86 at >> http://bugs.gentoo.org/360715 >> >> - the gentoo-x86 has been converted to virtual/jpeg to support this. >> - we have no bugs reported against the package. >> - libjpeg-turbo is default in virtual/jpeg >> >> so just heads up. >> > > Hi everyone, > > Just a user, not a developer, but: > > The third point of this message made me wonder about something. New > installs will get libjpeg-turbo, as it's the default. Old users may > never know it exists! It seems that making lbjpeg-turbo the default > implementation of virtual/jpeg is expressing some small preference in > favour of it, but old users will never be presented with the choice to > switch. It seems like this is a bit of a gap in package management, > that even if a "better" package becomes available and becomes the > default implementation of a virtual, existing users will keep using the > "worse" package for no other reason than that it's already installed > (and there's no message anywhere even telling them that the change > happened). > > Does anyone think this is suboptimal and that it might be nice to > investigate alternatives? A couple of alternatives come to mind: A) Create a news item to notify people who have media-libs/jpeg installed that there is an alternative. B) Put media-libs/jpeg in package.mask, so that migration happens automatically. -- Thanks, Zac
Re: [gentoo-dev] Re: RFC: better policy for ChageLogs
В Срд, 01/06/2011 в 19:37 -0400, Matt Turner пишет: > On Wed, Jun 1, 2011 at 7:29 PM, Jorge Manuel B. S. Vicetto > wrote: > > To be clear I support the goal to move our tree to git. > > However, I'd like to point out that simply moving to git will leave us > > in the same state. ++ ChangeLog files are text to be distributed to our users so they are completely independent of vcs we use. > > Assuming everyone agrees that git is far more useful > > than cvs to check for changes in the tree, a simple but important issue > > remains: the plan is to move the "development tree" to git, but to keep > > the rsync mirrors for users. So the "move to git" doesn't fix the issue > > for users or developers using an rsync tree. > > Temporarily or permanently? > > One of the huge benefits in using git would be really fast emerge > --syncs. Not having some kind of system for migrating users to git > seems like a lot of the benefits are lost. Is git faster then rsync? I've never done any checks but it'll be surprising if it will. Another useful feature of rsync is --exclude that allows some categories to be excluded (for size and speed efficiency), e.g. my servers don't need kde-* and games-*. Also taking into account that we use portage tree on embedded devices where again both size and speed really matters it looks like the answer on your question is "permanently". -- Peter.
[gentoo-dev] Virtual default changes for old users, was: Heads up: libjpeg-turbo stabilization, becoming the default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 27 Mar 2011 11:33:03 +0300 Samuli Suominen wrote: > libjpeg-turbo stabilization is happening for amd64/x86 at > http://bugs.gentoo.org/360715 > > - the gentoo-x86 has been converted to virtual/jpeg to support this. > - we have no bugs reported against the package. > - libjpeg-turbo is default in virtual/jpeg > > so just heads up. > Hi everyone, Just a user, not a developer, but: The third point of this message made me wonder about something. New installs will get libjpeg-turbo, as it's the default. Old users may never know it exists! It seems that making lbjpeg-turbo the default implementation of virtual/jpeg is expressing some small preference in favour of it, but old users will never be presented with the choice to switch. It seems like this is a bit of a gap in package management, that even if a "better" package becomes available and becomes the default implementation of a virtual, existing users will keep using the "worse" package for no other reason than that it's already installed (and there's no message anywhere even telling them that the change happened). Does anyone think this is suboptimal and that it might be nice to investigate alternatives? Chris -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk3nHIkACgkQXUF6hOTGP7ftqwCgho+EhlOnvy1swE7nOE21TcMq wiIAn1Vr9fRZmvRIvyO5vsILWT9XzSxi =GIqk -END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: better policy for ChageLogs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01-06-2011 22:59, Rich Freeman wrote: > I think the problem is that we're getting a bit legalistic here. I > have no idea why we even needed the policy change. IMHO what should > happen is: > > 1. Dev does something significant and doesn't update a Changelog. > 2. QA or another dev calls them on it. Tells them not to do it again. > 3. Dev does it again. > 4. QA or another dev escalates to devrel. Devrel deals with the > issue, resulting in either a dev who takes the rules more seriously or > one less dev. > > What it almost sounds like to me is that step 4 is breaking down. > Perhaps somebody is arguing "well, it isn't clear in the rules so you > can't do anything to me." To that my only answer is "sure we can!" Rich, besides a disagreement on how to deal with policy issues (as you can read in my proposal to update GLEP48), the issue here is *exactly* that whenever developers or QA warned *repeatedly* the people that don't update ChangeLogs (a very restrict minority of developers), they've always tried to find loopholes in the policy and argued others had no support for their request. About step 4 breaking down, the DevRel process would face the same hurdle as the above, but then there's another important point that people really need to think about: Do we really want to take all technical issues to DevRel and in the limit fire people "only" for that? I'm not saying that technical issues aren't relevant for DevRel or that people can't get "fired" because of them, but in my experience the role of DevRel is more to evaluate the ability and willingness of developers to work in the team than to fire someone because they failed to apply a policy here or there - to be clear, I'm talking here about mistakes and ignorance, not about defiance and disregard for others and policy - which in my view constitute the sort of behaviour patterns that DevRel is meant to evaluate, help fixing and, when everything else fails, to remove. > When it comes to money and taxes we need to have pretty clear rules > for legal reasons, but when it comes down to expecting devs to be > mature and team players, I don't think that we really need 14 appeals > and a team of lawyers to eliminate every loophole in our policies. If > a misunderstanding is genuine then everybody should get past it > quickly and maybe we update the policy to be more clear. When > policies are flaunted despite explanation, and the authority of devrel > or QA or whatever and ultimately the council (on appeal) is > questioned, then we're not playing like a team. It is amazing what > intelligent people can fail to understand when getting something they > want depends on it. The sad fact is that increasingly it seems our developer base, or a significant part of it, is losing all "common sense". > Just my two cents... That, and in the big scheme of things this is a > bit of a tempest in a teapot but I do share concerns that QA is an > attitude and small problems today just lead to big ones tomorrow. > > Rich - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN5s33AAoJEC8ZTXQF1qEPFEcP/2tLhDBXR24AF/GunN5BHKQy +fganpXgO1OqZcFX6tEG7h+j6fjbSFwTPaNG9CiSyrz/NsYseuL7wzkxXZawfUax ftiaFuOuKvLd56AizO0y0YNfrvIVxp2rTPas17yg+Noqgm3Hd5voh2J9FkN3x8X9 PPd8yA8f4DXA4ptdihGS694edtDtT2WwMVGbPuGl6I3U0tlLYlPyGoQDRaAhvQoB LnOzqrYxFxDxcEUWyae25dp3DI1rhqWw8cUc1We6lOZENOtGxiLuxToIorVB8lAs b3SB326WI5XJRyHWgWtcPkF9OrQvpsDXgO9YEqBbsXn3w6vsj2rD8IeswMGNt66R h4cmHEwXEyZ9iQPEPwJKi/UI6MZHTM5ezYJDAbBxBuLt5dPuR7RQBspHkyjSSFe8 /RPLDYy0UYnh0uUw1Rq7DCB5rhLf9acnGhT247q+5PNMcfdN3aBYPIK2ruqTQGKD SfNefj0tKJCXd/TsQUSn7GP7SLjiBNh7Ym+qy8Q5TFQs49vhYprbqRn6RdsMpPe6 eeHNiNzSw9Cfi6n/ZidHlvOXUM7g2yVOLzJ9ChzZRhftxABMWMJCzYvQfjE6Eqey +pVX372nI2G9e9UErS8/Zfxxxw/+vOE7DLLYKe9HSXeM3XdNwEzotdcN+Xxth3f/ R5tVPjMUL3TACOcqA/zr =vsto -END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: better policy for ChageLogs
On Wed, Jun 1, 2011 at 7:29 PM, Jorge Manuel B. S. Vicetto wrote: > To be clear I support the goal to move our tree to git. > However, I'd like to point out that simply moving to git will leave us > in the same state. Assuming everyone agrees that git is far more useful > than cvs to check for changes in the tree, a simple but important issue > remains: the plan is to move the "development tree" to git, but to keep > the rsync mirrors for users. So the "move to git" doesn't fix the issue > for users or developers using an rsync tree. Temporarily or permanently? One of the huge benefits in using git would be really fast emerge --syncs. Not having some kind of system for migrating users to git seems like a lot of the benefits are lost. Matt
Re: [gentoo-dev] Re: RFC: better policy for ChageLogs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01-06-2011 19:50, Nirbheek Chauhan wrote: > On Wed, Jun 1, 2011 at 9:54 PM, Andreas K. Huettel > wrote: >> >>> So we come back to the problem being *CVS* not ChangeLog rules. >> >> Well of course we can just tell everyone "go look it up on >> sources.gentoo.org". >> However, this is a different discussion. >> > sources.gentoo.org is a much worse (and slower) solution than cvs log. > The main advantage of a ChangeLog (and of git) is that it allows you > to check the history locally, without needing access to the network. > >>> All this is such a massive waste of time. Can't we just expend this >>> energy on the move to git? >> > [snip] >> We're not talking about future plans here but about the current situation. >> And about how to deal with it. >> > > The current situation is: > > (a) Not dire. > (b) Not urgent. (c) has irked enough developers and users that people pushed council to update the policy about the use of ChangeLogs. > And if we decide, hey, let's move to git instead of having this > discussion, the current situation is also: > > (c) A waste of everyone's time. > > So no, future plans are not independent of the current situation, and > a move to git *is* a way to deal with the current situation. > > In effect, we kill (at least) two birds with one stone and prevent a > lot of argument and bad blood. To be clear I support the goal to move our tree to git. However, I'd like to point out that simply moving to git will leave us in the same state. Assuming everyone agrees that git is far more useful than cvs to check for changes in the tree, a simple but important issue remains: the plan is to move the "development tree" to git, but to keep the rsync mirrors for users. So the "move to git" doesn't fix the issue for users or developers using an rsync tree. One solution that has been proposed before and that was raised again in this thread is to generate ChangeLogs directly from scm commit messages. That is already a solution with cvs, so moving to git won't help here. The same objections that have been raised about doing it for cvs, not being able to use different messages for the commit message and in ChangeLog (something I understand but admit have hardly used before), are also valid if we move to git. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN5stWAAoJEC8ZTXQF1qEPIPMQAJOBJxGkWJZ3saNdQvAjbR7l KQdLHbO3IdUTBixqSqnmBXop4d6XFBd6lZyjiLu29x9xBn68wE4gm7rlpulITs6R Yqh4ASyLkUF88qezmqdkBaIy/TUGpGS7ZQWMu7ViarhPtLpcyrVWIh8U0T7oJZBh offLYHiQK9dDajLro83aIGLfRlLEYTB9MhjHegv8sDTUCr+ti23OuKjO0CoI7LFx yYdnzkA1YQWA1MGj6iEAVHzcy+RsaGK1QfVn26qAyly3Mg4mPkbKjtIHUEleIV0X TiWPQfNOvPbbNNyuaJ2cBZoGSTLtTstwUKMccYspQawCpDz0h2yNxNLtVS5ws5AO HBvfuWROKtWQ90hSiHb5dy13KXhRYR0CZzGPPLMs316YzdsFtKRL5AG3ywzLT2Bu Dj/wiUoRIRhoPuBTRskCxmXBd04nE/MtDZM/MRn0OZE9zHeYvZYIqCtWVXaGejtZ uID3LxOdGvJn07+TeH7/i8ap4zchRvwZaW6H9LBFr5bIHzKEFPUAfL3NqquGj66d HOHsh/RdPG25gKAZy5/zJ92lsRbFyZlxZFNYoTBTSFg89z7YldPMMxPPpNMWro+n ZzhyourKYprtt2+ZI05gPB/f24KMBhZY8kALoORSeNpUxBwTQ/aanpbKKqjFcfuv j0asDqRgkHAvpF3aTmaI =cSzK -END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: better policy for ChageLogs
Rich Freeman wrote: I think that we need a simple policy like: Write up Changelogs for any change that impacts what gets installed on our user's computers. Then we can write up some guidelines about how to apply this policy in practice. I think the problem is that we're getting a bit legalistic here. I have no idea why we even needed the policy change. IMHO what should happen is: 1. Dev does something significant and doesn't update a Changelog. 2. QA or another dev calls them on it. Tells them not to do it again. 3. Dev does it again. 4. QA or another dev escalates to devrel. Devrel deals with the issue, resulting in either a dev who takes the rules more seriously or one less dev. What it almost sounds like to me is that step 4 is breaking down. Perhaps somebody is arguing "well, it isn't clear in the rules so you can't do anything to me." To that my only answer is "sure we can!" When it comes to money and taxes we need to have pretty clear rules for legal reasons, but when it comes down to expecting devs to be mature and team players, I don't think that we really need 14 appeals and a team of lawyers to eliminate every loophole in our policies. If a misunderstanding is genuine then everybody should get past it quickly and maybe we update the policy to be more clear. When policies are flaunted despite explanation, and the authority of devrel or QA or whatever and ultimately the council (on appeal) is questioned, then we're not playing like a team. It is amazing what intelligent people can fail to understand when getting something they want depends on it. More rules will never save an organization. Sometimes you need rules, but I think that for a group like Gentoo to work well we need to keep them to a minimum. "Well, that's not written in black and white so I won't cooperate until it is" is no reason for anybody to pause even a moment before escalating. Unclear policies are a reason to assume good intentions - not a reason to overlook obvious bad intentions. You can't solve a people problem with a better algorithm. Just my two cents... That, and in the big scheme of things this is a bit of a tempest in a teapot but I do share concerns that QA is an attitude and small problems today just lead to big ones tomorrow. Rich I'm not a dev, just a user but I do follow this list and read most things posted here. The point of the discussion is this. Someone didn't log something that should have been logged. Even after it was posted that the change is supposed to be logged, the person that didn't think he should log it said the rules didn't say he had to log it. So, it appears that #1, #2 happened but the rules wasn't clear enough so it was changed. I think the point of the discussion is this. The rules wasn't clear enough so they were changed to be much clearer. From my understanding, the NEW rules say if you touch it, log it. Thing is, that seemed to have went to far. So, round two is to smooth out the edges and get it back to what it was except in writing this time. That way, if this happens again, another dev, user, devrel or whatever can point to the rules and settle the argument quickly. It would be nice if when this originally started, the reply would have been "sorry, I didn't realize. It won't happen again". That could have been the end of it and it would have ended loong ago. :-) I do agree with your post tho. Sometimes you etch something in stone then realize you misspelled the thing. Dale :-) :-)
[gentoo-dev] Re: Re: RFC: better policy for ChageLogs
Il giorno mer, 01/06/2011 alle 18.59 -0400, Rich Freeman ha scritto: > Write up Changelogs for any change that impacts what gets installed on > our user's computers. > This is not really a good approach; Peter's approach is more reliable on this. Let me explain: an EAPI bump _should not_ impact what gets installed. On the other hand, I'd argue it _should_ be in the ChangeLog: a) it is a functional change: it changes _a lot_ the way the package manager sees the ebuild — even though one argues that if the package manager is perfectly compliant the result wouldn't change, it might very well expose a bug in the package manager; b) we can't assume nobody makes mistakes: "it's such a minimal change I cannot have made a mistake" is no way to argue a policy; mistakes are possible by anyone, and any change that is not strictly trivial (whitespace, comments) should be treated as a possible entrypoint for a mistake. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: RFC: better policy for ChageLogs
On Wed, Jun 1, 2011 at 12:44 PM, Duncan <1i5t5.dun...@cox.net> wrote: > The current "every change" policy goes overboard, I doubt anyone > disagrees, but it's worth repeating the point someone else made already, > every added exception makes the rule harder to remember. The four > numbered exceptions (plus my proposed exception to the exception) above > are IMO a reasonable compromise between practicality and simplicity, but > getting much more complicated than that and... IMO it's better to stay > simple. I think that we need a simple policy like: Write up Changelogs for any change that impacts what gets installed on our user's computers. Then we can write up some guidelines about how to apply this policy in practice. I think the problem is that we're getting a bit legalistic here. I have no idea why we even needed the policy change. IMHO what should happen is: 1. Dev does something significant and doesn't update a Changelog. 2. QA or another dev calls them on it. Tells them not to do it again. 3. Dev does it again. 4. QA or another dev escalates to devrel. Devrel deals with the issue, resulting in either a dev who takes the rules more seriously or one less dev. What it almost sounds like to me is that step 4 is breaking down. Perhaps somebody is arguing "well, it isn't clear in the rules so you can't do anything to me." To that my only answer is "sure we can!" When it comes to money and taxes we need to have pretty clear rules for legal reasons, but when it comes down to expecting devs to be mature and team players, I don't think that we really need 14 appeals and a team of lawyers to eliminate every loophole in our policies. If a misunderstanding is genuine then everybody should get past it quickly and maybe we update the policy to be more clear. When policies are flaunted despite explanation, and the authority of devrel or QA or whatever and ultimately the council (on appeal) is questioned, then we're not playing like a team. It is amazing what intelligent people can fail to understand when getting something they want depends on it. More rules will never save an organization. Sometimes you need rules, but I think that for a group like Gentoo to work well we need to keep them to a minimum. "Well, that's not written in black and white so I won't cooperate until it is" is no reason for anybody to pause even a moment before escalating. Unclear policies are a reason to assume good intentions - not a reason to overlook obvious bad intentions. You can't solve a people problem with a better algorithm. Just my two cents... That, and in the big scheme of things this is a bit of a tempest in a teapot but I do share concerns that QA is an attitude and small problems today just lead to big ones tomorrow. Rich
Re: [gentoo-dev] Re: RFC: better policy for ChageLogs
On Wed, Jun 1, 2011 at 9:54 PM, Andreas K. Huettel wrote: > >> So we come back to the problem being *CVS* not ChangeLog rules. > > Well of course we can just tell everyone "go look it up on > sources.gentoo.org". > However, this is a different discussion. > sources.gentoo.org is a much worse (and slower) solution than cvs log. The main advantage of a ChangeLog (and of git) is that it allows you to check the history locally, without needing access to the network. >> All this is such a massive waste of time. Can't we just expend this >> energy on the move to git? > [snip] > We're not talking about future plans here but about the current situation. > And about how to deal with it. > The current situation is: (a) Not dire. (b) Not urgent. And if we decide, hey, let's move to git instead of having this discussion, the current situation is also: (c) A waste of everyone's time. So no, future plans are not independent of the current situation, and a move to git *is* a way to deal with the current situation. In effect, we kill (at least) two birds with one stone and prevent a lot of argument and bad blood. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] Re: RFC: better policy for ChageLogs
Nathan Phillip Brink posted on Wed, 01 Jun 2011 11:30:21 -0400 as
excerpted:
> On Wed, Jun 01, 2011 at 04:15:31PM +0100, Markos Chandras wrote:
>> On 01/06/2011 04:08 , Peter Volkov wrote:
>> > ?? ??, 30/05/2011 ?? 14:55 -0700, Brian Harring ??:
>> >> The problem is, that's a *fuzzy* definition.
>> >
>> > Ok, let's start with something and then we'll add more items if
>> > required. Currently I'd like to propose following text:
>> >
>> > The ChangeLog must be updated with each commit. The only possible
>> > relaxations for this rule are:
>> >
>> > 1. Nonfunctional whitespace changes
>> > 2. Changes in comments (lines starting with # in ebuild,
>> > or leading text in patches)
>> > 3. Manifest updates
>> > 4. Changes in ChageLog itself ;)
>> >
>> > Something unclear? Anything else?
>
> I think these are reasonable.
Agreed with one exception:
Under #2, changes in comment lines, please be specific that commenting a
previously uncommented line is NOT a simple comment change and thus not a
valid reason to apply this exception. Otherwise we'll (unfortunately)
likely be having round #3 of the debate over someone arguing that
commenting an epatch line is simply changing a comment...
Perhaps (tho better wording is likely possible):
2. Changes in comments (lines starting with # in ebuild,
or leading text in patches, except that...)
2a. Commenting an existing line is considered more than
a comment change and thus must be changelogged.
>> Maybe typos in e{log,warn,info} messages and/or typos in general
>> ( variables, functions etc )
>
> But typos in variables and functions (which in most cases _imply_
> functional changes) are generally bugs which should be mentioned in the
> ChangeLog. Typos in informational messages (e{log,warn,info}) might also
> affect the user and thus be `functional' indirectly. I think that the
> 4-item list is complete enough ;-).
Exactly. Plus...
The current "every change" policy goes overboard, I doubt anyone
disagrees, but it's worth repeating the point someone else made already,
every added exception makes the rule harder to remember. The four
numbered exceptions (plus my proposed exception to the exception) above
are IMO a reasonable compromise between practicality and simplicity, but
getting much more complicated than that and... IMO it's better to stay
simple.
And in practice I believe it's impossible to define typos to the level it
unfortunately appears is now necessary, without either leaving holes big
enough to fly a jumbo-jet thru which no doubt someone will then attempt,
or complicating the rule beyond the point of simple effectiveness.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: RFC: better policy for ChageLogs
> So we come back to the problem being *CVS* not ChangeLog rules. Well of course we can just tell everyone "go look it up on sources.gentoo.org". However, this is a different discussion. > All this is such a massive waste of time. Can't we just expend this > energy on the move to git? Ack, this is an idea that I can very much support. But please please then have the changelog autogenerated from the git commit log, as otherwise the entire discussion will just continue. (/me is waiting for the next flamewar.) And again, this is also a different discussion. We're not talking about future plans here but about the current situation. And about how to deal with it. End of message from the department of redundancy department. -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] Re: RFC: better policy for ChageLogs
On Wed, Jun 1, 2011 at 9:09 PM, Andreas K. Huettel wrote: > Am Mittwoch 01 Juni 2011, 17:27:04 schrieb Samuli Suominen: > >> Wouldn't it be better to just trust devs to use common sense in what >> gets into ChangeLogs, and actually be grateful about if they take the >> time to sensor the crap out from it, and scrap the whole topic? > > The problem is, not everyone has the same notion of common sense. I hate > fumbling around with cvs, and see it as an absolutely great convenience if > the changelog clearly indicates when exactly an ebuild has been removed... > So we come back to the problem being *CVS* not ChangeLog rules. All this is such a massive waste of time. Can't we just expend this energy on the move to git? -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: RFC: better policy for ChageLogs
Am Mittwoch 01 Juni 2011, 17:27:04 schrieb Samuli Suominen: > Wouldn't it be better to just trust devs to use common sense in what > gets into ChangeLogs, and actually be grateful about if they take the > time to sensor the crap out from it, and scrap the whole topic? The problem is, not everyone has the same notion of common sense. I hate fumbling around with cvs, and see it as an absolutely great convenience if the changelog clearly indicates when exactly an ebuild has been removed... -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] Re: RFC: better policy for ChageLogs
On Wed, 01 Jun 2011 18:27:04 +0300 Samuli Suominen wrote: > Wouldn't it be better to just trust devs to use common sense in what > gets into ChangeLogs, and actually be grateful about if they take the > time to sensor the crap out from it, and scrap the whole topic? This whole thing came about because a select few developers repeatedly refused to use common sense, even after having been told to do so on numerous occasions. Unfortunately, common sense for some developers is running round the room whilst waving their wangs at everyone. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: better policy for ChageLogs
On Wed, Jun 01, 2011 at 04:15:31PM +0100, Markos Chandras wrote:
> On 01/06/2011 04:08 , Peter Volkov wrote:
> > ?? ??, 30/05/2011 ?? 14:55 -0700, Brian Harring ??:
> >> The problem is, that's a *fuzzy* definition.
> >
> > Ok, let's start with something and then we'll add more items if
> > required. Currently I'd like to propose following text:
> >
> > The ChangeLog must be updated with each commit. The only possible
> > relaxations for this rule are:
> >
> > 1. Nonfunctional whitespace changes
> > 2. Changes in comments (lines starting with # in ebuild, or leading text
> > in patches)
> > 3. Manifest updates
> > 4. Changes in ChageLog itself ;)
> >
> > Something unclear? Anything else?
I think these are reasonable.
> > --
> > Peter.
> Maybe typos in e{log,warn,info} messages and/or typos in general (
> variables, functions etc )
But typos in variables and functions (which in most cases _imply_
functional changes) are generally bugs which should be mentioned in
the ChangeLog. Typos in informational messages (e{log,warn,info})
might also affect the user and thus be `functional' indirectly. I
think that the 4-item list is complete enough ;-).
--
binki
Look out for missing or extraneous apostrophes!
pgpFCdFauEa5F.pgp
Description: PGP signature
Re: [gentoo-dev] Re: RFC: better policy for ChageLogs
On 06/01/2011 06:15 PM, Markos Chandras wrote:
> On 01/06/2011 04:08 ¼¼, Peter Volkov wrote:
>> =4, 30/05/2011 2 14:55 -0700, Brian Harring ?8H5B:
>>> The problem is, that's a *fuzzy* definition.
>
>> Ok, let's start with something and then we'll add more items if
>> required. Currently I'd like to propose following text:
>
>> The ChangeLog must be updated with each commit. The only possible
>> relaxations for this rule are:
>
>> 1. Nonfunctional whitespace changes
>> 2. Changes in comments (lines starting with # in ebuild, or leading text
>> in patches)
>> 3. Manifest updates
>> 4. Changes in ChageLog itself ;)
>
>> Something unclear? Anything else?
>
>> --
>> Peter.
> Maybe typos in e{log,warn,info} messages and/or typos in general (
> variables, functions etc )
>
And the list will grow...
If we don't want to start monitoring also the context of ChangeLog entries,
Like if someone adds a epatch line to fix a real bug in a ebuild but
while at it fixes ebuild Coding Style for repoman/pcheck/and so forth,
fails to mention it in the log.
How is that different from committing just the Coding Style fix and then
leaving it out of ChangeLog?
Wouldn't it be better to just trust devs to use common sense in what
gets into ChangeLogs, and actually be grateful about if they take the
time to sensor the crap out from it, and scrap the whole topic?
(I honestly can't remember being involved in anything this useless...)
- Samuli
[gentoo-dev] Re: RFC: better policy for ChageLogs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/06/2011 04:08 μμ, Peter Volkov wrote:
> В Пнд, 30/05/2011 в 14:55 -0700, Brian Harring пишет:
>> The problem is, that's a *fuzzy* definition.
>
> Ok, let's start with something and then we'll add more items if
> required. Currently I'd like to propose following text:
>
> The ChangeLog must be updated with each commit. The only possible
> relaxations for this rule are:
>
> 1. Nonfunctional whitespace changes
> 2. Changes in comments (lines starting with # in ebuild, or leading text
> in patches)
> 3. Manifest updates
> 4. Changes in ChageLog itself ;)
>
> Something unclear? Anything else?
>
> --
> Peter.
Maybe typos in e{log,warn,info} messages and/or typos in general (
variables, functions etc )
- --
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
iQIcBAEBCgAGBQJN5leTAAoJEPqDWhW0r/LCztAP/2GIXm1yllZX1r1IBErUoLGG
aO+8RGSgFrdT5SskyqA5Gbah+5XMzCyVEidebxst5JNSbpnKlRFPAvSJQUgHnJiD
+mQXizqqjJpbDBs0ktXFQIepXpUZ3vKUKAw8BG2fJ2thblBFA+A8V02cTF4mE5iV
HwiR2+0LGFVfR3HB2Q1Udbz24GIXxIFjhCzHW34f273VhBMWoUfaYxLAlFIPsnEn
TCvLwgdgSZqRIOH7+QyZHTVwvexVqHTu0mUWRTkCFoDX58PLfE4UolpRZGY/g/4n
MUDwmTvMaC7q90JhskCCCBcORgLnQpv4pqaTD6XV8x7Dnk96oT1BgDY7j5tu2Ezj
dp3ZPsPlf36xjYO9SGxu24KJvbb0DSeCxqN27EYa0p4yE/zAWyve2TsPX5lTdiVF
jZIrzoCBpBAu8/ggUBIDZOwgXMbHj2xTu2b1QFo2XOI+xSl57V+O5u2cuhEtQYYR
6kcK44cIYjKEUjroaxcn5CaIpOzmEuGq1O+1cNM+s7jXqPSQswa9EnJ5NyXs2IHw
EAOpqOpuQdNnk0cPqYv2zKhvTiP7Y6mR7aFA7zMOKPOD2Eh3E1BksPHk7hIKIjoS
nsVQ0f2sBntBUUmcc21QlPe5iSIuRrtj9hc3xiS2B4GygjiAflp443VL46ytjlH5
vlm5PBCN8ZZx0AvPc6n/
=Hnq4
-END PGP SIGNATURE-
RFC: better policy for ChageLogs (was: Re: [gentoo-dev] Council May Summary: Changes to ChangeLog handling)
В Пнд, 30/05/2011 в 14:55 -0700, Brian Harring пишет: > The problem is, that's a *fuzzy* definition. Ok, let's start with something and then we'll add more items if required. Currently I'd like to propose following text: The ChangeLog must be updated with each commit. The only possible relaxations for this rule are: 1. Nonfunctional whitespace changes 2. Changes in comments (lines starting with # in ebuild, or leading text in patches) 3. Manifest updates 4. Changes in ChageLog itself ;) Something unclear? Anything else? -- Peter. diff --git a/ebuild-writing/misc-files/changelog/text.xml b/ebuild-writing/misc-files/changelog/text.xml index d92bbf4..eea927e 100644 --- a/ebuild-writing/misc-files/changelog/text.xml +++ b/ebuild-writing/misc-files/changelog/text.xml @@ -5,10 +5,21 @@ -The ChangeLog must be updated with each commit. The -echangelog tool should be used to create ChangeLog entries; -the format of a ChangeLog is now defined as "whatever -echangelog creates". +The ChangeLog must be updated with each commit. The only possible +relaxations for this rule are: + + + + 1. Nonfunctional whitespace changes + 2. Changes in comments (lines starting with # in ebuild, or leading text in patches) + 3. Manifest updates + 4. Changes in ChageLog itself ;) + + + +The echangelog tool should be used to create ChangeLog entries; the +format of a ChangeLog is now defined as "whatever echangelog +creates".
[gentoo-dev] [Test request] Group plugdev for udisks and upower
Mailed a while back about restoring the plugdev group behavior like HAL had for their udev replacements upower and udisks, so finally got something real to be tested: http://bugs.gentoo.org/369667 Just comment on the bug instead of ML Thanks, Samuli
