Gentoo Developers Video Library

Well, this comes rather longer and bigger than I anticipated.

Now, getting to a suggestion I was trying to work out for resolving boring documentation issues. So, I have to thank few people first, and they all are our great User Representatives:

Loki99 - his views (rather pessimistic this time) help me concentrate and recheck myself.

Now, although I did came up with initial thoughts for this, it was developed, checked, edited, added ideas and contributed in sorts of other different ways by Q-collective and toskala. Thanks guys.

After reading a lot about Ebuild GUI builder (tm) and even contributing my cents to the debate, I got few responds to my writing. In general, responses can be summarized by the following:

1. I totally agree with you! Can I quote you in my prayers?

2. In general, I agree with what you said, but even creating a simple ebuild automatically can be something not as generic as it sounds. It can be even wrong in some cases to ignore USE flags, because installing a package with default procedure (./configure; make; make install) can be incorrect and sometimes even break something in the system.

Besides that, everyone seems to agree with me though, that users should read a portage documentation (which potentially can provide Gentoo with more developers in the future).

But then, we get back to the original question: “Why would users want a GUI builder for ebuilds?”

I believe there are 2 reasons for that:

1. For an occasional user, it would save time for creating a “simple” ebuild - as all he or she has to do is (supposedly) provide some basic details about the package he/she would like to build and automagically an ebuild would be built for her.

2. No one wants to read the documentation. Don't get me wrong on this - I know what the documentation is for and the reasons for it to be read, but for someone who wants something done fast (and in lots of cases this would be a one-time contributing user) - reading lots of stuff even before getting to the point is a definite intention killer.

So, after I thought about it, I understand the issue and agree, that the first action item (creating an automatic ebuilds builder) cannot be solved easily - or fast for that matter.

But documentation and an attitude towards it might be.

So, if I would to redefine the problem, I'd say it's this:

"Gentoo [developer] documentation (which provides an information and knowledge about portage and ebuilds) is an especially boring read for one-timers. What we need, is one of the following: allow creating an ebuild with less effort that it requires today or make a process of getting the information about it more interesting".

So, I have a suggestion about making it more interesting.

I would call it "Hands-on developers library".

The concept I propose is as following: create a screen-cast (video-cast, screen recording - choose an appropriate name) of actual writing of an ebuild (using your favorite text editor). Make it only few minutes long. Add audio comments to it and explain at each step what is it that you do. Redirect for more info to the documentation and give the direct links to it.

Rationale

I believe, that following benefits can be achieved by such information representation:

1. Watching “movies” is much more fun than reading plain documentation. Specifically, while keeping them small enough, this kind of movies provides a user in minutes with concentrated needed information she needs, so she can start “experimenting” creating her own ebuilds immediately.
2. By giving an example of writing a simple ebuild, you could inspire users to follow given directions to create their own ebuild. They would hear explanations for each step, so they will better understand what even simplest things are there for. They will also see the redirection to a full documentation site, so there won't be a need to go over piles of docs to find the specific one they are looking for.
3. If needed more complex example with more complex ebuilds, make another recording. Just keep it short enough not to get a boring school lecture.
4. It is possible to create as many recordings as would be found fit.
5. Such examples can be developed in parallel by several people, thus multiplying the amount of examples and easily expanding the experiences in the library.

In addition, I find that the following issues should be addressed:

Relation to "may never come to existence" Ebuilds GUI builder.

Such implementation has no direct relation to a EGB (Ebuilds GUI builder). It just tries to solve a particular problem by other way.

License

I believe, that if implemented, such recordings should be released under an opened license. As such, CC (Creative Commons), which used widely for creative content, may be appropriate.

Technology

Few aspects of technology should be worked out, such as:

• Format in which these recordings would be created.
• Tagging, indexing, creating chapters for easier and later access and search of content.
• Storing the content of each recording (ebuild) online in ASCII form, so easy content usage can be allowed for later personal use and experimentation.
• Minimal requirements for a system where one should be able to see those recordings (depends on a format chosen).

