Re: kde-lean TL;DR unless you're going to use it ;)

Duncan wrote:
> Steven J. Long posted
> > Duncan wrote:
> >> Then I created a framework that works much like epatch_user, except
> >> instead of automatically applying patches to upstream sources, it
> >> automatically applies patches to gentoo ebuilds and instead of using
> >> the /etc/portage/patches/ tree, it uses /etc/portage/patches.ebuild/.
> > 
> > Hmm that's quite interesting. Not something I'd personally want in the
> > tree, but definitely of interest to more advanced admins, as opposed to
> > end-users.
> 
> Of course, as I guess you'll recall (you've been around long enough I 
> think) that's what was originally said about epatch_user as well...

Perhaps, but there's a qualitative difference, in distro terms, between
patching the upstream source, and changing what the distro recommends.
Sure, both leave you to pick up the pieces (as if anything else ever happens;)
but patching the ebuilds is the same as using an ebuild from overlay: get
your support from whoever provided it, not the distro.

> Administrating a computer system is a serious job, and the more people 
> that consider it so, the less danger everyone, both those that treat the 
> job seriously and those who don't, are in.

Like all things were "it would be better if only everyone did X" everyone
does NOT do X by definition, or we wouldn't have anything to discuss.

I don't personally feel the user should have to do anything to have a
reasonably secure machine, and I'd counter that the real problem is that most
people are using an inherently secure system (apparently by design if recent
news is accurate.) IOW we have bigger problems than what Linux users do.

But overall, we agree on approach: the user is in charge, and thus its their
responsibility. Given that we're all human, and further that I don't really
have the inclination to administer a large network and deal with end-users on
a daily basis, I still won't call myself an admin ;-) and will continue to
hero-worship the good ones, since I can't really get much done without them,
if it's outside my front-door.

> an appropriate level of verbosity saying an ebuild was modified in emerge
> --info <pkg>, for posting with bugs) will be needed.

Definitely. A terse line should be in every emerge --info, near the top.

> > Hell yeah :-)[2] You picked an odd forum for it though: I only found out
> > about this because Dominique posted to pro-audio list.
> 
> I picked this list/forum for a couple (related) reasons, in addition to 
> convenience (I was already subscribed).
> 
> 1) It's the coordinating list for kde-sunset, and this seemed a 
> reasonably similar project, so using the same list seemed appropriate.

Ah wasn't aware of that. It seemed odd to me, since the gentoo-kde team
clearly thinks the approach is a waste of time, so why expect a positive
response on their ML.

> >> A hybrid alternative would be to adopt an idea much like the existing
> >> kde overlay, where there's a documentation or tools directory that
> >> carries them, in addition to the kde-base category and etc, carrying
> >> the patched ebuilds themselves.
> > 
> > That sounds ideal, but why not just have two overlays? One for
> > ebuild-patch which others can use and collaborate around, and one
> > conventional kde-lean for people who want the end-product.
> 
> kde-lean definitely beats kde-nosemantic, my working title.
> 
> As for ebuild-patch, an overlay just for it?  What about setting up a git 
> repo somewhere (github's popular, but not open source...) and putting the 
> ebuild for it, presumably using git2.eclass for a live-9999 version, in 
> the sunrise overlay?  Once it gets mature enough to tag, if we don't want 
> to bother with a tarball, a versioned ebuild can still use the git 
> infrastructure, and simply checkout a specific tag.

Yeah a repo for it works fine, for me. People can just use a live vcs ebuild
to stay current; after all it's an experimental setup, so if you use it blindly
you're an idiot. The user must be aware that they need to review the patches
they apply to ebuilds on every bump, so being aware of the need to keep an eye
on epatch-user itself isn't that much of a hardship.

However we should still make it so that an upgrade doesn't actually change
existing patches. That pushes us in the direction of the patch, review and later
use of an ebuild, rather than a live patch during an emerge itself, which fits
with the separate overlay model.

(Yes, I'm aware you can't patch an ebuild during an emerge, because metadata has
to be constant.) I just mean the overall design is one of patching as one process,
and use as a later, independent phase that does not have any awareness of the
fact that the ebuild has been patched (apart from the metadata tag for QA.)

If that's required, I'd actually argue against it, even where it's similar to the
check of version being 99999*, as conceptually it feels broken: the whole point
is to patch the ebuild for a specific situation, and only to distribute as
equivalent ebuilds in an overlay. If you've patched it right, there should be
no need for anything like that.

It's never going to need to get a different set of sources according to whether
it's been patched or not, for example; the kind of thing we'd check version for
in a live ebuild that can be used for fixed sources. By definition it's always
patched.

That makes the ebuilds produced candidates for use elsewhere, should they be
wanted. Not for our stuff ofc, but for other users like overlays, where submission
of patched ebuilds to Gentoo might be a future possibility.

> > I'd ask that we collaborate on the forums[2] about this: things can move
> > much quicker there, and you get general encouragement and lots of bug
> > feedback, as well as others to help.
> 
> I've actually seen lists/newsgroups move in very close to real-time -- as 
> close as I generally care to get (I don't do IRC as I like a bit more 
> time to compose my posts).

Lists can move in near to realtime yes, but they seldom move usefully when they're
moving that quickly, ime. Part of the problem is that all subscribers get a copy
of the email delivered to them, whereas forum posters have chosen to read your
post. Reading lists via gmane shields you from that, but it's important to remember
that many others get your posts in their mailboxes.

So if forum-users reply, it's because they're interested in the topic, and you
never get people who are just posting because they're irritated at what to them is
noise, since they're not actually interested in your new thing. If that were the
case they wouldn't even have opened the thread, let alone got to the end.

> But, web-forums do seem to be more popular, and I guess I could dust off 
> my old forum login or create a new one...

Yay! :-)
 
