[gentoo-dev] Last rites: app-text/cuneiform

[gentoo-dev] Last rites: app-text/cuneiform

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

# Markos Chandras <hwoarang@gentoo.org> (22 Mar 2013)
# Quite a few buffer overflow and other bugs
# See #462366 #462224 #421717
# Removal in 30 days
app-text/cuneiform

- -- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQJ8BAEBCgBmBQJRTOMsXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw
OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun88DfQP/0aimgGL9jHurJ3PDcsm/Lmm
QahTWhYpRAdSb7JtADQQ1DsBBKyt5cnUpEhR4z2gBGRoy5K6BlD3r7RZpkUSXKgl
unUdfuf45WZwWZgSHSfpT6Ia2hgjtwWVxNzXW9fLLfUp3dI4dUvxoktXnb3laLx3
HeSazMR0B7zfaQ42S09tD4inTt8a3tjlKVdbwk4MLpgW6D3eP3ZW56X/1U4F6xZp
3et4lxGRKjnZEXRHw7fomA10FlZ04S7eiUX8wZzNiD8unO5MO/tTew2uIKidG3fn
bVgbeJraYBGlLPMqPEMdF8NVsztxP3Gc0l1ZDiy0I6M3GkBFL7OsoZRD1nLPwzHj
VajTmCakm/shC19I6hULsCDwF2YTKj0/b2BxGu6gEZ82SgrwdUJ/E471jZot/7Zp
OuYEbv1ifZYN17V8UZSLL8ziq4NYom8b3qwZbC09EO+rBpP79bzYVUtl8dxW7xvs
BUVTtfM6cuV1vEcZ5Z4GIZOY7aJlczVwA0eXh+w0WI9nans9JLhMph5VXOnFuluV
2Kht4PAgMhQuAL6o0qb/L+sG8awq9NYBSZDY95BLjqJ6ik4lMIF5vaMgLAA9/hxb
cLm2TeA6vlcHwbswJb9R2EyGQcBze0tB8bnwlgX0BtNzuOFkcZesrJM4xaL2vnqq
HAx1Gi2q9Ky82VFtbwQF
=VdK8
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Last rites: app-text/cuneiform

[James Cloos]

>>>>> "MC" == Markos Chandras <hwoarang@gentoo.org> writes:

MC> # Removal in 30 days
MC> app-text/cuneiform

That one should not go.  There are not enough quality ocr engines
available, Gentoo needs to keep all of them.

And a couple of bugs is never a sufficient reason to kick a package.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Markos Chandras]

On 23 March 2013 19:52, James Cloos <cloos@jhcloos.com> wrote:
>>>>>> "MC" == Markos Chandras <hwoarang@gentoo.org> writes:
>
> MC> # Removal in 30 days
> MC> app-text/cuneiform
>
> That one should not go.  There are not enough quality ocr engines
> available, Gentoo needs to keep all of them.
>
> And a couple of bugs is never a sufficient reason to kick a package.
>
> -JimC
> --
> James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6
>

Please do not reply to gentoo-dev-announce. The Reply-To was set for a reason.
The package is going away unless someone fixes the bugs and properly
maintains the package

I will not have this conversation again. You are always free to move
this package to an overlay.

-- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-dev] Last rites: app-text/cuneiform

[James Cloos]

>>>>> "MC" == Markos Chandras <hwoarang@gentoo.org> writes:

MC> Please do not reply to gentoo-dev-announce.

I didn't.  I explicitly replied to the message in gentoo-dev.  If doing
that resulted in a cc to announce that means there was no reply-to
header in the message posted to dev.  Had there been a reply-to header
gnus would have asked me whether to accept it.

MC> The package is going away unless someone fixes the bugs and properly
MC> maintains the package

Again, that is an irresponsible mistake.  It is better to just leave it
as is than to kick it.  Dropping important packages can only harm the
community and is never welcome.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Markos Chandras]

On 23 March 2013 20:13, James Cloos <cloos@jhcloos.com> wrote:
>
> Again, that is an irresponsible mistake.  It is better to just leave it
> as is than to kick it.  Dropping important packages can only harm the
> community and is never welcome.

You are not listening to what I am saying so I'll stop here

-- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Rich Freeman]

On Sat, Mar 23, 2013 at 4:13 PM, James Cloos <cloos@jhcloos.com> wrote:
> Again, that is an irresponsible mistake.  It is better to just leave it
> as is than to kick it.  Dropping important packages can only harm the
> community and is never welcome.

Is this package working in the typical case?  That is, when you aren't
intentionally trying to buffer-overflow it or otherwise break it?  I
did read the bugs but they don't really indicate the extent of the
problem.

Rich

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Alec Warner]

On Sat, Mar 23, 2013 at 1:13 PM, James Cloos <cloos@jhcloos.com> wrote:
>>>>>> "MC" == Markos Chandras <hwoarang@gentoo.org> writes:
>
> MC> Please do not reply to gentoo-dev-announce.
>
> I didn't.  I explicitly replied to the message in gentoo-dev.  If doing
> that resulted in a cc to announce that means there was no reply-to
> header in the message posted to dev.  Had there been a reply-to header
> gnus would have asked me whether to accept it.
>
> MC> The package is going away unless someone fixes the bugs and properly
> MC> maintains the package
>
> Again, that is an irresponsible mistake.  It is better to just leave it
> as is than to kick it.  Dropping important packages can only harm the
> community and is never welcome.

Nothing stops you from becoming a dev and maintaining it...

-A

>
> -JimC
> --
> James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6
>

Re: [gentoo-dev] Last rites: app-text/cuneiform

[James Cloos]

>>>>> "RF" == Rich Freeman <rich0@gentoo.org> writes:

RF> Is this package working in the typical case?  That is, when you aren't
RF> intentionally trying to buffer-overflow it or otherwise break it?

I haven't found an image file which causes it to crash.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Róbert Čerňanský]

On Sat, 23 Mar 2013 16:13:07 -0400
James Cloos <cloos@jhcloos.com> wrote:

> >>>>> "MC" == Markos Chandras <hwoarang@gentoo.org> writes:
> 
> MC> The package is going away unless someone fixes the bugs and
> MC> properly maintains the package
> 
> Again, that is an irresponsible mistake.  It is better to just leave
> it as is than to kick it.  Dropping important packages can only harm
> the community and is never welcome.

And that is why I now appeal to users:

  _Do not report bugs to Gentoo unless a package is completely broken._

