[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Peter Volkov]

В Вск, 08/11/2009 в 11:56 +0000, Patrick Lauer (patrick) пишет:
> patrick     09/11/08 11:56:46
>   Log:
>   Bump

> file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-forensics/foremost/foremost-1.5.6.ebuild?rev=1.1&view=markup

> Index: foremost-1.5.6.ebuild
> ===================================================================

> inherit eutils toolchain-funcs
> 
> DESCRIPTION="A console program to recover files based on their headers and footers"
> HOMEPAGE="http://foremost.sourceforge.net/"
> #SRC_URI="mirror://sourceforge/${PN}/${P}.tar.gz"
> # starting to hate sf.net ...
> SRC_URI="http://foremost.sourceforge.net/pkg/foremost-1.5.6.tar.gz"

Patrick, do you remember the answer on question number 1 in end-quiz?

> KEYWORDS="~ppc ~x86 ~amd64"

> src_install() {
> 	dobin foremost

This question did not existed in end-quiz at times you were mentored,
but still you are supposed to follow gentoo development and you are
supposed to know the answers on quizzes. Please check question 15 of
end-quiz.


-- 
Peter.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Patrick Lauer]

On Sunday 08 November 2009 15:21:18 Peter Volkov wrote:
> В Вск, 08/11/2009 в 11:56 +0000, Patrick Lauer (patrick) пишет:
> > patrick     09/11/08 11:56:46
> >   Log:
> >   Bump
> >
> > file :
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-forensics/foremost/fo
> >remost-1.5.6.ebuild?rev=1.1&view=markup
> >
> > Index: foremost-1.5.6.ebuild
> > ===================================================================
> >
> > inherit eutils toolchain-funcs
> >
> > DESCRIPTION="A console program to recover files based on their headers
> > and footers" HOMEPAGE="http://foremost.sourceforge.net/"
> > #SRC_URI="mirror://sourceforge/${PN}/${P}.tar.gz"
> > # starting to hate sf.net ...
> > SRC_URI="http://foremost.sourceforge.net/pkg/foremost-1.5.6.tar.gz"
> 
> Patrick, do you remember the answer on question number 1 in end-quiz?
> 
Yeah, and if sf.net would even tangentially try to work I might care.
Took me long enough to get a file out of it, and if I feel like it I might 
even fix that SRC_URI to make people happy.
Ah well. Since they love changing paths around it won't work for the next bump 
anyway ...

> > KEYWORDS="~ppc ~x86 ~amd64"
> >
> > src_install() {
> > 	dobin foremost
> 
> This question did not existed in end-quiz at times you were mentored,
> but still you are supposed to follow gentoo development and you are
> supposed to know the answers on quizzes. Please check question 15 of
> end-quiz.
Please check history of the ebuilds. It's been like this since 2004 in 
foremost. I don't intend to clean up every ebuild I touch. 

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

Patrick Lauer wrote:
> On Sunday 08 November 2009 15:21:18 Peter Volkov wrote:
>> В Вск, 08/11/2009 в 11:56 +0000, Patrick Lauer (patrick) пишет:
>>> patrick     09/11/08 11:56:46
>>>   Log:
>>>   Bump
>>>
>>> file :
>>> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-forensics/foremost/fo
>>> remost-1.5.6.ebuild?rev=1.1&view=markup
>>>
>>> Index: foremost-1.5.6.ebuild
>>> ===================================================================
>>>
>>> inherit eutils toolchain-funcs
>>>
>>> DESCRIPTION="A console program to recover files based on their headers
>>> and footers" HOMEPAGE="http://foremost.sourceforge.net/"
>>> #SRC_URI="mirror://sourceforge/${PN}/${P}.tar.gz"
>>> # starting to hate sf.net ...
>>> SRC_URI="http://foremost.sourceforge.net/pkg/foremost-1.5.6.tar.gz"
>> Patrick, do you remember the answer on question number 1 in end-quiz?
>>
> Yeah, and if sf.net would even tangentially try to work I might care.
> Took me long enough to get a file out of it, and if I feel like it I might 
> even fix that SRC_URI to make people happy.
> Ah well. Since they love changing paths around it won't work for the next bump 
> anyway ...
> 

The filename that violates our policies hasn't changed between the new
and old SRC_URI.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Patrick Lauer]

On Sunday 08 November 2009 15:56:24 Petteri Räty wrote:
> Patrick Lauer wrote:
> > On Sunday 08 November 2009 15:21:18 Peter Volkov wrote:
> >> В Вск, 08/11/2009 в 11:56 +0000, Patrick Lauer (patrick) пишет:
> >>> patrick     09/11/08 11:56:46
> >>>   Log:
> >>>   Bump
> >>>
> >>> file :
> >>> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-forensics/foremost/
> >>>fo remost-1.5.6.ebuild?rev=1.1&view=markup
> >>>
> >>> Index: foremost-1.5.6.ebuild
> >>> ===================================================================
> >>>
> >>> inherit eutils toolchain-funcs
> >>>
> >>> DESCRIPTION="A console program to recover files based on their headers
> >>> and footers" HOMEPAGE="http://foremost.sourceforge.net/"
> >>> #SRC_URI="mirror://sourceforge/${PN}/${P}.tar.gz"
> >>> # starting to hate sf.net ...
> >>> SRC_URI="http://foremost.sourceforge.net/pkg/foremost-1.5.6.tar.gz"
> >>
> >> Patrick, do you remember the answer on question number 1 in end-quiz?
> >
> > Yeah, and if sf.net would even tangentially try to work I might care.
> > Took me long enough to get a file out of it, and if I feel like it I
> > might even fix that SRC_URI to make people happy.
> > Ah well. Since they love changing paths around it won't work for the next
> > bump anyway ...
> 
> The filename that violates our policies hasn't changed between the new
> and old SRC_URI.
> 
Correct. Just the PATH. Which is not the filename.