> > I can get the overlays, git and trac setup, same as we did for hardened
> > a few years ago, if that helps.
> 
> That would be useful.

Okey-dokey: I'll mail you off-list in the next day or two, after I've got the git
repo setup, as we'll need to also setup an ssh login for you, to commit.
 
> Person to person, let me also say I'm absolutely thrilled to have you 
> helping.

Thanks man :) Your words gave me a real boost. I'm delighted to be collaborating
with you too: I always regretted that I couldn't persuade you to use update[1] ;)

> Of course there's other than shell/bash, but that's the scripting I'm 
> most familiar with.  I tried perl but that didn't go so well.  I have on 
> my list to learn python some day, but it's been on my list for awhile, 
> and bash can do way more than a lot of people give it credit for, even if 
> it's not the most efficient choice for the job otherwise.

Exactly. I was amazed at how far we could push bash, when I only had a 32-bit
machine. In the end, I gave up worrying about it, though slightly regretfully:
for some perverse reason I wanted it to fall over on me with such a large script.
As for performance, it's pretty sh1t-hot imo: the plan was to rewrite large chunks
in awk once we'd got the basics running, but it was never needed.

All in all, I'd say people who think bash is slow are using it wrong. Sure it's not
as fast as bb for basic sh. But if you want to write a moderately complex application
you'll tear your hair out with sh, in places where bash has constructs designed by
people who've been scripting for decades, to fix the exact *coding* limitation you've
come up against. Granted a lot came from ksh, and bash takes ideas from other shells
like zsh. Personally I like that ;)