Because what you will get in return?  Package removed.

A package with bugs has a greater user value than no package at all.
Until Gentoo does not understands that and does not change its removal
policy accordingly, and provides technical means to reflect it*, it is
the only user-viable** way how to keep a package in the tree as long as
possible.

* Which could be e. g. masking a package until it is completely
  broken.

** No, I do not want to become a developer.  No, I do not want to
   maintain a package.  I am the user, I want using it.  (It does not
   mean that I do not contribute to the community, I just have other
   ways/projects to do so.)

Robert


-- 
Róbert Čerňanský
E-mail: openhs@tightmail.com
Jabber: hs@jabber.sk

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Rich Freeman]

On Sat, Mar 23, 2013 at 5:40 PM, James Cloos <cloos@jhcloos.com> wrote:
>>>>>> "RF" == Rich Freeman <rich0@gentoo.org> writes:
>
> RF> Is this package working in the typical case?  That is, when you aren't
> RF> intentionally trying to buffer-overflow it or otherwise break it?
>
> I haven't found an image file which causes it to crash.

Seems like a compelling case to keep it around - works for me as well.

I'm taking over maintainership.  I'll leave it masked until the buffer
overflows are cleaned up (with an appropriate mask comment so users
can make an informed decision about using it).  The package will not
be removed in 30 days, however.

Rich

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 03/24/2013 09:15 AM, Róbert Čerňanský wrote:
> On Sat, 23 Mar 2013 16:13:07 -0400 James Cloos <cloos@jhcloos.com>
>  wrote:
> 
>>>>>>> "MC" == Markos Chandras <hwoarang@gentoo.org> writes:
>> 
>> MC> The package is going away unless someone fixes the bugs and 
>> MC> properly maintains the package
>> 

I am replying to your email (and NOT to you because it happens to be
the last one on the thread and because what you said is just an
immature flamebait. We already have enough of these so don't bother
sending yours as well).

So per https://bugs.gentoo.org/show_bug.cgi?id=462366#c4, the package
now has a new maintainer so it will not be removed.
See? This is what I call a good solution instead of going around and
constantly saying "Ohhh bad bad Gentoo removes awesome packages"

Thanks Rich.

- -- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQJ8BAEBCgBmBQJRTti1XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw
OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun88FyMP/Aslg1c43TeHqBDg4/Vswdni
rrLinbSsfi15gSk4UcBlKkYmE6f/XRmNvxt1cpf+M2X2iPakXKtnCT+Hw3Uuhy4H
rYJ3pjdeB+chyduikscW3Px1fDfrYMvF8nPcXBp4KJzDUvoZUxBG8LWc1Y9mvxxb
9/wYBncLHsUC8qt38UwmwSPzn9/ue37jtO+bf8KKlrF+5498d33LdVWqY38/p+hE
cPdKKaGGsdgK9vU6toRpPEst6kfPAlGSAlkFgSU9MCzulAHn3nmEtRqx+DyJlm7X
rXFyciqYqlnxs2xZLbU7x3sZoqftSX0vlpVCPHpunVpshS3jaitjBXYVwUe3SRFb
7SuNh1q9FHbS/UFaRkotR8FznNYQq48QftrzdCyezYaJDT+Fm+o3ED9jn/+m6OQ3
bmjBWsMkEOA/COV7SxU+6+4a6gBh+if2XDkdAB6Te1cbLx6rop/L0vcxELvbempF
sPNbeRuGPhtMES6VsyVbJKzmBGSHgIV2OJOwcGR2x3x26HXM27D/dQzuKpbV1xqH
Sj6uvuEsUaxGH+efx9IANPUbNxnM2TpZ2lFaKgjm9Nb127WJn6CWiaWKyM/ypyjW
8Vo0JjKWEEnIruBa3CBa3EJOXyYU7ipUInxrXwbAU9+WH52xlS7nqHT2aczSMvaI
ctKIrqpE52M2KvnWO1bt
=MNLe
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Rich Freeman]

On Sun, Mar 24, 2013 at 6:43 AM, Markos Chandras <hwoarang@gentoo.org> wrote:
> So per https://bugs.gentoo.org/show_bug.cgi?id=462366#c4, the package
> now has a new maintainer so it will not be removed.
> See? This is what I call a good solution instead of going around and
> constantly saying "Ohhh bad bad Gentoo removes awesome packages"

Probably worth noting that the real problem for packages like these is
a barely-existent upstream.  If a package is really important to you
it behooves you to try to support upstream however you can.

I've yet to really dig into the issues with this package, but some of
the Gentoo bugs refer to working implementations in other distros or
upstream filed patches that apparently aren't in the repository yet.
These are really upstream issues.

So, while cuneiform has a lease on life in Gentoo, it is really just a
matter of time before some big dependency change kills it for good if
upstream doesn't pick up momentum.  I don't mind maintaining an odd
patch or two, but there is no way something like this is going to stay
in the tree if it ends up becoming a blocker for some big toolchain
upgrade (unless the fix is trivial).

So, if you find this package really useful consider this whole thread
as a warning.  I don't personally use it, but I think that this
package isn't quite at the point of no return and at least some appear
to be passionate about it so I'm willing to buy them some time.  If it
does reach that point, then I'll put out a call for maintainers (proxy
or otherwise) and put it down myself if there is no response to save
treecleaners the duplicate effort.  If you aren't interested in
developing then offer donations to upstream, or do something to
revitalize the project.  It isn't a lost cause - YET.

On a side note, if you use this instead of tesseract I'd be interested
in hearing about why (off list).  In my very limited tests tesseract
seems to perform better.  The cuneiform community (what little there
is) would do well to understand their niche and exploit it, or
influence healthier projects to address their needs.

Markos - I'm not sure what can be done to try to better flush out user
interest in taking care of packages that are on the verge of death.
I'd suggest announcing pending removals before masking them, but I
suspect that more often than not the only reason we get replies on
-dev is that users notice the masks.  Maybe the package masks could
have a webpage explaining how users can help rescue packages
constructively, and include a link to it in mask notices.  Since I've
tended to be an advocate for not masking as quickly I might go ahead
and toss something together.