An example of interactive chapters approach is the use of flash technology (although it is known not to be much loved inside the community). Other solution can be a real movie file (in formats such as MPEG or OGG).

Accessibility

This aspect of the project should get attention as well. By accessibility I mean allowing blind and hearing-impaired people to enjoy the fruits of this project:

• Transcription of voice recording, which would show as subtitles in timely matter.
• Creating full audio of a particular recording should be technically supported.

Styling

Our aspiration for quality requires all content to be as professional or at least as consistent as possible. This requires for "styling guidelines" to be developed, which would include some, all or at least the following:

• Fonts chosen.
• Fonts sizes.
• Color schemes.
• Speaker with a nice and easily understandable voice.

Medium of distribution

An appropriate medium should be chosen. Whether it will be hosted by Gentoo or by, for example, Google or YouTube remains to be decided. It is also very dependent on format chosen for recordings.

Security

Because such recordings actually show how to create an ebuild, there's a risk that "faulty" and erroneous recordings (which if followed could destroy the system) may appear in the web. To fight off such security issue, few things should be resolved:

• Authorization and authentication processes by official Gentoo should take place. For example, only recordings which are hosted by Gentoo are authentic.
• Even today, such an ebuild can be introduced into bugzilla, and as such can be probably related as similar threat. Such ebuild in bugzilla (or recordings) would probably get a comment that it contains negative content, and their distribution would slow down.

Anyhow, the matter of security on such sensitive subject should not be taken lightly.

Pro's and con's

Technologies

• Choosing flash format would allow interactive menus/chapters/links, but it is a closed format, and as such may not be chosen.
• Creating chapters/index/live links inside the recordings would complicate the creation process but make it easier to access the content later.

Distribution Medium

• Choosing to host recordings on Gentoo would allow easier authentication and authorization of the content.
• Choosing to host recordings on Google Video or YouTube would save a lot of bandwidth and hence lower the costs, but may create a “security hole” as not being “authenticated”.

Licensing

• Choosing CC over other types of license, makes the process easier as CC was specifically created for licensing creative content as audio, video, pictures and text.

Styling

• Choosing to work in particular style may complicate a bit and prolong the process of creating a recording, but in doing so, it will make easier to impaired to understand the content.

I also believe that such recordings would make Gentoo even more unique than it is today.

In addition, this may allow us to kick ass Debian, Ubuntu, Fedora, SUSE, Mandrake or whatever!

Few more things:

1. I don't believe in miracles made by humans. I don't think that from the first recording everything will be perfect. It can be started with something small, and get developed over time to answer all the issues mentioned earlier.
2. This suggestion does not nullify reading the documentation. It is merely a step which tries to simplify the process of initial understanding how portage works and how to create packages. For serious portage/ebuild development one would still have to go through a lots of documentation, tests, quizzes, mentoring and whats not.
3. I think this can be good idea for the UserRep project, as it will allow correlating between what users need and what developers can provide them with.
4. Although this may get more users to try and develop something for Gentoo (and that would be great if it happens), it doesn't mean that reading documentation later would be less boring and less abstract.

Thats about it. Comment it or not, its a completely your choice.

Boring documentation

OK, after debating all the GUI Ebuild Builder thing and considering responses I got about it, I have to agree: it may not be implemented soon. There are issues to be solved to consider such thing in the first place, and they do require some effort to solve them.

So, in meantime, I thought about solving the problem by doing something else:
1. Redefine it. Which problem exactly GUI Ebuild Builder is trying to solve? Maybe we're trying to solve the wrong problem.
2. Try to solve the "original" problem some other way.

I believe that "original" problem is being documentaion. I know, I know, documentation is there for a reason. But for an occasional user or for initial steps it is huge, intimidating and boring. It is boring to read piles of docs just in order to start and create some simple ebuild, and it has no appeal at all for an occasional user.