Shell-scripts are slow, because people call externals when they don't know better,
typically on a crap OS that can't handle fork very easily, whereas it's trival on Unix.
Then they walk away declaiming how the language is useless. Unfortunately since it was
designed for use by any user, that means any idiot can knock something together and
think they know it well, though their script would earn them a day of lessons (or a
roasting if they think they're it) in #bash.

> > [2] How to opt out of a semantic-desktop?
> >     http://forums.gentoo.org/viewtopic-t-963504.html
> 
> I guess you're more of a forums user than I.  If we do the forums, new 
> topic in desktop environment, or unsupported software, or ...?  Or 
> continue with the topic above?

Continue with the topic. If it needs to be moved the moderators will do it, when
they feel the time is right.
 
> And do we combine the kde and tools subjects in a single topic or one for 
> each?

Let's just start with that thread, and make the tools work for our use-case,
while keeping them in a git repo others can use and collaborate around. We have
a reasonably simple aim for the tools, and we're both committed to making them
useful for more than the one project, so I'm reasonably happy we're not going
to make them unportable, or completely specific to kde.
 
> How strong are your forum prefs and do you have any further thoughts/reasons
> why switching to the forums would be better?

Just what I said above, about the forum users self-selecting that they care
about the thread, as opposed to spamming everyone's mailbox with it. Moderation is
useful too, when done as well as the Gentoo Forums are moderated. Though I prefer
IRC for people I actually have to collaborate with directly: it's more like email
than people imagine, so effectively works as async/offline, but it can be as quick
as real-life when needed. Plus it's all about your attitude and your knowledge,
not about what badge you have attached to your address. (In fact, flaunting +o is
actively discouraged.)

I won't do development on a mailing list, personally. Discussion around proposals
and ideas, to elicit feedback from the wider community before moving forward is
a great idea, and personally I think that's why Gentoo has done well. AIUI
when drobbins set it up he'd been burnt by the descent into clique that is a
peril for any FLOSS project, and so the dev ML has always had that as an explicit
purpose. Not that that stops it getting cliquey, it just means the current clique
(and they're nebulous things;) can never take over and destroy the distro. At
least, not without a clear record that users hated what was happening, before they
all left.

I quite like lists about patch submissions, though. When we used to get
gentoo-commits follow-ups on-list, it was actually interesting, since people
were talking about the code we actually want from them (ie ebuilds) and not
their latest dream of an idiot-box, or why portage sucks and can we have your
ebuilds.

The pro-audio overlay list is quite interesting for the same reason, though the
discussion is a lot sparser nowadays, and it's mostly just the bot. I like to
think that's because most of the problems are well-understood, and people
are just concentrating on the ebuilds. I have a vague feeling that probably
means we're due for a big round of "innovation" to make things more 'interesting'
or 'time-wasting' depending on your view. ;)

> It's just that... I've been a regular on some lists and/or newsgroups for 
> a decade or more (I've been a regular on the pan lists since 2002, 
> according to gmane, and I've been on some newsgroup or another since I 
> discovered them back in 1997 or so, back on MS with the IE4 previews), 
> but despite the best of intentions, I've never been able to handle a 
> forum for more than a couple months before I burn out on it, so quite 
> apart from the personal preference thing, a real-life consideration is 
> that my own longevity as a project contributor before burnout may well be 
> conditional on what form the project communications take, list or forum, 
> with the latter very possibly leading to much faster burnout.

I think you should just deal with the issue, which is that you burnout on
forums, likely because you get too involved, and post at such length you
don't have time left over for yourself.

Don't do that. Learn to let go. Why does it matter if "someone on the internet
is wrong"? ;)

But still I'm glad you raised it, since it means I can keep an eye on it too,
and email you if I think you're burning out (or posting too much and not fixing
stuff instead;)