Rich

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 03/24/2013 11:22 AM, Rich Freeman wrote:
> 
> Markos - I'm not sure what can be done to try to better flush out
> user interest in taking care of packages that are on the verge of
> death. I'd suggest announcing pending removals before masking them,
> but I suspect that more often than not the only reason we get
> replies on -dev is that users notice the masks.  Maybe the package
> masks could have a webpage explaining how users can help rescue
> packages constructively, and include a link to it in mask notices.
> Since I've tended to be an advocate for not masking as quickly I
> might go ahead and toss something together.
> 
> Rich
> 
The masks are sort of announcements as you have 30 days to revert that
decision. Users who have that package installed, will get the message
after the emerge --sync && emerge -uDN world cycle. If they sync less
often (say once every 2 months) and not following any ML, then what
can I do? The process for rescuing a package is documented here[1] and
it takes about 15'' of google searching to find it.

[1] http://www.gentoo.org/proj/en/qa/treecleaners/index.xml#doc_chap7

- -- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQJ8BAEBCgBmBQJRTu14XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw
OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun88GI4QAKOzmCub0h0fstxDPDpMYp0k
kufGTfBjaufOkv4DYY7h/h/WkMQCjqMupq7vEO76S0Bf8tpqg1So6UwPW2ac1YUy
nmqVESresiHnsUHNEHTupUE+A055rohwEaOh4CBjbAYxtplZ8SlvRmRcS2F+xVcB
fhcROxyz3UFqKn9ZX9p1k9WTlEA/xI4lXeCDigBA1qSG/JmYjw9Bx/KRwEFJU6yl
hYozqNcvCkqyKVeYYP8sS1TK9wceO5Eim1sDTd4YzM7PMq2zTSfr6hGvaKBZC29i
LUW4rE3+fNMSr3x2Waqvjyu2RoyJLu0qpo4cxB8otesiHdg9ZgQ160sJ86+sBrZg
4BadUYYqQKm+L3Pa4PuRulh18Q+BPnneLSA4B//eJvH2dKvzwaY9GIsXWvJJ77YN
R3ysO/Ne+AzGhahs6JaMZJaaq9qxdiSeBXVasphdW47NNzS9L54usTeOdawHGAs/
bKYVr6Bo1qDr3KKWaoXmTQ+E85vC9LqYxdRsfEb+9AE8+8rO+NE0hFwhM75Yw4Gw
U1clcv3PEuhI3P+7VttHHz5ftL0XMMNHx43vF/tXiymGFFPRIOQCXq5r8xRFnNaX
ggqFPc7fzH/SqxzUpPWsZOhvUr5nHUjVbLVMWA/DULp5+Rikl++CoM/e42nH5111
gD8RNXAvntVEj2hc8+XB
=GTZy
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Rich Freeman]

On Sun, Mar 24, 2013 at 8:11 AM, Markos Chandras <hwoarang@gentoo.org> wrote:
> The process for rescuing a package is documented here[1] and
> it takes about 15'' of google searching to find it.
>

I think that something a bit more elaborate with links to the relevant
pages (proxy-maint, etc) that is more user-oriented might help with
that.  I'd also suggest putting the link in every package mask notice.
 Hopefully then users will read the link before they reply on the
list, and we can perhaps make treecleaning a more positive experience
all around.

I'll take a pass at tossing something together and we can see if it
makes sense.  I'm trying to be constructive about this, and I've made
a new-years resolution to stop arguing about hypotheticals and offer
improvements before criticism.  (FYI - anybody on the list is willing
to send me a note off-list if you catch me breaking my resolution.)

> [1] http://www.gentoo.org/proj/en/qa/treecleaners/index.xml#doc_chap7

Rich

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 03/24/2013 12:18 PM, Rich Freeman wrote:
> On Sun, Mar 24, 2013 at 8:11 AM, Markos Chandras
> <hwoarang@gentoo.org> wrote:
>> The process for rescuing a package is documented here[1] and it
>> takes about 15'' of google searching to find it.
>> 
> 
> I think that something a bit more elaborate with links to the
> relevant pages (proxy-maint, etc) that is more user-oriented might
> help with that.  I'd also suggest putting the link in every package
> mask notice. Hopefully then users will read the link before they
> reply on the list, and we can perhaps make treecleaning a more
> positive experience all around.

I don't mind adding that link to every package mask. Do note thought
that this is not the only way for a package to be rescued (assuming it
can be rescued). Providing fixes without becoming the maintainer is
also a viable solution, which is probably something we need to add to
that page as well.

- -- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQJ8BAEBCgBmBQJRTvIwXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw
OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun88nWIP/21v/4FTP1npzjrntt7ttw7v
wAzOmd5MHutlOUvCGfecbv+VCLbTdYMRNGG8Mwp8RSCTtZM/gIR6fMefOdz/i7Ac
zCKyhmIjSLE1lKojWnyre9Lh2tMGScmqmOirNi/GAFc7GI1/3fe8qMCwxgLfw5xI
RPOOXPebLy9QXuQV3KNZ0qepVm+YmwyqTFeExaSkGg3ofbIi7gjfvTGly64uyRei
8itW8V8fd+E5suOLJpYUbvrlP/zb6o5sGNQHxPuIwMxrN0/MYX2coQiDQ8deQ34m
f53OjYs+Jg6IiA+XfDhoAAeQXlV6zOpfkdKN62oIf+QUpaOWp69U369sPXLoZGt4
VjSTlgu1dA+ZGUc7GXEuIcXUtDR5KEoQY9ajXdDiMbv91P9DXvC0QlJc8eaJpcqS
vu1on4hF3qJqzdE16hUYlaoSw+oPlD32JefVHi3Q40mGd5mK+JUDOUykkL7R6piI
IsZDdqci0iIijqJWLHAT/7l+KuK4imKwDkAYXCkycvEQRD6yAWtYHE6mWQ2stuXr
In1Y4geagYEYr4UfewZt8XLdjd5v3+fBrhjhUpLFCeB0xEfFnjK9cK7xYshcMXEA
JCZRRtd4InCRg1/7ewOve0vEprMUzf9Wqm8caVSk3sWk0+cU324qyLF9m1m7SwWm
HOWYld71/yIL6W91Pyia
=4VIp
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Rich Freeman]

On Sun, Mar 24, 2013 at 8:31 AM, Markos Chandras <hwoarang@gentoo.org> wrote:
> I don't mind adding that link to every package mask. Do note thought
> that this is not the only way for a package to be rescued (assuming it
> can be rescued). Providing fixes without becoming the maintainer is
> also a viable solution, which is probably something we need to add to
> that page as well.

I started something at:
http://dev.gentoo.org/~rich0/treeclean.txt