And because I'm a lazy bum I copypasta'ed it out of the mess the sourceforge 
people call a website. And then I even managed to fetch that file after 3 or 4 
tries, so I was happy to have gotten it and cared more to see if it works.

So I'd appreciate if y'all stopped obsessing about such details and just fix 
it instead of whining at me until my motivation takes a long walk on the beach 
and doesn't return for quite some time. At least I'm trying to keep these 
packages alive, which noone else seems to do. 

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Fabian Groffen]

On 08-11-2009 16:06:58 +0100, Patrick Lauer wrote:
> So I'd appreciate if y'all stopped obsessing about such details and
> just fix it instead of whining at me until my motivation takes a long

+1

> walk on the beach and don't return for quite some time. At least I'm
> trying to keep these packages alive, which noone else seems to do. 

thanks


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 442 bytes --]

Patrick Lauer wrote:

> So I'd appreciate if y'all stopped obsessing about such details and just fix 
> it instead of whining at me until my motivation takes a long walk on the beach 
> and doesn't return for quite some time. At least I'm trying to keep these 
> packages alive, which noone else seems to do. 

In the long time more time is spent in total if you do a crappy job and
others clean up after you.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 448 bytes --]

On Sunday 08 November 2009 10:06:58 Patrick Lauer wrote:
> So I'd appreciate if y'all stopped obsessing about such details and just
>  fix it instead of whining at me until my motivation takes a long walk on
>  the beach and doesn't return for quite some time. At least I'm trying to
>  keep these packages alive, which noone else seems to do.

if you're introducing crap into the tree, then it is better if you took that 
long walk
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Mike Auty]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Patrick Lauer wrote:
> At least I'm trying to keep these 
> packages alive, which noone else seems to do. 

If you spot that a new version is available, you're more than welcome to
post a version bump bug assigned to the appropriate herd and developer
(forensics and me, in this instance).

I don't necessarily have time to stayed glued to exactly when new
versions of a package come out, but that doesn't mean I'm not willing to
spend the time to keep it up to date once I'm aware a new version's come
out.  If nobody tells me, it'll have to wait until I spot it myself.

Foremost has a single bug open against it, which is a stabilization bug,
that means it still compiles, and works, or that no one's bothered to
complain about it.  So I'd class the package as far from dead.

Please don't claim no one else wants to keep the package alive, when you
don't afford them the opportunity to demonstrate that they do.  If you
take responsibility for bumping a package from the appropriate
maintainer, you can't then turn around and claim you're allowed to cut
corners because no one was maintaining it.  It's quite rude to the
people who are willing to look after it...

Mike  5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (GNU/Linux)

iEYEARECAAYFAkr25AYACgkQu7rWomwgFXrIxQCgnVdigpUJZnaW28HcJ2U8qQZy
b9IAoJc2Afv0UfrrYu7xe7EdP1DCP2Ze
=m8Os
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Peter Volkov]

В Вск, 08/11/2009 в 16:06 +0100, Patrick Lauer пишет:
> And because I'm a lazy 

> I'd appreciate if y'all stopped obsessing about such details and just fix 
> it instead 

Do you mean that whatever you commit to the tree is not your
responsibility? Sorry but it's your job.

Also it's nice to see how you touch packages without even minimal
negotiation with maintainers and at the same time you are not subscribed
to bug mail of relevant herds and you do not add yourself into
metadata.xml. Such behaviour is prohibited. Please, stop doing that.


-- 
Peter.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Patrick Lauer]

On Sunday 08 November 2009 18:37:10 Peter Volkov wrote:
> В Вск, 08/11/2009 в 16:06 +0100, Patrick Lauer пишет:
> > And because I'm a lazy
> >
> > I'd appreciate if y'all stopped obsessing about such details and just fix
> > it instead
> 
> Do you mean that whatever you commit to the tree is not your
> responsibility? Sorry but it's your job.
I make things work. Cosmetics are quite low on my list of priorities.
Feel free to fix such things.
All "my" packages are free for all to bump, fix and extend, as long as whoever 
touched it is willing to fix any issues that happen from it. 

> 
> Also it's nice to see how you touch packages without even minimal
> negotiation with maintainers and at the same time you are not subscribed
> to bug mail of relevant herds and you do not add yourself into
> metadata.xml. Such behaviour is prohibited. Please, stop doing that.
I'm the only person in the benchmarks herd and with dragonheart the only one 
in forensics herd. What's the exact problem here? 

Also, if I break anything ... assign the bugs to me. I'll unbreak it. Easy as 
that. And if you're rude enough I'll avoid touching your packages in the 
future and yell at you when things don't get fixed in a reasonable time.

Have fun,

Patrick

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1083 bytes --]

On Sunday 08 November 2009 13:10:34 Patrick Lauer wrote:
> On Sunday 08 November 2009 18:37:10 Peter Volkov wrote:
> > В Вск, 08/11/2009 в 16:06 +0100, Patrick Lauer пишет:
> > > And because I'm a lazy
> > >
> > > I'd appreciate if y'all stopped obsessing about such details and just
> > > fix it instead
> >
> > Do you mean that whatever you commit to the tree is not your
> > responsibility? Sorry but it's your job.
> 
> I make things work. Cosmetics are quite low on my list of priorities.
> Feel free to fix such things.
> All "my" packages are free for all to bump, fix and extend, as long as
>  whoever touched it is willing to fix any issues that happen from it.

