Call for discussion to clarify the IRC guidelines

[Matt Darcy]

On 20/07/2011 11:07, Alan Pope wrote:
> Hi All,
>
> Thanks for starting this discussion, I think it's very valuable.
>

Welcome, looks like it maybe a worth while discussion.

>
> Assuming "associated software" means main, restricted, universe, multiverse.
>

Very much so

>> Your learning to compile software is nothing to do
>> with the Ubuntu product therefore why should people giving their time to
>> support the Ubuntu product give their time to help you learn about "Linux" -
>> more so when other users who are looking for help with Ubuntu have attention
>> diverted away from them.
>>
>
> So where does gcc, make, ld and related stuff go in there? Do we
> support "How do I create a template in LibreOffice" or "How do I
> manage my sources.list" but not "How do I compile this C code?".
>
> Where is the line?

we don't support "how to use ld" or "how do I compile" however if there 
is a problem with LD or gcc in compiling we can look at that and say 
"ahhh, I see the problem gcc 4.3.2 doesn't support -your-flag, I suggest 
you log a bug to the gcc package on launchpad, or I'll help you do it"

how do I create a template - there is documentation and an libreoffice 
channel, however creating a templates not working it gives me error 001, 
lets take a look.

but I fully take the point it's hard to draw lines.
>
>> to be blunt, if you are an inexperienced user, why would you be using the
>> unsupported beta product,
>
> For fun?

Yes, that's fine, but then I don't expect to see "I NEED THIS TO WORK 
IT's MY MAIN MACHINE !!! or "I lost all my work, HELP !!!!"

what's the point of people putting these warnings on, setting up support 
channels such as #ubuntu+1 for other people to decide they are not happy 
with the level of support and use other support channels that explictly 
do not support that software - I don't like that and I find it rude.

>
> Part of the principle of Free Software is being able to run what you
> like on your own hardware. If "what I want" is bleeding edge crack of
> the day, then so be it.

Totally agree, you can do what you want, however then coming saying I 
built firefox 9 on ubuntu 12.04 with no understand of what I was doing, 
please help me get my box working again doesn't wash well with me, and 
the most realistic answer to this is "re-install and try again".

if I use says I was testing the ubuntu 12.04 build with the proposed 
firefox 9 package, I had $X problems so updated package $Y as a test, 
it's fixed $X but created $Z - that's worth while as feeding back that 
$Y fixed it but also created a problem.

For me these are two totally seperate situations, one is worth while, 
the other is not. That's not to say both are wrong, both are valid, but 
why should we put effort into the first.


>>
>
> We may not recommend it, we may believe new users are daft for doing
> this, but do this they will. We should point them to the right
> direction in a respectful way, and not ridicule them for the choices
> they make.

Fully agree, I don't want anyone to be mocked, but then I also expect 
people doing this sort of thing to either a.) be aware of the 
consiquences of it b.) when given the reality of their situation accept 
it not start begging and crying.
>
>> Why again should the community pickup unofficial software, no matter how
>> good it is, that's nothing against unofficial projects, but if they are
>> good, they can apply for and will get status within the ubuntu project. The
>> definition of official release and supported release (such as EOL products)
>> would certainly benifit from a definition on the wiki going forward.

the EOL stuff is very interesting, and I don't see a problem with 
"fixing" something in EOL, eg: my host file is corrupted, but when it 
comes to actually resolving a problem I find that a worthless task as 
the fix will never make it into the repos as they are dead, 3rd parties 
will have swapped focus onto non-EOL versions, and packages in the repos 
may have been moved/removed, if we are going to support the EOL stuff, 
what's the point of making it EOL, may as well say support runs for ever 
but package support is dead after 18months.

I don't want to see EOL releases cut off at the knees, but at the same 
time why if the company canonical put an EOL on their support efforts on 
a release why should the community not follow that model.
>>

>>
>
> Yes, I have worries about the use of "supported" and "unsupported" as
> well as "recommended".
>

I agree and can see your concerns are valid from your comments.
I'm hopefull one of the things to come out of the discussion is a 
agreement on the terms, even if we don't all agree with them.


>> I believe (possibly wrongly) #ubuntu should follow that model and get behind
>> the supported methods and technologies,
>
> Ok, so the questions above are still being asked, whether we choose to
> help them in #ubuntu or not. The question and requirement doesn't go
> away. So I guess one or more of a number of things will happen.
>
> 1. "Wow, these guys are clever, I clearly don't want to mess this up,
> I'll not do what I wanted to do, and live with old software, or a
> broken ZingDevice"
> 2. "Wow, crap support, I'll go elsewhere for help"
> 3. "Why!? Why!? Tell me, how to do this!"
>
> (1) seems unlikely to me. (2) is more likely with the net result that
> people _will_ do what they want with _their_ systems whether "we" help
> them or not. Other support avenues such as Ubuntu Forums and Ask
> Ubuntu don't seem to impose these restrictions.
>
> http://askubuntu.com/questions/6339/how-do-i-install-the-latest-stable-version-of-firefox
> http://askubuntu.com/questions/51743/how-do-i-compile-a-kernel-module
> http://askubuntu.com/questions/12909/how-do-i-upgrade-to-the-development-release-aka-ubuntu1
>
> Seems to me they manage to provide support for "unsupported"
> activities. How is it they can do it and 'we' "can't" {won't}?
>
>
> Al.


the last bit is tricky, as I know I sit on the unpopular side of the 
fence on this, in that, what other groups do (while valid as views and 
inspiriation) doesn't provide reasoning for what another group does. I'm 
more interested in what we as the IRC community should do.

Matt

>