So if we try to solve the "boredom" problem of getting familiar with docs (or any info for that matter) at the beginning of the process, we may get more attention from potential users, and more people may try to get into portage/ebuild development.

I have a suggestion as to how potentially solve this problem, and it's in the works as I write this. More details later (maybe few days)

Geek certified

Although I really had no doubts, it is now proven. I'm not a nerd, I'm not a dork, I'm a geek.

Here are the test results:

Pure Geek
43 % Nerd, 73% Geek, 17% Dork

For The Record:

A Nerd is someone who is passionate about learning/being smart/academia.
A Geek is someone who is passionate about some particular area or subject, often an obscure or difficult one.
A Dork is someone who has difficulty with common social expectations/interactions.


You scored better than half in Geek, earning you the title of: Pure Geek

It's not that you're a school junkie, like the nerd, and you don't really stand out in a crowd, like the dork, you just have some interests that aren't quite mainstream. Perhaps it's anime, perhaps it's computers, perhaps it's bottlecaps, perhaps it's all of those and more. Your interests take you to events and gatherings that are filled with people you find unusual and beyond-the-pale, but you don't quite consider yourself "of that crowd." Instead, you consider yourself to be fairly normal.

Ebuild GUI or ! Ebuild GUI

Well, after reading all this I totally agree with Q-Collective: its going circles.

Before I start, I have to mention few things:
1. This issue cannot be resolved in one forum thread. It is too controversial for some people, and as such, there always will be someone with "I have to say the last word!!!" attitude.
2. It is obvious, that a stance on this is different for developers and users. Hence, it has to be dealt with each group accordingly.
3. I never (or almost never) take one side in the argument. That is probably because I still haven't been in an argument that I 100% agree with.

Now to the point.

As I understand, the major question is whether there should be a tool for automatic building of ebuilds. There are 2 major opinions:

USERS: of course!!!! For ages I've been secretly dreaming to write lots of ebuilds, sometimes even a couple before I go to sleep/lunch/out ( Choose appropriate, - Alex), but those evil developers made it so complicated, that ordinary humans cannot master the craft. And that documentation thing? One has to read it to be able to do anything.....its awful.

DEVS: nonsense!!!! Noone in his healthy mind would need such a thing. We wouldn't want to bring piles of users (read crappy, - A.) ebuilds in, and we would not like to maintain those, and we wouldn't like to develop yet another portage application. Besides, it would be too complex to be somewhat useful, and totally useless if made for simple things.

Other opinions, simply put in terms of quantum mechanics, are superposition of these two.


Now I would like to analize the problem in hand, what it is good for and why would it help (or not).

I start with the basics: do we need an Automatic/GUI/Text/Whatever ebuild builder (TM) ?

For some reason, the question, albeit simple, got complicated in the way. I think this might be easier if we dissect it a little bit, such as:
1. What would such a tool provide and how can it help?
2. What sorts (kinds, types, etc) of ebuilds we would like to be able to create with such a thing?

Starting with first part, what would such tool do for me? Quoting Q-Collective, "it will help to make the tree bigger". Regargind this remark - as I know based on my own humble opinion, the most frequent type of package any "normal" user would like to add, can be compiled with simple "./configure; make; make install". Now, that, is what I would call the default ebuild for a package. What would be needed for generation of an ebuild for that? Just URL for source files and description. Is it that hard to do? Don't implement USE, DEPEND and RDEPEND. Just default 3 commands.
Now, to prove the point, take that "normal" user and ask her to write an ebuild manually. That would be funny.

So, going to second part, if we can identify at least one type of ebuilds that can be created with such a tool, can we find more? And if we cannot, would one small type thing matter anything?