I think though, that the reason you burnout on forums is actually because they
move quicker than mailing lists, and people who are posting are usually as
caught up in the topic as you are: without moderators you basically don't have
any externals, unlike a ML, or IRC (where people are happy to tell you it's got
boring, and no one takes offense. Well, no-one you can't /ignore. ;)

> kde4 itself is planned to continue getting further updates until say mid-year
> 2014 (or later if they get behind on kde5/frameworks), which means it'll
> probably remain available in gentoo  until end of 2014 or so, at least.

Good to know, thanks.

> However, with interest and help from others, it's quite possible my 
> initial patches and tool code can help jumpstart things, and the project 
> will be able to continue without me by then.
> 
> What do you (and anyone else who cares to jump in) think?  Is it 
> reasonable to expect the project to be sustainable without me once I 
> decide to move on to kde5/frameworks

Yup. Or we're doing it wrong, which we'll find out within the first two months.

> As I said, you're more experienced in the forums than I.  There's 
> certainly some interest there.  But is it likely enough to build 
> something that I can reasonably expect to be sustainable without me in a 
> reasonable time, or is it likely that I (and possibly you) will be doing 
> nearly everything myself/ourselves, and once I move on, the whole thing 
> will dry up and blow away?

It's always a possibility. I don't think it's very likely for two reasons:
Firstly, I'm a lazy sh1t when it comes to anything that's not code, and a lot
of this won't be about coding, so it's very unlikely I'll be doing all the work ;)
Secondly, I have a lot more faith in Gentoo users when it comes to scratching
the itch to make stuff work. They've basically "self-selected" again when it comes
to that. And they have a very wide range of computing experience. AFAIC they're
basically _the_ elite userbase.

IME you just have to give them the support and encouragement to try stuff, and wait
to see who contributes the most. And what's good about it, is that even people who
think they can't contribute, do so, just by encouraging you, or giving you feedback.
There's been times when I would have given up on update, since it's just me now,
only for someone to post out of the blue and thank me. I cannot tell you the boost
that gives you, since it validates all the effort you've put in.

Again, because it's a self-selected group even when it comes to reading the thread,
the only people involved care about making it work. I was really surprised at how
nice people are on the forums, especially when compared to the mailing-list. Now I
take it as a given that anyone posting is coming from a positive space.

I wish I could say the same about the lists.

>  And if it does dry up and blow away when I 
> leave, will it have been worth the trouble for the time it will have been 
> available (hey, it gave people six months they'd have not had otherwise 
> and that's something!), or not?

That's your call to make. All I'd say is: don't think of it as all-consuming,
and don't let your head go there when you are posting on the forums. You have
to remind yourself from time to time, that you're doing it because you want to,
and no-one's paying you a dime, so you don't owe anyone a thing. You care about it,
so it's easy to forget: it's low-priority. Period.
 
The only exception is when you've pushed a buggy version. Then you better fix it
quick (and not with a forced rebase), or expect a bollocking (as I've learnt, and
so shall I teach, since it cuts through the haze.[2] ;-)

> Finally, it's worth confirming one thing brought up on the forum thread.  
> I don't see any realistic possibility of doing anything further with 
> kdepim in a no-semantic kde.  That's an upstream hard-dependency and I 
> don't see anyw way around it, making kdepim totally non-viable for our 
> purposes.  Agreed?  Given that, I believe it best not to carry kdepim in 
> the kde-lean overlay at all, and to recommend that people use something 
> else.

Agreed. I never thought I'd stop using KMail, but there it is.

> And one more thing:  Short term, is it worth it to post the 4.10.80+ 
> patches as I have them either here or to the forum thread linked above, 
> or is it better to wait until we have an overlay to put them in and/or 
> until 4.11.0 is available?

Do please post them to the forum thread, in a [code]block[/code] if the diff is
reasonably small; you can Preview any post to check how it'll look, or Edit it
(top-right of the post) after you've submitted it. If you do that before anyone
replies, it doesn't show up as an edit (Last edited..; edited X times in total.)
But in general preview everything with tags in it.

Or at a reasonably light pastebin with a [url=http://..]link text[/url] I use
http://sprunge.us/ generally, but IDK if that's at all permanent. I doubt it ;)
http://paste.debian.net/ is used by quite a few people, and checking it I see it
allows "permanent" posts.

Just not pastebin.com please. It used to have an awful lot more ads, but it's
still heavy, and it also used to insert CR/LF. I don't know if it still does;
I refuse to use it, and only occasionally follow a link to it on IRC if it's
something I'm really interested in reading. If someone's asking me for help,
they won't get it with a pastebin.com link, unless they're cool and use another
pastebin when asked.

> kdelibs ebuild was still kde 4.10.4.  My patches are tested not to pull in
> the deps here at all but they're for 4.10.80+, where the semantic-desktop USE
> flag is already gone, and thus won't apply cleanly to earlier versions that still
> have it.

Good, we need them in those versions, and we need to start thinking of the whole set
so collaboration early is better, as ever. I'd better get my update --toolchain patch
set finished so I can upgrade my system (Forgive me Gentoo for I have sinned: it's been
3 months since my last completed emerge world..;) and see what's happening in the
latest stable versions.

Thank god for FEATURES=binpkg[3] though: I can roll back if 4.10/11 turns out to be a
stinker. The way I feel about 4.9, is kinda how I felt about 3.5, so it's all good.
There's some nice stuff in kate for 4.11 I want to try though.

>  Also, while complete for the packages I have installed, I don't 
> have a full kde installed (obviously not kdepim, but beyond that too), so 
> further patches will likely be needed for other packages.

Yeah. Please post the patches to forums, so we can get cracking.

Regards,
steveL.

[1] http://forums.gentoo.org/viewtopic-t-546828.html
[2] http://www.paulgraham.com/head.html
 -- very useful to explain ourselves to non-coders, if you've not read it.
"I don't hate you, I just can't stand it when you talk to me.." ;)
[3] http://forums.gentoo.org/viewtopic-p-7165614.html#7165614
 -- I know you're using it, but others might not be yet.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)