using this definition of "correct" (the package installs w/out failure and it 
seems to work), there is a lot of crap that could be in the tree.  that doesnt 
mean the ebuild should be in the tree.  this kind of work and opinion belongs 
in sunrise, not the main tree.  we dont have a QA team to fix installed 
packages; they're here to maintain the *quality* of the tree.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Patrick Lauer]

On Sunday 08 November 2009 19:24:47 Mike Frysinger wrote:
> On Sunday 08 November 2009 13:10:34 Patrick Lauer wrote:
> > On Sunday 08 November 2009 18:37:10 Peter Volkov wrote:
> > > В Вск, 08/11/2009 в 16:06 +0100, Patrick Lauer пишет:
> > > > And because I'm a lazy
> > > >
> > > > I'd appreciate if y'all stopped obsessing about such details and just
> > > > fix it instead
> > >
> > > Do you mean that whatever you commit to the tree is not your
> > > responsibility? Sorry but it's your job.
> >
> > I make things work. Cosmetics are quite low on my list of priorities.
> > Feel free to fix such things.
> > All "my" packages are free for all to bump, fix and extend, as long as
> >  whoever touched it is willing to fix any issues that happen from it.
> 
> using this definition of "correct" (the package installs w/out failure and
>  it seems to work), there is a lot of crap that could be in the tree.  that
>  doesnt mean the ebuild should be in the tree.  this kind of work and
>  opinion belongs in sunrise, not the main tree.
I hope you realize what percentage of packages are completely unmaintained or 
only tangentially maintained. By that reasoning we better cut out everything 
apart from the base system, xorg, kde and gnome. Oh, and python. (If I missed 
anyone here, please don't take this personal. It's a reductio ad absurdum I'm 
doing here, so it better be absurd!)

If you haven't noticed (here's a really hilarious one!) ...
We currently do not have anyone seriously maintaining all the perl bits. 
There's, uhm, ... err ... there used to be Tove, who did an awesome job.

I took over benchmark and forensics herd because they were empty, not because 
I care about those packages.

sgml and ha-cluster herds are quite vacant as far as I can tell.

bugwranglers are understaffed and can barely keep up with the current flood 
from our motivated and skillfull bug-finding users.

So maybe now you understand my mentality of just fixing whatever bugs I 
encounter. I don't care at all about your idealistic views of how we were to 
do things if everything worked. Reality doesn't tolerate it well. Bugs happen, 
and we better start fixing them.

>  we dont have a QA team to
>  fix installed packages; they're here to maintain the *quality* of the
>  tree.
That's good. So start fixing stuff. Maybe take over the empty herds until you 
manage to recruit some replacements.

If you feel you have too much time you could search on bugzilla for "patch" 
and start fixing those bugs. "Bump" is also a funny search. 

Or if you don't know what else to do, there's this nice "Bug Wranglers" search 
at the bottom of the bugzilla pages. Click on it and get the amount of bugs in 
the bugwrangler queue under 100 if you can!

Once you've done that for 3 months we can renegotiate cosmetic bugs and QA.

Kthxbai,

Patrick

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Mark Loeser]

[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]

Patrick Lauer <patrick@gentoo.org> said:
> If you feel you have too much time you could search on bugzilla for "patch" 
> and start fixing those bugs. "Bump" is also a funny search. 

If you are just bumping random packages and applying patches when you
have no idea how the package works, we have a problem on our hands.
Please don't do that, you are only making more work for others.  Perhaps
some of the things that are not maintained should go away.

> Once you've done that for 3 months we can renegotiate cosmetic bugs and QA.

Renegotiate QA?  Do not commit anything to the tree that doesn't comply
to QA standards.  Its really that simple.  Don't be lazy and do things
the right way, or don't do them at all.


> Kthxbai,

Also, please learn how to communicate in a manner that is constructive
instead of acting like a dick at every opportunity.

-- 
Mark Loeser
email         -   halcy0n AT gentoo DOT org
email         -   mark AT halcy0n DOT com
web           -   http://www.halcy0n.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Patrick Lauer]

On Sunday 08 November 2009 20:27:23 Mark Loeser wrote:
> Patrick Lauer <patrick@gentoo.org> said:
> > If you feel you have too much time you could search on bugzilla for
> > "patch" and start fixing those bugs. "Bump" is also a funny search.
> 
> If you are just bumping random packages and applying patches when you
> have no idea how the package works, we have a problem on our hands.
> Please don't do that, you are only making more work for others.  Perhaps
> some of the things that are not maintained should go away.

Like Perl? I like your plan already.

> > Once you've done that for 3 months we can renegotiate cosmetic bugs and
> > QA.
> 
> Renegotiate QA?  Do not commit anything to the tree that doesn't comply
> to QA standards.  Its really that simple.  Don't be lazy and do things
> the right way, or don't do them at all.

That is an interesting opinion. But I doubt we're in a position to demand such 
things - I did point at a few minor issues in my last email, none of which you 
responded to in any way. So I guess you prefer things being unmaintained and 
rotting away so our users have the shittiest user experience possible instead 
of people trying to make things better.

Now if you really were interested in QA you might want to do some things - 
like help bugwranglers. With the current amount of people available (not 
enough) and the influx of bugs (100-200 a day) we have a latency of worst case 
a few days until a bugwrangler looks at it. (Average case is much better). 
That is time the maintainers are not informed of a bug, which means we delay  
fixing it. Sucks from a QA point of view.

