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

[Alan McKinnon <alan.mckinnon@gmail.com>]

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