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

[Sergey Popov]

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



signature.asc
Description: OpenPGP digital signature

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

[Róbert Čerňanský]

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

 On Sun, Mar 24, 2013 at 3:24 PM, Ian Stakenvicius a...@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: ope...@tightmail.com
Jabber: h...@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 patr...@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: ope...@tightmail.com
Jabber: h...@jabber.sk

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

[Alec Warner]

On Sun, Mar 24, 2013 at 4:40 PM, Rich Freeman ri...@gentoo.org wrote:
 On Sun, Mar 24, 2013 at 3:24 PM, Ian Stakenvicius a...@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 hwoar...@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
 hwoar...@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

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

[Róbert Čerňanský]

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

  MC == Markos Chandras hwoar...@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: ope...@tightmail.com
Jabber: h...@jabber.sk

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

[Rich Freeman]

On Sat, Mar 23, 2013 at 5:40 PM, James Cloos cl...@jhcloos.com wrote:
 RF == Rich Freeman ri...@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 cl...@jhcloos.com
  wrote:
 
 MC == Markos Chandras hwoar...@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)

iQJ8BAEBCgBmBQJRTti1XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
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 hwoar...@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)

iQJ8BAEBCgBmBQJRTu14XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
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 hwoar...@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
 hwoar...@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)

iQJ8BAEBCgBmBQJRTvIwXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
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 hwoar...@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]

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

  RF == Rich Freeman ri...@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


signature.asc
Description: PGP signature

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 pe...@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 pe...@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 pe...@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.mckin...@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
 hwoar...@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)

iQJ8BAEBCgBmBQJRTxIrXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
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)

iQJ8BAEBCgBmBQJRTxO8XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
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 ri...@gentoo.org wrote:

 On Sun, Mar 24, 2013 at 8:31 AM, Markos Chandras
 hwoar...@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: ope...@tightmail.com
Jabber: h...@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 a...@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 patr...@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

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

[James Cloos]

 MC == Markos Chandras hwoar...@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 cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6

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

[Markos Chandras]

On 23 March 2013 19:52, James Cloos cl...@jhcloos.com wrote:
 MC == Markos Chandras hwoar...@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 cl...@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 hwoar...@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 cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6

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

[Markos Chandras]

On 23 March 2013 20:13, James Cloos cl...@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 cl...@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 cl...@jhcloos.com wrote:
 MC == Markos Chandras hwoar...@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 cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6

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

[James Cloos]

 RF == Rich Freeman ri...@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 cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6