Things like that would be good to have, but instead y'all spend lots of time 
discussing on mailinglists and not helping there. (Ok, we're all volunteers, 
we all have limited time, etc. etc.) So I find it a bit hard to care about 
your academic discussion of how to handle things when I haven't heard any idea 
of a solution to the problems I mentioned earlier. Head-in-the-sand is not 
going to work.

And again, start at the basics. You can't build a tower without a solid 
foundation. "Does it compile" is more important than "does it respect as-
needed" or "is indentation beautiful", so prioritize a bit and focus on 
getting the big problems resolved. 

Take care,

Patrick

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 452 bytes --]

none of your points here are relevant to the original issue at hand.  like 
Mark said, if you cant be bothered to do it right in the first place, then 
dont do it at all.  if that means packages get removed from the tree, then so 
be it.  it isnt that hard to do it right in the first place, so stop bemoaning 
the point.  people have done volumes of work in the past to update random 
packages and didnt have trouble tackling the basics.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Ben de Groot]

2009/11/8 Mark Loeser <halcy0n@gentoo.org>:
> Also, please learn how to communicate in a manner that is constructive
> instead of acting like a dick at every opportunity.

Looks to me this should be applied to some others in this thread first.
Really, aren't there more constructive ways to communicate your (meaning
all of you in this thread) concerns, without demotivating the person who
does so much work for Gentoo?

Cheers,
-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
______________________________________________________

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Mark Loeser]

[-- Attachment #1: Type: text/plain, Size: 777 bytes --]

Ben de Groot <yngwin@gentoo.org> said:
> 2009/11/8 Mark Loeser <halcy0n@gentoo.org>:
> > Also, please learn how to communicate in a manner that is constructive
> > instead of acting like a dick at every opportunity.
> 
> Looks to me this should be applied to some others in this thread first.
> Really, aren't there more constructive ways to communicate your (meaning
> all of you in this thread) concerns, without demotivating the person who
> does so much work for Gentoo?

If the person doing said work does not care about abiding by QA
standards, then that person shouldn't be touching the tree to begin
with.

-- 
Mark Loeser
email         -   halcy0n AT gentoo DOT org
email         -   mark AT halcy0n DOT com
web           -   http://www.halcy0n.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Ben de Groot]

2009/11/8 Mark Loeser <halcy0n@gentoo.org>:
> Ben de Groot <yngwin@gentoo.org> said:
>> Really, aren't there more constructive ways to communicate your (meaning
>> all of you in this thread) concerns, without demotivating the person who
>> does so much work for Gentoo?
>
> If the person doing said work does not care about abiding by QA
> standards, then that person shouldn't be touching the tree to begin
> with.

So, you didn't get my point. It must be true then, what they say about geeks
and social skills...

Cheers,
-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
______________________________________________________

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 670 bytes --]

On Sunday 08 November 2009 15:22:19 Ben de Groot wrote:
> 2009/11/8 Mark Loeser <halcy0n@gentoo.org>:
> > Ben de Groot <yngwin@gentoo.org> said:
> >> Really, aren't there more constructive ways to communicate your (meaning
> >> all of you in this thread) concerns, without demotivating the person who
> >> does so much work for Gentoo?
> >
> > If the person doing said work does not care about abiding by QA
> > standards, then that person shouldn't be touching the tree to begin
> > with.
> 
> So, you didn't get my point. It must be true then, what they say about
>  geeks and social skills...

i dont think your point is relevant to this thread
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Maciej Mrozowski]

[-- Attachment #1: Type: Text/Plain, Size: 341 bytes --]

On Sunday 08 of November 2009 23:19:13 Mike Frysinger wrote:

> > So, you didn't get my point. It must be true then, what they say about
> >  geeks and social skills...
> 
> i dont think your point is relevant to this thread
> -mike

Indeed it is - it's not about what's been said, but about the way it's been 
said.

cheers
MM

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 740 bytes --]

On Monday 09 November 2009 07:36:31 Maciej Mrozowski wrote:
> On Sunday 08 of November 2009 23:19:13 Mike Frysinger wrote:
> > > So, you didn't get my point. It must be true then, what they say about
> > >  geeks and social skills...
> >
> > i dont think your point is relevant to this thread
> 
> Indeed it is - it's not about what's been said, but about the way it's been
> said.

except that this thread has largely been timid.  the issue is patrick cant 
seem to accept the fact that laziness is no excuse to add crap to the tree.  
we shouldnt need to tell him how much we love him unrelated to his crap 
adding.  go buy a teddy bear if your confidence needs reinforcing, or find 
some baby boomers to raise you.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Vlastimil Babka]

Ben de Groot wrote:
> 2009/11/8 Mark Loeser <halcy0n@gentoo.org>:
>> Also, please learn how to communicate in a manner that is constructive
>> instead of acting like a dick at every opportunity.
> 
> Looks to me this should be applied to some others in this thread first.
> Really, aren't there more constructive ways to communicate your (meaning
> all of you in this thread) concerns, without demotivating the person who
> does so much work for Gentoo?
> 
> Cheers,

I totally agree. And I must say it started with the very first mail of 
pva. Accusing of not knowing quizzes was totally uncalled for. As 
patrick said, the SRC_URI thing was simply forgot to be polished after 
testing, and the dobin thing he didn't even touch. Who remembers what 
everything should have || die or not from the top of his head and spots 
it immediatelly? And this offensive tone just provoked adequate reaction 
and here we are, useless flame. People can sometimes commit much worse 
stuff by mistake, this didn't break anything. If the first mail was just 
a 'hey this should bw changed to X and Y', that could be it.

It's great that somebody cares to fix stuff, it's also great that 
somebody watches the commits for mistakes, but let's be civilized about it.

Vlastimil