It needs some work, and guidexmlification.  However, I tried to hit
some of the alternatives.

I'd like to work on this a bit more to try to urge people to make more
lasting contributions.  Most Gentoo users are sufficiently capable
that they could make real contributions to the distro.  Sure, not
everybody is an expert at everything, but the proxy maintainer project
has been more active than it ever has been so now is a good time for
users to step up and pitch in where they can.  Maybe they can't save
their own favorite package, but they might be able to save somebody
else's, and vice-versa.

Sure, moving to git or gerrit or whatever will make it even easier to
contribute, but the fact is that simply implementing technology
doesn't make up for the fact that somebody still needs to write the
patches.

Rich

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Sergei Trofimovich]

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

On Sat, 23 Mar 2013 17:40:37 -0400
James Cloos <cloos@jhcloos.com> wrote:

> >>>>> "RF" == Rich Freeman <rich0@gentoo.org> writes:
> 
> RF> Is this package working in the typical case?  That is, when you aren't
> RF> intentionally trying to buffer-overflow it or otherwise break it?
> 
> I haven't found an image file which causes it to crash.

There is at least one I have seen dying:
https://bugs.launchpad.net/cuneiform-linux/+bug/1069657

-- 

  Sergei

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

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Peter Stuge]

Alec Warner wrote:
> > MC> The package is going away unless someone fixes the bugs and
> > MC> properly maintains the package
> >
> > Again, that is an irresponsible mistake.  It is better to just leave it
> > as is than to kick it.  Dropping important packages can only harm the
> > community and is never welcome.
> 
> Nothing stops you from becoming a dev and maintaining it...

I find the become-a-dev threshold significant so yes, something stops it..


//Peter

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Rich Freeman]

On Sun, Mar 24, 2013 at 9:24 AM, Peter Stuge <peter@stuge.se> wrote:
>
> I find the become-a-dev threshold significant so yes, something stops it..
>

So, my personal feeling is that /some/ packages get pulled a little
earlier than strictly necessary.  However, the fact is that when a
package gets treecleaned it is a symptom of a bigger problem.  Could
some packages stay in the tree an extra six months?  That's debatable.
 However, it doesn't really change the fact that in almost all of
these cases something is bound to break for good sooner or later if
things don't change.

In this particular case upstream is the main problem - it needs to
exist for starters (it looks like there is some interest in making
this move forward, but C++ expertise or not the maintainer needs to at
least start committing some of the known patches after testing them).

The only thing I've really done for cuneiform is buy it time.  I'll
give it best-effort and will genuinely try to fix bugs where able, but
it isn't like I get paid to use this package in my day job.  The mask
takes some of the edge off of the potential security concerns, but
sooner or later if upstream doesn't start moving forward they're going
to get stuck on some outdated version of some dependency and lead to
more serious QA violations.  If people really care about packages they
have to do something about it.  That's basically how FOSS works - you
get all this software for free, but it doesn't mean that it was
without cost to create it, and for the most part when things break you
get to keep the pieces.

If your goal is to have more packages in the tree then simply delaying
the inevitable won't really accomplish that.

Rich

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Peter Stuge]

Markos Chandras wrote:
> The masks are sort of announcements as you have 30 days to revert that
> decision.

You don't seem to recognize the quite significant psychological
impact of you having already made the decision, compared to, say,
having an actually inclusive package removal process.

Bugzilla does not count as inclusive in this case.

I mean something like a process where users who have this package
installed are notified about the change in status, as opposed to
having to monitor a developer mailing list or portage.mask in order
to get those news. It would probably be a part of emerge --sync.

I think that might do far more good than any web page.

You might argue that such a thing is completely outside your
department, but please consider that what you do can't be seen
in isolation, because users don't care at all about the isolated
particulars which result in their package being masked and cleaned,
they just see that the package is gone one day. You should care
because what you do is the trigger for that user experience.

Improving UX should be your priority too, even if it isn't formally
part of what you do. (Should be everyone's priority.)


//Peter

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Rich Freeman]

On Sun, Mar 24, 2013 at 9:40 AM, Peter Stuge <peter@stuge.se> wrote:
> You don't seem to recognize the quite significant psychological
> impact of you having already made the decision, compared to, say,
> having an actually inclusive package removal process.

I was going to post something along these lines, but I'm struggling to
come up with something that would actually be a better system in
practice.

The notice in the mask appears the next time you run emerge, which is
about as good as it gets in terms of making users aware.  Markos is
open to including a URL in this annoucement which offers advice to
those affected.  That might take some of the edge off.

I'm not sure I see a lot of alternatives.  We could announce them on
-dev, but I don't know that it would cause many to show up.  It might
be worth doing if it saves the treecleaners churn in the event that
somebody does step up (no need to touch portage only to have somebody
else revert the changes).

If somebody has ideas on better ways to communicate pending removals
speak up, but do keep in mind that it won't do any good if nobody
notices them until the mask comes.

Rich

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Peter Stuge]

Rich Freeman wrote:
> something is bound to break for good sooner or later if things don't change.

Certainly.

But consider the chain of events:

* user is happily using outdated, but working, software without
  knowing how behind the times upstream really is, because it works
* gentoo masks and removes package

That looks bad.

Masking is a quite invasive UX. It makes a package unavailable by
default *before* the package actually stops working.

Users who want to fix the problem need to get involved upstream,
there is no disagreement about that, but users who have already
gotten a package masked by the powers that be are vastly less
motivated to do so, because the package has already been masked.

Masking communicates that a decision to treeclean has been made.

Masking is not at all communicating an opportunity to address the
perceived problems. That should be done in a different way.

A per-ebuild bug metric would be cool. A kind of health indicator
for individual ebuilds, alerting users when some of our installed
ebuilds go yellow, so that we have perhaps on the order of six
months before the package goes red, at which point it would be fine
to mask at will. Does that make sense? (Obviously how many months
yellow is depends on what else happens in the tree. It's a ballpark
figure.)


//Peter

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Rich Freeman]

On Sun, Mar 24, 2013 at 9:52 AM, Peter Stuge <peter@stuge.se> wrote:
> A per-ebuild bug metric would be cool. A kind of health indicator
> for individual ebuilds, alerting users when some of our installed
> ebuilds go yellow, so that we have perhaps on the order of six
> months before the package goes red, at which point it would be fine
> to mask at will. Does that make sense?

And how would users actually be alerted?