As for other types of ebuilds with one simple "builder" - I really doubt it. Not because I think its impossible, but because, no matter how loud "normal" users would cry about creating ebuilds, one should understand the process, meaning that if default ebuild doesn't work, then probably the whole thing is sorta pointless, because there are not so much users who would even test the package installation with default 3 commands in the first place. A user, should she decide to create an ebuild, and given that default one doesn't work, should be able to understand why it doesn't work, and not just play american tests with some GUI (or text, doesn't matter) wizard.

Now, regadring "crappy" packages. If the tool created by someone, who deliberately thought out the way it should work, then please, with all do respect, define a "crappy" to me. And how can default ebuild be crappy if all it does is to run make? That does not make any sense to me.
What does though, that if lot of users were to use such tool, then devs would get consistent, streamlined and understandably written ebuilds, and not a mesh-up created by hourdes of different people, each with her own style of coding.

Now, as I partially done with users, lets see what it holds for developers.
1. If such a tool was to exist, and users would start to use it and donate ebuilds, would it contribute something? Absolutely. First, you could ignore it, and then nothing is changed if compared with what we have today, and you still have users who do not really involved with the distro, although they might want to. Second, you would get loads (supposedly) of ebuilds, all written the same way, easy to understand for you. Maybe it would be good enough to put it in overlay or even tree - but then, you get in effect, user-contributed content, which holds two-fold advantage: you work less, because all you did is check that ebuild is ok (not essentially getting to know the software), and also user feels like she did something.

2. It might incite user to solve the problem if default ebuild didn't work, thus making the user more proficient in ways of portage, and in effect making a user more valuable contributor.

3. If a package is inserted to Bugzilla, wouldn't you prefer some more controlled way that users would go when creating packages? Noone would argue that creating packages with automatic process is much better that user who really doesn't know portage writes one and submits it.

So, to sum up, here my conclusions:
Q1. It seems to be, that only for default process of installing a software an ebuild can be automatically and correctly created. Does this worth the effort of creating another "software" and inserting more bugs into what we have?
A1. Absolutely!!! I do think, that by providing a way to create such default ebuild (and maybe even placing it automatically in overlay area on the machine would be great, and submitting to bugzilla automatically from the same script given username and password would be even better), it would create a lot of opportunities for users to contribute new packages. I know from my own expirience, that I gave up on creating few ebuilds just because each time I wanted to do that, I lost myself in documentation on one step or the other, and too much time was spent on seemingly simple things. I shouldn't spent my time looking for right versioning scheme, which can change rapidly.

Q2. Wait, you're saying that this thing should do one type of ebuilds only??? Are you nuts?
A2. No, its not what I said. This app can do one type only at the beginning, and if wanted it can be easily expanded. I beleive, that writing one simple "builder" for one type of ebuild, can be done by proficient portage programmer in 15 minutes, and then GUI can be added to it by some more artistic person in another 15 minutes. No need to dramatize.

Q3. OK, but what do we do with those ebuilds??
A3. The same thing that done today with ebuilds submitted to Bugzilla.


And the last thing.
As it seems, such a tool mainly would support users (read one-time contributors) and help them to get involved. It would not enforce developers to action, nor would promise users their ebuilds will be taken. It is just a tool, its purpose it to help make things happen, not to make things happen.


And for developers, I do beleive that creating an IDE may help a lot, meaning function checks, test, cross-referencing between classes, inline help, etc. And building it upon Eclipse seems to me good idea


And a really last thing. I still hope, that even given this tool comes to life, I hope that mentoring will still require knowledge of how to use text editor to create ebuilds. Not some fancy shmancy builder.

As always, just my humble opinion. Comments are welcome even on this one.

Suggestion for a new "Gentoo Userday"

I haven't written anything lately, because I don't beleive in saying something with no purpose. I beleive, that if you have something to say, say it, if not - keep you mouth shut. We have too much background noise anyway.

So now, as I published in user relations ML, I'm suggesting something new - a "user day", sorta bugday for users.