Re: [gentoo-dev] QA is unimportant? (was: gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild)

[Peter Volkov]

В Пнд, 09/11/2009 в 01:37 +0100, Vlastimil Babka пишет:
> I totally agree. And I must say it started with the very first mail of 
> pva. Accusing of not knowing quizzes was totally uncalled for.

If you know how to do thing properly what are the reasons avoid doing
that? All I heard here is laziness and I don't think this is acceptable.

> As patrick said, the SRC_URI thing was simply forgot to be polished after 
> testing, and the dobin thing he didn't even touch. Who remembers what 
> everything should have || die or not from the top of his head and spots 
> it immediatelly?

Quizzes are the basic knowledge required to work with tree. Do you state
that it's impossible to remember answers on quizzes? Should we drop
quizzes then and let people do whatever they want with the tree? Please,
stop this nonsense advocation.


> And this offensive tone just provoked adequate reaction

Offence was not my intention. I apologize for tone.


That said, Patrick insist on mistakes he is well aware about, e.g. take
a look at this ebuild:

http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-analyzer/snort/snort-2.8.4.1.ebuild?hideattic=0&rev=1.1&view=markup

This is user submitted ebuild, without any modifications and with number
of QA problems that Patrick commited. I've tried to contact Patrick and
Jason (user who did and does snort job) and while Jason fixed everything
in next version Patrick avoided to fix even crying things (e.g. missed
|| die after emake) in the tree for ebuild that was fast stabilized. No
offense, but again I have to admit that Patrick forgot an answers on
ebuild-quiz questions 3 (b) and 4. And worst thing is that he is not
going to fix things he commited to the tree... I hope this explains my
tone, but again I apologize for it.


> and here we are, useless flame.

This thread is not "useless flame". It revealed at least two concerns:

1. Our good non-formal policy "if developer touched anything he becames
responsible for that ebuild and should fix issues noticed" is sometimes
ignored. We see people reacting: you've noticed - you fix. I think such
attitude is unacceptable.

Telling somebody that crap was in the previous version of ebuild so I'm
not gonna fix it does not make any sense. Things change and developers
are supposed to follow changes. This means that since new coding
standards were introduced new ebuilds follow them. Even users on Sunrise
managed to learn this easy || die thing and I really hope that
developers who passed quizzes are capable too. I don't even see how ||
die is "cosmetics" - it is either redudand (in case of econf) or missed
code (in case of make). The first one just introduces more crap around
the latter could make ebuild miss build failure.

2. Some developers prefer to do "blind" bumps (just rename .ebuild and
check if it builds). This kind of things are possible in case package is
used on daily basis and package development was followed. In all other
cases if developer touchs new package he is supposed to check it as a
"new package", from the very beginning. In case version bump done
properly the things I'm asking about will take less then 1% of
developer's time: with bump developer is supposed to review
modifications of build system, check if seds/patches inside package are
still required and check that there are no new deps. At the same time
it's really easy remove redudant || die or drop default src_compile
{ emake || die ; } functions. I'm really surprised to see that people
insist that such ebuilds are better then unmaintained: it's really hard
to call such "blind" bump as package maintainance but this bump hides
unmaintained packages in the tree. Yes, this makes things worse.


Well, it looks like the root of this problem is the following statement:
"QA is less important then new packages in the tree". I failed to hear
any arguments why QA is unimportant so I still believe that QA problem
is a problem.

-- 
Peter.

Re: [gentoo-dev] QA is unimportant? (was: gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild)

[Ben de Groot]

If you have concerns, try a friendly approach and ask Patrick to fix them.
I'm quite convinced he would be happy to do so. Your offensive approach
achieves the opposite. That isn't in the interest of QA either.

Cheers,
-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
______________________________________________________

Re: [gentoo-dev] QA is unimportant?

[Richard Freeman]

Peter Volkov wrote:
> 1. Our good non-formal policy "if developer touched anything he becames
> responsible for that ebuild and should fix issues noticed" is sometimes
> ignored. We see people reacting: you've noticed - you fix. I think such
> attitude is unacceptable.

Keep in mind the downside to such a policy is that people just ignore 
problems that are trivial to fix, because they don't have the time to go 
over the ebuild with a fine-toothed comb.  Then, if people get their 
heads chewed off on -dev if they do miss something that lowers the 
motivation just a bit more.

Sure, if a dev fixes an ebuild they should give it a once-over to make 
sure there are no major problems, and obviously they should do moderate 
testing to make sure it builds and works.  However, if I spotted a minor 
problem with an ebuild that I could fix, and a major problem that I 
couldn't fix, chances are that I wouldn't touch it at all.  Then the 
ebuild stays in the tree with both problems, instead of one fewer.

I think it all boils down to "we're all in this together."  If you see a 
problem try to fix it, and if you see somebody make a mistake try to 
help them out.    While we do need policies, and policies do imply 
police, nobody likes the police, so let's try to make that work with the 
minimum in fuss.  A good rule of thumb is whether a dev has left a 
situation better off or worse off than when they touched something, and 
in this case I'd have to say that we're better off.

While the good can be the enemy of the best, sometimes the best can be 
the enemy of the good, and I think that sums up the current situation well.

Re: [gentoo-dev] QA is unimportant?

[Thilo Bangert]