Seems like a potentially interesting GCOC project, but somebody does
need to actually implement this for it to be useful...

Rich

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Alan McKinnon]

On 24/03/2013 15:40, Peter Stuge wrote:
> Markos Chandras wrote:
>> The masks are sort of announcements as you have 30 days to revert that
>> decision.
> 
> You don't seem to recognize the quite significant psychological
> impact of you having already made the decision, compared to, say,
> having an actually inclusive package removal process.
> 
> Bugzilla does not count as inclusive in this case.
> 
> I mean something like a process where users who have this package
> installed are notified about the change in status, as opposed to
> having to monitor a developer mailing list or portage.mask in order
> to get those news. It would probably be a part of emerge --sync.
> 
> I think that might do far more good than any web page.
> 
> You might argue that such a thing is completely outside your
> department, but please consider that what you do can't be seen
> in isolation, because users don't care at all about the isolated
> particulars which result in their package being masked and cleaned,
> they just see that the package is gone one day. You should care
> because what you do is the trigger for that user experience.
> 
> Improving UX should be your priority too, even if it isn't formally
> part of what you do. (Should be everyone's priority.)

We have 5 "statuses" for packages

- stable
- unstable
- masked by no keyword
- hard masked
- gone

You are proposing one more:

- stable
- unstable
- masked by no keyword
- candidate for hard mask
- hard masked
- gone

I see that as pointless, the extra category buys you nothing (except as
one more thing users can ignore). Even if you prompt the user during
emerge to accept the candidate packages after reading the reason, you
have not actually done anything different from hard masking it. The
effect is the same - the user tweaks the system to allow the package to
be emerged, user gets on with life. And one day the package is gone.

Masking already accomplishes everything you propose, which is to
communicate "there is something wrong with this package and it is in
danger of leaving the tree. To get it out of this state, you need to
take action".

As for what constitutes "take action", well that is highly variable and
isn't something that easily submits to categorization. Better to give
the reason in a plain text comment with a link where interested users
can go to start the rescue process.

You also didn't give any examples of how "inclusive" could work.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Peter Stuge]

Rich Freeman wrote:
> > A per-ebuild bug metric would be cool. A kind of health indicator
> > for individual ebuilds, alerting users when some of our installed
> > ebuilds go yellow, so that we have perhaps on the order of six
> > months before the package goes red, at which point it would be fine
> > to mask at will. Does that make sense?
> 
> And how would users actually be alerted?

The when I think is after emerge --sync.

The how may not be as easy. :)

Maybe the bug metric can be added into portage easily enough,
allowing it to be transfered as part of sync. I think that would be
ideal.


> Seems like a potentially interesting GCOC project, but somebody
> does need to actually implement this for it to be useful...

Sure, but an idea of what to accomplish is a good start.


//Peter

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 03/24/2013 12:40 PM, Rich Freeman wrote:
> On Sun, Mar 24, 2013 at 8:31 AM, Markos Chandras
> <hwoarang@gentoo.org> wrote:
>> I don't mind adding that link to every package mask. Do note
>> thought that this is not the only way for a package to be rescued
>> (assuming it can be rescued). Providing fixes without becoming
>> the maintainer is also a viable solution, which is probably
>> something we need to add to that page as well.
> 
> I started something at: http://dev.gentoo.org/~rich0/treeclean.txt
> 
> It needs some work, and guidexmlification.  However, I tried to
> hit some of the alternatives.

I don't think we need to create a new page for that. Just put all this
text into the treecleaners page.

- -- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQJ8BAEBCgBmBQJRTxIrXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw
OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun88TKkP/iedzUIxUTJ+r0i+xNhRjX5D
khIPiia8cwc1QjvRZgBrjoh9C7Cv8WPMnca9ryJwm1CaLgmCX+g+4a6laLavq2cY
lRiCcZgA9L7xWirJQsA8GZRxoWkJP9wCP3cG3X1IDwXwIPUiTe3Ecx3q2QIChQ/+
leNh5T65T+9Yw2BbUptXWGkQVPA83klNC0IaUYJbU+E5E4gbQWjljSZlBV6XRZDx
DRy0GAhRKZThPDYVk6ri3Ove0yPAMUY58u5Dm/7P3R5dPZ6zBLeX1B7y+SVIlYAJ
Jx08m9FTZXk+EGvvoCGSoTihZW7GGCm/EiJb3vtNRImjodmg7DdbOjh/wLYfkSgN
9Dul015p3yZ763INvqGgQ8dbHDXWEKNRc2QoJq4Dee5Fr9ALvvYlSNvH9hstrjfH
/9DU2s1zZH8sdPtC8FoOUoR1uOb98KGsR0teQpaVw/ulLKHNN1iEl7S6+Hx9XEn8
eXJybi76F5eUsykdgR0rlINeQGEizSNhb1gJPPbf/yBzNWEnXrT+lrmPi7I0afEx
ApY6rZjIJRgt9eeDW0hyy89Do0LouyWU8erQfQwQTKZdxQSE+RRpqs2Benjnh2mT
lfRMWXL04TdCuovdkMQT+MVevVAU0JKPa2pctUhYFzZN55iRk4/tFe8xNxc0YENi
7pcqQwTv0BD8eCGRspGR
=RLUH
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Peter Stuge]

Alan McKinnon wrote:
> Masking already accomplishes everything you propose, which is to
> communicate "there is something wrong with this package and it is in
> danger of leaving the tree. To get it out of this state, you need to
> take action".

I disagree strongly that this is what masking communicates,
specifically the words "is in danger of leaving."

Masking is the result of a developer decision and is something users
are unable to influence, because the decision has already been made.

When the decision has been made the package isn't in danger of
leaving the tree anymore, it has been decided that the package *will*
leave the tree. I consider the difference to be significant.


The way I see it, every ebuild is in danger of leaving the tree.

Masking is the next step, and means that a developer has decided that
now (soon) is the time for that package to go.

As Rich mentioned, sometimes this happens too quickly or on wrong
grounds. Most of the time not, but the sometimes is still a problem,
and in general I think it would be cool to make bugs more visible.

I think there are other Gentoo users like myself, who are able to fix
broken things that they care about. We don't use bugzilla unless we
are reporting bugs however, because since fixes don't go into portage
anyway there is little motivation.

I fix what I need for myself and push fixes into my overlay, and
usually I document both bugs and their fixes in bugzilla. The common
case, in my experience, is that *nothing* further happens.