The idea came up to me after a few things, amongst them:
1. Gentoo Bugday
2. Users Representatives are about to start to do something...
3. The need for users->dev flow


The concept:

I suggest having regular user meetings, which can take place in either
forums/irc/ML (choose your favorite medium). The main idea for this is
to give users a place to whine about anything that bothers them in
Gentoo, ask for something or suggest new stuff. It can be anything at
all, starting from "I don't like default color in prompt in default
screen" and up to "I suggest creating totally automatic installation
including very cute Gentoo girls (or boys, just to be politically
correct) performing the install".

This would allow a few things: a) anyone can offer or complain on anything
she/he likes or dislikes; b) users with no knowledge what the hell Bugzilla
is, can suggest very good things in plain language that otherwise would
not come up in any shape or form; and for some users c) to cry to
someone about their computer problems (and don't tell me we're not here to
be a shrink, simple "I hear you" means a lot to people); and d) to let
out steam so user can more calmly explain what bothers them.

On each meeting, all suggestions/complaints which are worth
consideration are noted and saved and later discussed in a smaller forum
of people. After that, it can either 1) be dismissed; 2) left for
further discussion or 3) sent to implementation, such as userrel meetings
or inserted into Bugzilla.

Those meetings can also be regarded as "brainstorming" days, so they can
be used for hunting users' needs for our great distro.

About what we do have now and why it doesn't solve the problem on hand:

1. Bugday
Bugday is a great idea for fixing bugs / implementing
enhancements/features and generally pulling users in. But, from majority
of users' point of view, it is not relevant as a place to cry or suggest
anything, because most of users (or at least many) do not know what
Bugzilla is. Explaining in plain language is still much easier, and
getting an answer in a matter of few seconds gives a feeling of
"service"; whilst ignoring causes people to leave or at least not to
bother in the future. In addition, bugday work is highly organized (by
definition, there's nothing wrong with that) and hence moderated. As
such, some things/ideas/suggestions will be automatically ignored/thrown
away, because of these constraints.

2. User Representatives are now in some kind of self search, trying to
figure out how and what they would do for Gentoo. Main issues that they
deal with right now are about an infrastructure, and organization. I
have no doubt that all of them are great people and will contribute to
distro greatly, and that in the beginning all teams have to work out all
the logistics. Hence, because I'm not a userrep, I have no such troubles
in my mind, and all I can do is provide my humble opinion on things.
On this particular matter, in my opinion, implementation should
originate with userrep. These meetings are for users, and hence
naturally that Userreps would take responsibility for this. Details can
be worked out later.

3. Today ee do not have any kind of process for concentrated user
feedback/requests. These meeting would allow users to say what's in
their mind, and would allow some kind of ideas to be born out of preliminary
discussion. It would also help to eliminate obvious erroneous or
unimplementable ideas so they don't even reach devs.

A few remarks about this suggestion:

1. This suggestion should not obligate devs to participate in those
meetings. Meetings are for users mainly, and there is a userrep team
which should attend and collect useful data. If there's something
userrep considers valuable, they would bring that to userrel as it is
userrel subproject.
2. Anyone who participates and suggests anything, should understand,
that there's *no promise* for suggestion to be implemented. There might
be lots of reasons for that, starting with lazy devs and to the point
where the idea was considered it was decided not to implement it for
different reasons. But it should not stop users to keep
suggesting/complaining at following meetings. On the other hand, should
an idea be taken to implementation, a user who suggested it should receive
a credit, because it shows respect and also encourages others that
Gentoo people listen to their users.
3. On a timely basis, a summary of suggestions/complains should be
published, so users would see that userrep team has nothing to hide.
4. Because of large the userbase, such meeting can grow to a very large
grouping. In such cases, different "sub-meetings" can be implemented,
for instance one for complaints, one for suggestions. Or, one for
desktop issues, other for install issues. Or anything else, imagination
is (or not...) the limit.

That's all for now,
Comments are welcome