[-- Attachment #1: Type: Text/Plain, Size: 244 bytes --]

Richard Freeman <rich0@gentoo.org> said:
[good stuff]

i share this sentiment. lets stay an open community and encourage 
learning.

if somebody improves a package then that is a good thing. even if it could 
be improved even more.



[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] QA is unimportant?

[Patrick Lauer]

On Monday 09 November 2009 13:08:52 Peter Volkov wrote:
[Snip]
> Well, it looks like the root of this problem is the following statement:
> "QA is less important then new packages in the tree". I failed to hear
> any arguments why QA is unimportant so I still believe that QA problem
> is a problem.
> 
Ok, here's the real problem;

"Unmaintained stuff is unmaintained"

And instead of being happy that people like ssuominen just fix things where 
other people don't (be it because these other people have no interest, only 
care about a few packages or have become distracted with life) some people get 
really confused and start working on demotivating us.

You should understand one thing: I don't care at all about most packages. I'm 
handling virtualbox because right now jokey doesn't seem to have the time. I 
fixed Xen bugs because drobbins pointed out that there were a few bugs with 
it, and the current maintainers seem to have gone for a long walk in the park. 
Can't blame anyone there (I've disappeared for some time too), but those 
packages would be in a really useless state now. 
And if I break something for a day or two, well, that's ~arch for you. I try 
to avoid breaking things, but if things break in ~arch the users shouldn't be 
too surprised. Otherwise we wouldn't even have to care about having the 
arch/~arch split. Better a slightly buggy version than a security-exploitable 
version. Especially when the bug gets fixed the next day.

So find me a dozen recruits that can properly maintain things and I won't feel 
the need to touch random packages. Stop living in your sandbox and have a look 
at the bigger picture :)
(Btw, I wonder how many bugs glibc-2.11 will bring. We'll just let users 
discover them. I love that QA!)
I'm trying to get people to help me, but it's a slow tedious process to even 
motivate most. And then our recruiting puts up a virtual wall many don't want 
to climb over. At times it's tiring, it's demotivating, and still we go on. 
Because we still believe that we can improve things. And as they say, you 
can't make an omlette without breaking some eggs.

Take care,

Patrick

Re: [gentoo-dev] QA is unimportant?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1510 bytes --]

On Monday 09 November 2009 11:30:27 Patrick Lauer wrote:
> And instead of being happy that people like ssuominen just fix things where
> other people don't (be it because these other people have no interest, only
> care about a few packages or have become distracted with life) some people
>  get really confused and start working on demotivating us.

oh muffin !  get over it already.  either do it right or stop doing it.

> You should understand one thing: I don't care at all about most packages.

then let them die.

>  I'm handling virtualbox because right now jokey doesn't seem to have the
>  time.

jokey hasnt been doing virtualbox in a long time either.  it's been proxy 
maintained.  i know because i was fixing things for a while too.

> So find me a dozen recruits that can properly maintain things and I won't
>  feel the need to touch random packages. Stop living in your sandbox and
>  have a look at the bigger picture :)

we are looking at the bigger picture.  everything in the tree is an example 
for people.  if you throw crap in, people think crap is acceptable and will 
base their work on it.

> (Btw, I wonder how many bugs glibc-2.11 will bring. We'll just let users
> discover them. I love that QA!)

hmm, let's see, one package that was already broken under other C libraries 
broke under glibc-2.11.  and it's already been fixed.  of course, if you'd 
simply used bugzilla's search function, you wouldnt have to rhetorically 
wonder aloud.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] QA is unimportant?

[Robert Bradbury]