Bugzilla is very much write-only for us users, but at the same time
it has valuable information for upstream, and I think the bug metric
would be a good way to push knowledge in bugzilla onto users, so that
we can engage upstream early and make a difference for Gentoo without
first needing to play through the recruitment game.


//Peter

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 03/24/2013 01:52 PM, Peter Stuge wrote:
> Users who want to fix the problem need to get involved upstream, 
> there is no disagreement about that, but users who have already 
> gotten a package masked by the powers that be are vastly less 
> motivated to do so, because the package has already been masked.

Mask != removed.

> 
> Masking communicates that a decision to treeclean has been made.
That's your opinion. The masked message says "removal in 30 days"
meaning something can change in these 30 days. If you want me to write
an essay on every package.mask, sorry it's not going to happen. Deal
with it.

> 
> Masking is not at all communicating an opportunity to address the 
> perceived problems. That should be done in a different way.

The masked message says why the package is removed. So fixed the
aforementioned bugs and the package will stay.

> 
> A per-ebuild bug metric would be cool. A kind of health indicator 
> for individual ebuilds, alerting users when some of our installed 
> ebuilds go yellow, so that we have perhaps on the order of six 
> months before the package goes red, at which point it would be
> fine to mask at will. Does that make sense? (Obviously how many
> months yellow is depends on what else happens in the tree. It's a
> ballpark figure.)
> 

No we don't have the human resources to do that.

- -- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQJ8BAEBCgBmBQJRTxO8XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw
OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun88vVoQAMA+kDYRiVkQG29u59ZT3+rT
O7KXcDuf6WuesrFG+HoTSQoSyJV59axY+ynA/MB0LXUZnjgATigRXd6mn1B88eFn
E0rZfC9oLzqMwfNoKYNpk/a0gz57CzV5+lT2Ta7cgwiU+h4EUxXNSOovfqINj990
sDu0Djl/RGNMYrbgYSc/Myck2oyi//Jv/ky9jnC0p3vNWcq05QaBSym05Wgd1NNP
pKxx7U/EFIXAccQsuvMCDxPPy42kcTVNYA365C19WGLMYPARiKJP5TiZvsW9IhxN
NYzanKjzNVjQLeHiYuJR4mP+XVI1Q4NusnByX9fzwAeBN6t74vgLh0SDUBd/qtk/
7nQltBIo6JbBzaFWzZ+a93ACrgI9Y/T1NbAedI1n7mnXUwHvKjBQ1LbtOvAqZzAD
/FEszsePexlvQop1Zz5BBfsr0Fgxn+uP3TSJ4FVmBUprxincqkydMj3l33fZo5aq
AIKINzDTiGpV7ZBw0VGHaQR8+ofqKDVkB0+nZBqJrMErl4BjjWH9KMZGVTZqiaeK
n6rY4/FEQDQ7xO3lsea9rfebDRTt6alkyVF+MNlQqCEhnCnFpx7CJjip375l0n/z
/T6u8lQ4tQieqECisJEXdSUwt5m9I6csaio8AOMeDOE5ewWflahFvJKcFe1qjIYe
XA1nLSM8wH9uQEPchpu8
=kDjx
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Peter Stuge]

Markos Chandras wrote:
> > A per-ebuild bug metric would be cool. A kind of health indicator 
> > for individual ebuilds, alerting users when some of our installed 
> > ebuilds go yellow, so that we have perhaps on the order of six 
> > months before the package goes red, at which point it would be
> > fine to mask at will. Does that make sense? (Obviously how many
> > months yellow is depends on what else happens in the tree. It's a
> > ballpark figure.)
> 
> No we don't have the human resources to do that.

Ah, no, it must be automated. Of course the metric would be
accordingly "stupid" but it would still be way more informative
than no metric at all.

I think a GSOC project is a good fit, unless of course a developer
likes to run with the idea. In any case, yes, people are needed to
do development, but working out an idea is a good start.


//Peter

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Róbert Čerňanský]

On Sun, 24 Mar 2013 08:40:17 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Sun, Mar 24, 2013 at 8:31 AM, Markos Chandras
> <hwoarang@gentoo.org> wrote:
> > I don't mind adding that link to every package mask. Do note thought
> > that this is not the only way for a package to be rescued (assuming
> > it can be rescued). Providing fixes without becoming the maintainer
> > is also a viable solution, which is probably something we need to
> > add to that page as well.
> 
> I started something at:
> http://dev.gentoo.org/~rich0/treeclean.txt

It is relief to see that someone is trying to listen and do something
constructive about this long standing problem.  However, with all due
respect, I do not think that the document will help very much.  I
think most users are aware of the possibilities they have to save a
package.  They just do not have will, time or priority to do so for a
particular package they are using (this fact is essential to accept in
order to understand the problem here).

What I have expressed in rather theatrical way in my previous mail, is
the fact that unresolved bugs contributes to the package removal.
This may lead to _not_ reporting a bugs on purpose in order to lower
the possibility that the package will be removed.  I may say that I am
afraid to submit a bug for some packages and for some cases I
willingly do not report any for the very same reason.  Sad but true.

How it can be mitigated?  In my opinion by applying 30 days removal
policy only to packages that are completely broken.  So packages that
-- according to current policy -- would have been 30d masked for
removal, would be _just masked_ (no 30d removal).  This has following
advantages:

1. Users can submit as many bugs as they want without being afraid
   that it will contribute to removal of the package.  Documented bugs
   are better than hidden bugs.

2. Users can still use the package while being aware that it is
   partially broken.  They can find known bugs in bugzilla.

3. Users can still submit new bugs or workarounds to existing bugs.

4. Users can submit patches, effectively maintain the package even no
   official proxy maintainer was established.  (If from time to time
   some dev would bring provided patches to the tree, even better.)

5. Since the mask period will be likely longer than 30d there is a
   bigger chance that someone will take proxy/maintainership, or that
   someone will submit provided patches to the upstream.  Even users
   or devs that usually do not have will, time or priority to take
   care of the particular package could find some -- e. g. during
   summer or so -- and provide a patch.

During the mask period Gentoo will basically be providing just the
infrastructure.

Sorry that I am addressing the policy here even you explicitly said in
the document not to do so.  I will not make this post longer than it
is in trying to explain why I am doing it.  I just hope you (and other
devs) will try to listen.

Robert