[-- Attachment #1: Type: text/plain, Size: 1007 bytes --]

I believe QA is important from the perspective that you want to assure that
the ebuilds work.  Nothing makes a casual user more annoyed that having an
emerge for his machine fail to work.  But if you are running the emerges
unconstrained (e.g. you specify them in the keywords file) then you are
"exposed".

A recent example is the mythtv package.  It does not compile on an x86
without significant intervention (Gentoo Bug #292421).  How does it make it
into the "release" category without it compiling on the most common
machines?  (I'm dealing with an older x86 Pentium IV Prescott machine from
HP and there have to be millions of them out there in the world.).

There should be some sort of QA procedure which says "the package builds on
these minimal list of machines" before it should be released.

Then there is a separate discussion about how to best migrate people from
the "approved" packages to the cutting edge packages with some level of
warning to the user ("this may be problematic")

Robert

[-- Attachment #2: Type: text/html, Size: 1179 bytes --]

Re: [gentoo-dev] QA is unimportant?

[Patrick Lauer]

On Monday 09 November 2009 21:16:28 Mike Frysinger wrote:

> oh muffin !  get over it already.  either do it right or stop doing it.

perl?

That's how you want to handle things? Great.
I think we can agree that that strategy doesn't work.
 
> > You should understand one thing: I don't care at all about most packages.
> then let them die.
Not an option. I refuse to sabotage the best distro in the world. 
 
> > (Btw, I wonder how many bugs glibc-2.11 will bring. We'll just let users
> > discover them. I love that QA!)
> 
> hmm, let's see, one package that was already broken under other C libraries
> broke under glibc-2.11.  and it's already been fixed.  of course, if you'd
> simply used bugzilla's search function, you wouldnt have to rhetorically
> wonder aloud.
So you actually built all packages against it? Awesome. I thought flameeyes 
and the sabayon people were the only one doing that at the moment.

And talking about glibc ...

For 2.11 you didn't even test if all patches apply (bug #292139)
and maybe forgot to upload a patch (#292223)

Plus a few bugs (hello simple bugzilla search function!) that I can't comment 
on yet as they might be user error.
So please, do not try to talk to me about QA when you can't even handle simple 
things without error yourself. Especially on critical system packages.

Let's just agree that things aren't perfect and when we discuss this topic 
next time - maybe in a year - we want things to be better. 

Bye,

Patrick

Re: [gentoo-dev] QA is unimportant?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 2496 bytes --]

On Monday 09 November 2009 17:52:23 Patrick Lauer wrote:
> On Monday 09 November 2009 21:16:28 Mike Frysinger wrote:
> > oh muffin !  get over it already.  either do it right or stop doing it.
> 
> perl?

you [thankfully] arent handling perl, so i dont see how that package is 
relevant.

> > > You should understand one thing: I don't care at all about most
> > > packages.
> >
> > then let them die.
> 
> Not an option. I refuse to sabotage the best distro in the world.

apparently you're incapable of realizing that you already are.

> > > (Btw, I wonder how many bugs glibc-2.11 will bring. We'll just let
> > > users discover them. I love that QA!)
> >
> > hmm, let's see, one package that was already broken under other C
> > libraries broke under glibc-2.11.  and it's already been fixed.  of
> > course, if you'd simply used bugzilla's search function, you wouldnt have
> > to rhetorically wonder aloud.
> 
> So you actually built all packages against it? Awesome. I thought flameeyes
> and the sabayon people were the only one doing that at the moment.
> 
> And talking about glibc ...
> 
> For 2.11 you didn't even test if all patches apply (bug #292139)

this example is bs and you know it.  i'm not going to test every USE flag 
combo, especially ones that take specific profiles.  ignoring that, this is 
for configurations that another team handles.  i'm not maintaining the 
hardening patches.

> and maybe forgot to upload a patch (#292223)

yes, i roll so many patch tarballs that i sometimes forget to post some.  and 
it's not an obvious scenario to me since it emerges fine on my system.

> Plus a few bugs (hello simple bugzilla search function!) that I can't
>  comment on yet as they might be user error.
> So please, do not try to talk to me about QA when you can't even handle
>  simple things without error yourself. Especially on critical system
>  packages.

this is sort of argument is also complete bs.  other people causing bugs is 
absolutely no excuse to knowingly introduce bugs of your own.  unlike yours, 
mine werent done on purpose.

> Let's just agree that things aren't perfect and when we discuss this topic
> next time - maybe in a year - we want things to be better.

no.  you've been told by multiple developers, including the QA team, to stop 
knowingly introduce crap into the tree.  if you dont fix your development 
processes, the next step is to punt you yet again from the pool.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] QA is unimportant?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 926 bytes --]

On Monday 09 November 2009 18:45:46 Mike Frysinger wrote:
> On Monday 09 November 2009 17:52:23 Patrick Lauer wrote:
> > On Monday 09 November 2009 21:16:28 Mike Frysinger wrote:
> > And talking about glibc ...
> >
> > For 2.11 you didn't even test if all patches apply (bug #292139)
> 
> this example is bs and you know it.  i'm not going to test every USE flag
> combo, especially ones that take specific profiles.  ignoring that, this is
> for configurations that another team handles.  i'm not maintaining the
> hardening patches.
> 
> > and maybe forgot to upload a patch (#292223)
> 
> yes, i roll so many patch tarballs that i sometimes forget to post some. 
>  and it's not an obvious scenario to me since it emerges fine on my system.

also, unlike you, i acked/fixed the bugs right away instead of whining on a 
mailing list over and over that people are making you fix bugs you introduced
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] QA is unimportant?

[Samuli Suominen]

Mike Frysinger wrote:
> hmm, let's see, one package that was already broken under other C libraries 
> broke under glibc-2.11.  and it's already been fixed.  of course, if you'd 
> simply used bugzilla's search function, you wouldnt have to rhetorically 
> wonder aloud.
> -mike

and I was all excited about new toolchain porting tracker, which never
came... the one bug (kdelibs) was all I had to fix... boo!

more rice!

:)

Re: [gentoo-dev] QA is unimportant?

[Dawid Węgliński]

On Monday 09 November 2009 17:30:27 Patrick Lauer wrote:
> 
> "Unmaintained stuff is unmaintained"
> 

If i can recall my recruitment process, i remember one sentence which was like 
"if you touch any package, you are responsible for it".

Please don't hide behind your great job that you are doing here (we all 
appreciate it) and admit you are wrong. QA (not the QA team itself, but 
policies we have here) is important and talking "excuse me my mistakes because 
i do things others do not" doesn't really matter.

-- 
Cheers
Dawid Węgliński

Re: [gentoo-dev] QA is unimportant?

[Rémi Cardona]

Le 09/11/2009 17:30, Patrick Lauer a écrit :
> Ok, here's the real problem;
>
> "Unmaintained stuff is unmaintained"

Patrick,

Just piping in to say that dropping a package from portage isn't the end 
of the world, we have a very good process for it and it has proven to be 
very effective.

Dead packages should be masked :

1) it tells users that no-one among us devs really care about the 
package. And it's good because we're not lying or pretending to care. I 
think it's honest of us to admit that some packages are abandoned. Users 
deserve to know.

2) it sends a crystal-clear message that this package is up for grabs, 
either by another dev or by a user with a proxy-maintainer. This is yet 
another good thing because it might encourage users to join our ranks.

3) it allows to effectively clear out cruft, and $deity knows portage is 
full of it. Faster sync times, fewer security risks, etc.

So while of course we're not going to p.mask perl because its sole 
maintainer has decided to stop working on it, but for _less_ _important_ 
packages, masking and treecleaning is a *good* thing.

And besides, the beauty of CVS is that deleted files are never really 
gone, so a deleted package can be brought back from the dead in a few 
minutes.

So really, don't feel obliged to touch/bump/fix all unmaintained 
packages, fix those that you use and treeclean the rest. It'll be for 
the best.

Cheers,

Rémi

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]

Mike Frysinger schrieb:
> On Sunday 08 November 2009 13:10:34 Patrick Lauer wrote:
>> On Sunday 08 November 2009 18:37:10 Peter Volkov wrote:
>>> В Вск, 08/11/2009 в 16:06 +0100, Patrick Lauer пишет:
>>>> And because I'm a lazy
>>>>
>>>> I'd appreciate if y'all stopped obsessing about such details and just
>>>> fix it instead
>>> Do you mean that whatever you commit to the tree is not your
>>> responsibility? Sorry but it's your job.
>> I make things work. Cosmetics are quite low on my list of priorities.
>> Feel free to fix such things.
>> All "my" packages are free for all to bump, fix and extend, as long as
>>  whoever touched it is willing to fix any issues that happen from it.
> 
> using this definition of "correct" (the package installs w/out failure and it 
> seems to work), there is a lot of crap that could be in the tree.  that doesnt 
> mean the ebuild should be in the tree.  this kind of work and opinion belongs 
> in sunrise, not the main tree.  we dont have a QA team to fix installed 
> packages; they're here to maintain the *quality* of the tree.
> -mike

Please stop such comments. Sunrise really isnt a place, where you can drop anything in without any
quality check. Join the sunrise team, do our work for some months, then tell me, where it lacks
quality checks or anything else.

-- 
Thomas Sachau

Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1570 bytes --]

On Sunday 08 November 2009 14:46:34 Thomas Sachau wrote:
> Mike Frysinger schrieb:
> > On Sunday 08 November 2009 13:10:34 Patrick Lauer wrote:
> >> On Sunday 08 November 2009 18:37:10 Peter Volkov wrote:
> >>> В Вск, 08/11/2009 в 16:06 +0100, Patrick Lauer пишет:
> >>>> And because I'm a lazy
> >>>>
> >>>> I'd appreciate if y'all stopped obsessing about such details and just
> >>>> fix it instead
> >>>
> >>> Do you mean that whatever you commit to the tree is not your
> >>> responsibility? Sorry but it's your job.
> >>
> >> I make things work. Cosmetics are quite low on my list of priorities.
> >> Feel free to fix such things.
> >> All "my" packages are free for all to bump, fix and extend, as long as
> >>  whoever touched it is willing to fix any issues that happen from it.
> >
> > using this definition of "correct" (the package installs w/out failure
> > and it seems to work), there is a lot of crap that could be in the tree. 
> > that doesnt mean the ebuild should be in the tree.  this kind of work and
> > opinion belongs in sunrise, not the main tree.  we dont have a QA team to
> > fix installed packages; they're here to maintain the *quality* of the
> > tree.
> 
> Please stop such comments. Sunrise really isnt a place, where you can drop
>  anything in without any quality check. Join the sunrise team, do our work
>  for some months, then tell me, where it lacks quality checks or anything
>  else.

you misinterpreted my post.  sunrise has built in processes to get the quality 
up past crap.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Richard Freeman]

Petteri Räty wrote:
>>>> #SRC_URI="mirror://sourceforge/${PN}/${P}.tar.gz"
>>>> # starting to hate sf.net ...
>>>> SRC_URI="http://foremost.sourceforge.net/pkg/foremost-1.5.6.tar.gz"
> 
> The filename that violates our policies hasn't changed between the new
> and old SRC_URI.
> 

Is this policy actually written down someplace?  Sure, having the 
SRC_URI pick up the package version automatically is good practice and 
all, but does this actually rise to the level of a QA policy violation? 
  To me the word "policy violation" means more than just something that 
could have been done better.  It means that someplace there is an 
official rule in writing that wasn't followed, and that rule was 
endorsed by some official body recognized by gentoo.  I don't think 
quizzes can be considered policy since by design their answers aren't 
written anywhere.

The only downside to not being clever with the SRC_URI is that to bump 
the package you'd need to edit the URL.  That isn't exactly the end of 
the world, and while this is a trivial one to fix I've certainly seen a 
few that are quite messy to automate.

Now, if there were no version in the filename I'd consider that a policy 
issue as it would mean that the distfiles would get confused rather 
quickly.  However, not every lack of ideality is a policy violation 
worthy of a 30-post -dev thread.

Even so, it doesn't hurt to point out non-idealities so that they can be 
corrected.  Let's just try not to treat them the same as if somebody had 
keyworded something that breaks stable systems...

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1387 bytes --]

On Sunday 08 November 2009 18:36:00 Richard Freeman wrote:
> Petteri Räty wrote:
> >>>> #SRC_URI="mirror://sourceforge/${PN}/${P}.tar.gz"
> >>>> # starting to hate sf.net ...
> >>>> SRC_URI="http://foremost.sourceforge.net/pkg/foremost-1.5.6.tar.gz"
> >
> > The filename that violates our policies hasn't changed between the new
> > and old SRC_URI.
> 
> Is this policy actually written down someplace?

the gentoo dev handbook lists this as a common ebuild error

> I don't think quizzes can be considered policy since by design their answers
> aren't written anywhere.

the exact answer is generally not found, but the info to arrive there should 
largely be documented and/or obvious.  the issue raised is even worse because 
it is almost verbatim from the quiz.  any prospective dev who got this wrong 
would have been forced to go back and review things.  i.e. it isnt acceptable 
for newbies, so there's no excuse for people who are supposed to be past that 
point -- especially considering they're doing it knowingly.

> The only downside to not being clever with the SRC_URI is that to bump
> the package you'd need to edit the URL.  That isn't exactly the end of
> the world, and while this is a trivial one to fix

since it must have been changed in order to be bumped, there is no excuse for 
having added it like this in the first place.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]