-- 
Róbert Čerňanský
E-mail: openhs@tightmail.com
Jabber: hs@jabber.sk

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 24/03/13 11:19 AM, Peter Stuge wrote:
> Markos Chandras wrote:
>>> A per-ebuild bug metric would be cool. A kind of health
>>> indicator for individual ebuilds, alerting users when some of
>>> our installed ebuilds go yellow, so that we have perhaps on the
>>> order of six months before the package goes red, at which point
>>> it would be fine to mask at will. Does that make sense?
>>> (Obviously how many months yellow is depends on what else
>>> happens in the tree. It's a ballpark figure.)
>> 
>> No we don't have the human resources to do that.
> 
> Ah, no, it must be automated. Of course the metric would be 
> accordingly "stupid" but it would still be way more informative 
> than no metric at all.
> 
> I think a GSOC project is a good fit, unless of course a developer 
> likes to run with the idea. In any case, yes, people are needed to 
> do development, but working out an idea is a good start.
> 
> 
> //Peter
> 

The idea may have some merit in general, but I think it will be rather
difficult to implement anything for this in practice, simply because
there is no metrics that I can think of that would be of use for this
that isn't going to require a lot of per-bug flagging of some sort by
humans.

The number of open bugs doesn't really matter, it's what those bugs
are that matters -- security bugs, sure, are of a higher priority and
can be fairly easily detected in bugzilla.  Possibly, bugs that block
a STABLEREQ bug would work, but I think we don't mark stablereq on
these bugs until the blockers are resolved and so that isn't going to
be easy to find either outside of matching 'stabilize' in bug
summaries.  We generally discourage the use/filing of 'version-bump'
bugs, so that doesn't work so much -- euscan helps here, of course,
since it already works well to determine out-of-date packages, but for
packages with a mostly-dead but still existing upstream, not a whole
lot can be reported.

Of course, I look forward to being proven wrong, but at this point I
just can't picture what one would go by to trigger the report of a
yellow-package status before it goes red (where red = p.mask).


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlFPUv4ACgkQ2ugaI38ACPC+6gEAqbe9woyvgLMUsd4SbqDszmJI
xorLFSMAJFtxK4pyXAQA/RIE1ckYa+46/Fq8huo64oTZz7K2xUf0aKEsCG+5HpHR
=Dw8R
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Rich Freeman]

On Sun, Mar 24, 2013 at 3:24 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
> The number of open bugs doesn't really matter, it's what those bugs
> are that matters -- security bugs, sure, are of a higher priority and
> can be fairly easily detected in bugzilla.

Well, our current treecleaner policy seems to be that if a package
isn't maintained and has any bugs open at all it is fair game.  The
caveat to that is that trivial bugs are grounds for fixing instead of
removals (bad DEPEND atoms, simple-to-fix, etc).  Google the full
policy for details.

I think that a better policy would be rather than having any open
non-trivial bugs we list the sorts of bugs that should be grounds for
removal, such as:

1.  Package does not build in the majority of cases on all archs.
(Unkeywording is the solution for individual archs that are broken, if
not easily fixable.  Not building some of the time isn't grounds for
removal.)

2.  Package has an open security bug.  (Cuneiform is a borderline case
of this - no exploit/CVE but I wouldn't use it on a server being fed
images submitted by strangers.)

3.  Package is blocking another package.  Maintained packages always
take priority over unmaintained ones.

Perhaps there are other cases which should be included, but I think
this covers most of them.  If a package isn't blocking anything else,
doesn't have security problems, and works most of the time, then I
think it should generally be kept.

Rich

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Patrick Lauer]

On 03/24/2013 09:40 PM, Peter Stuge wrote:
> Markos Chandras wrote:
>> The masks are sort of announcements as you have 30 days to revert that
>> decision.
> 
> You don't seem to recognize the quite significant psychological
> impact of you having already made the decision, compared to, say,
> having an actually inclusive package removal process.

If the package has been "rotting away" with open bugs in bugzilla for
weeks or months and no one cares ... what are we supposed to do? Wait a
bit longer?

> 
> Improving UX should be your priority too, even if it isn't formally
> part of what you do. (Should be everyone's priority.)

Stop whining, get cracking.

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Rich Freeman]

On Sun, Mar 24, 2013 at 8:23 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> On 03/24/2013 09:40 PM, Peter Stuge wrote:
>> Markos Chandras wrote:
>>> The masks are sort of announcements as you have 30 days to revert that
>>> decision.
>>
>> You don't seem to recognize the quite significant psychological
>> impact of you having already made the decision, compared to, say,
>> having an actually inclusive package removal process.
>
> If the package has been "rotting away" with open bugs in bugzilla for
> weeks or months and no one cares ... what are we supposed to do? Wait a
> bit longer?

I suspect the concern is over the definition of "rotting away."  Just
about every package in the tree has had open bugs for weeks and
months.  Not all bugs are worth fixing right away, but that doesn't
mean they aren't valid.  When they can be fixed, they are.

Packages without bugs are packages that nobody has bothered to test...  :)

Rich

[gentoo-dev] Re: Last rites: app-text/cuneiform

[Duncan]

Rich Freeman posted on Sun, 24 Mar 2013 20:26:03 -0400 as excerpted:

> Packages without bugs are packages that nobody has bothered to test... 
> :)

LWN distro page QotW material. =:^)

-- 
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] Last rites: app-text/cuneiform

[Sergey Popov]

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

24.03.2013 13:15, Róbert Čerňanský пишет:
> And that is why I now appeal to users:
> 
>   _Do not report bugs to Gentoo unless a package is completely broken._
> 
> Because what you will get in return?  Package removed.

If package is broken, upstream is dead/unresponsive and nobody wants or
can fix it - yeah, it will be treecleaned. Sooner or later. Cause we
should keep some QA standarts that are expected by users.

> A package with bugs has a greater user value than no package at all.
> Until Gentoo does not understands that and does not change its removal
> policy accordingly, and provides technical means to reflect it*, it is
> the only user-viable** way how to keep a package in the tree as long as
> possible.
> 
> * Which could be e. g. masking a package until it is completely
>   broken.
> 
> ** No, I do not want to become a developer.  No, I do not want to
>    maintain a package.  I am the user, I want using it.  (It does not
>    mean that I do not contribute to the community, I just have other
>    ways/projects to do so.)

If you, as user, want to use package that does not fullfill minimum QA
requirements, nobody can stop your from installing it from your local
overlay. You can not rely on support through bugzilla from that moment,
but if package was removed because lack of maintainership it does not
matter, does not it?

Main tree is not place for dead AND(not or, and!) not working packages.

-- 
Best regards, Sergey Popov
Gentoo Linux Developer
Desktop-effects project lead


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

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Róbert Čerňanský]

On Sun, 24 Mar 2013 19:40:07 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Sun, Mar 24, 2013 at 3:24 PM, Ian Stakenvicius <axs@gentoo.org>
> wrote:
> > The number of open bugs doesn't really matter, it's what those bugs
> > are that matters -- security bugs, sure, are of a higher priority
> > and can be fairly easily detected in bugzilla.
> 
> Well, our current treecleaner policy seems to be that if a package
> isn't maintained and has any bugs open at all it is fair game.  The
> caveat to that is that trivial bugs are grounds for fixing instead of
> removals (bad DEPEND atoms, simple-to-fix, etc).  Google the full
> policy for details.
> 
> I think that a better policy would be rather than having any open
> non-trivial bugs we list the sorts of bugs that should be grounds for
> removal, such as:
> 
> 1.  Package does not build in the majority of cases on all archs.
> (Unkeywording is the solution for individual archs that are broken, if
> not easily fixable.  Not building some of the time isn't grounds for
> removal.)
> 
> 2.  Package has an open security bug.  (Cuneiform is a borderline case
> of this - no exploit/CVE but I wouldn't use it on a server being fed
> images submitted by strangers.)
> 
> 3.  Package is blocking another package.  Maintained packages always
> take priority over unmaintained ones.
> 
> Perhaps there are other cases which should be included, but I think
> this covers most of them.  If a package isn't blocking anything else,
> doesn't have security problems, and works most of the time, then I
> think it should generally be kept.

This souds very promising.  Could we leave out point 2 though?  Gentoo
puts lot of decision power to users.  Can it be so also in this case?
Users will have to be informed that the package has security issues of
course, for example, by mentioning it in the mask note.

Robert


-- 
Róbert Čerňanský
E-mail: openhs@tightmail.com
Jabber: hs@jabber.sk

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Róbert Čerňanský]

On Mon, 25 Mar 2013 08:23:31 +0800
Patrick Lauer <patrick@gentoo.org> wrote:

> On 03/24/2013 09:40 PM, Peter Stuge wrote:
> > Markos Chandras wrote:
> >> The masks are sort of announcements as you have 30 days to revert
> >> that decision.
> > 
> > You don't seem to recognize the quite significant psychological
> > impact of you having already made the decision, compared to, say,
> > having an actually inclusive package removal process.
> 
> If the package has been "rotting away" with open bugs in bugzilla for
> weeks or months and no one cares ... what are we supposed to do? Wait
> a bit longer?

In short, mask it, wait until it rots completely and _then_ apply 30 day
removal policy.  Unmask it, if it finds a maintainer and bugs are fixed.

Robert


-- 
Róbert Čerňanský
E-mail: openhs@tightmail.com
Jabber: hs@jabber.sk

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Alec Warner]

On Sun, Mar 24, 2013 at 4:40 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Sun, Mar 24, 2013 at 3:24 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
>> The number of open bugs doesn't really matter, it's what those bugs
>> are that matters -- security bugs, sure, are of a higher priority and
>> can be fairly easily detected in bugzilla.
>
> Well, our current treecleaner policy seems to be that if a package
> isn't maintained and has any bugs open at all it is fair game.  The
> caveat to that is that trivial bugs are grounds for fixing instead of
> removals (bad DEPEND atoms, simple-to-fix, etc).  Google the full
> policy for details.

So Treecleaners exists to do two jobs.

1) Keep the number of packages in the tree from growing out of
control. It is easier to add software to the tree than to remove it.
There is no policy for adding software to the tree (in terms of
minimum # of users, etc.) There is a policy for removal. Prior to the
policy being adopted, I would remove packages without notice (or
often, without masking.) This angered people, which is why the policy
was adopted; to inform users why a package was being removed, and what
they could do about it. This is why the masks exist at all.

2) Remove dead packages. This is perhaps the more hotly debated
section. My intention was not to remove packages that compiled and
worked, but had bugs. I think your statement about buggy packages is
apt. In many cases the target of TreeCleaners was portions of the tree
that were basically under-maintained and dead. This consisted of
software that did not build, or built, but did not run. Generally
security bugs were already taken by security@ (in 2007 anyway.)

Sometimes users are using dead packages. One of the reasons why
proxy-maint was established was to get interested users to step up and
maintain the packages they wanted; in the beginning I wanted
TreeCleaners to be 'maintainer-needed' and fix up all the broken
packages. Sadly though, there are too many broken packages for such a
small team.

-A

>
> I think that a better policy would be rather than having any open
> non-trivial bugs we list the sorts of bugs that should be grounds for
> removal, such as:
>
> 1.  Package does not build in the majority of cases on all archs.
> (Unkeywording is the solution for individual archs that are broken, if
> not easily fixable.  Not building some of the time isn't grounds for
> removal.)
>
> 2.  Package has an open security bug.  (Cuneiform is a borderline case
> of this - no exploit/CVE but I wouldn't use it on a server being fed
> images submitted by strangers.)
>
> 3.  Package is blocking another package.  Maintained packages always
> take priority over unmaintained ones.
>
> Perhaps there are other cases which should be included, but I think
> this covers most of them.  If a package isn't blocking anything else,
> doesn't have security problems, and works most of the time, then I
> think it should generally be kept.
>
> Rich
>

Re: [gentoo-dev] Last rites: app-text/cuneiform

[Ben de Groot]

On 24 March 2013 22:48, Markos Chandras <hwoarang@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 03/24/2013 12:40 PM, Rich Freeman wrote:
>> On Sun, Mar 24, 2013 at 8:31 AM, Markos Chandras
>> <hwoarang@gentoo.org> wrote:
>>> I don't mind adding that link to every package mask. Do note
>>> thought that this is not the only way for a package to be rescued
>>> (assuming it can be rescued). Providing fixes without becoming
>>> the maintainer is also a viable solution, which is probably
>>> something we need to add to that page as well.
>>
>> I started something at: http://dev.gentoo.org/~rich0/treeclean.txt
>>
>> It needs some work, and guidexmlification.  However, I tried to
>> hit some of the alternatives.
>
> I don't think we need to create a new page for that. Just put all this
> text into the treecleaners page.

I suggest putting it in the wiki instead.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin