open development of tinycore

[roberts]

You can please some of the people some of the time...
Doing a distro is such a thankless task!

[Rich]

Hi cosmin_ap

"What we got here is... failure to communicate."
                                       [Cool Hand Luke, 1967]

Say I report a bug today, when will I be able to access the fix?

That depends. If you report a bug for an extension, quite often the extension maintainer will have it
fixed and available in a day or two. If the maintainer cannot be reached in a timely manner (typically
two weeks), someone else will fix it. Maybe even you, if you have a fix and wish to do so.
If you find a bug in the base, any fix would most likely wind up in the next Alpha, RC, or final release.
If you look under TCB News in the forum you'll see releases occur quite often.

If it's quicker for me to just fix it locally would I even bother to report it? For what benefit?

If you find and fix a bug in either the base or an extension, and you decide to install a newer version,
you won't need to re-implement the fix. Plus you said you wished to contribute, supplying a fix for a bug
would be doing just that.

The only question is: do tc devs consider additional dev. involvement welcome or are they self-sufficient?

While I can't speak for any of the developers, I can suggest you use a different approach. Why don't
you try posting something about your capabilities. What programming languages are you versed in?
Maybe you have experience in driver development/debugging? Writing GUI based applications?
Kernel modifications? Documentation? Porting packages from other Linux distributions? By stating how
you wish to contribute you would get a better response. I'm sure the ability to answer questions on the
forum is also valued. Some of the people on this forum maintain a great many packages. It's possible
you possess a skill some of them may be looking for.

How can I find out right now who's on what, what's fixed and what's not? Should I just scan the 16 pages of topics on the "TCB Bugs" and make myself a list?

Of course not. If you find a bug, do a quick search. If nothing turns up, post it on the forum. If it's been
reported and/or is being fixed, someone will reply or direct you to the relevant thread. If you are looking
for something like an open list of bugs I doubt you'll find it, bugs get fixed pretty fast.

While the atmosphere is informal, what's important is that it works. When fixes/changes are being made,
members communicate and coordinate their intentions through the forum for all to see and the end
result is a well maintained Linux distribution.

Please accept this as just some friendly advice and not a lecture.

[cosmin_ap]

Doing a distro is such a thankless task!

Let's not get dramatic over this. Everyone here appreciates your efforts. After all, we're here arguing about tinycore, not slitaz or dsl, which should be enough confirmation for what we like and appreciate. But that shouldn't stop us from debating new ways to improve the process, doesn't it? I mean, unless you think there's no room for improvement (I'm sure you're not - that would be illusory) or there's something inherently wrong with faster access to bug fixes, automatic extension building and such.

[curaga]

I have to ask, suppose we started automatic nightly extension and core builds. Who would pay for the server and bandwidth?

If you have noticed, we're all volunteers, there are no ads and nothing for sale.

[bmarkus]

Doing a distro is such a thankless task!

But that shouldn't stop us from debating new ways to improve the process, doesn't it?

I do not understand. You are talking about improvement of process, not talking about improvement of TC.

Tell us a single case when current process failed for you when you propesed changes?

[Guy]

I think it would be wise for those already involved, to encourage new people to get involved.

I think people should be able to suggest new ideas, and have them discussed, not automatically reject them, or have any bad feelings (I am not suggesting everyone has bad feelings).

As more people get involved, it will eventually become a good idea to improve the way things are organized.

Why does someone not say? We would like to see you get involved. Things are not organized the way you have been talking about at this stage, but we could discuss ways to improve things in the future.

[cosmin_ap]

I have to ask, suppose we started automatic nightly extension and core builds. Who would pay for the server and bandwidth?

If you have noticed, we're all volunteers, there are no ads and nothing for sale.

Download bandwidth could be free if using mirrors. A few cpus needed for the build server could be supported through donations or someone could volunteer to give a vps or two to spare. We can't know until we ask.

The software would be a build queue that would build extensions in FIFO order in a chroot jail in which only declared deps are tce-loaded. Pushing changes to build scripts through git/hg would trigger a push to that queue.

But let's forget about the server for a moment. I would argue that once you have the software you can ship it as a tcz extension and you wouldn't even need a centralized build server. People could build the core and extensions themselves on their own machines and it wouldn't make any difference to them, _as long as they get exactly the same result every time_. The only difference between core devs and everyone else would be that the core devs can also upload the resulted binaries to the official tce mirrors, while others can only upload to a special "for-review" server.

With both ingredients, that is sources on a svc and automated build scripts, reporting bugs and accessing the fixes would be fast and easy.

[ixbrian]

Is there a "wish list" of features that the team would like to see added to Tiny Core?  If something like this was published, it might encourage more contributions. 

The wish list could also include a section of features that the team specifically does not want included with Tiny Core and the reason why.

Thanks to everyone who works on Tiny Core and makes it such a great project. 

Thanks,
Brian

[roberts]

Tiny Core is already open to community development via the extensions. It was always my plan that via extensions Core would be open to the community. Just look at the number of contributors listed in the repository.

I have brought a difference to Linux distributions with my unique philosophy of frugally functional. That is I created FLTK guis that are very minimal. They are not feature rich. They typically a front end to scripts. Most do not agree with this approach. I say that because I receive mods of my programs that are double to 5 times in size larger by adding features. If I took that approach initially Tiny Core would not be very tiny. I hold firm to this approach. It can be difficult for some who have contributed to the core only to feel that they must add feature after feature and soon what was frugally functionally now try to mirror feature rich as most other distros offer. However that is not the goal. That runs counter to my philosophy. If trying to mirror the features in other distros then Tiny Core is no longer unique.

Not to repeat myself, but via extensions you can have as much feature rich as you desire. You can customize as much as you want. You can have as much eye candy or any other such as you want.

BTW there has not been complaints of unfixed bugs. There are some who claim a bug only to get a feature that they want.

I think I and the team have been very responsive in the maintenance of both extensions and core. As stated we are volunteers. I do not want to involve money.

[cosmin_ap]

Ok, now I get it. You want to keep things tight in the core to avoid bloat/feature creep. Thanks for explaining the background/rationale. Makes total sense.

Having free competing tools maximizes freedom, I dig it. Though I could really use a tool that would get+build any tc extension I throw at it. Having many competing variants of such tool on the repo, each being able to build only a subset of extensions (the ones created with it) kinda defeats its purpose. This, and other infrastructure-like tools could really use endorsing by core devs instead of free competition on the tcz space. One tce-load is enough. One tce-build would also be enough.

[curaga]

No matter the tool or procedure, you can't build every package. Some use standard autoconf, some use just make, some use some esoteric $BUILD_SYSTEM_OF_THE_WEEK, and yet there are many other variants.

If you say "then script it", then what purpose would the tool serve at all?

[cosmin_ap]

If you say "then script it", then what purpose would the tool serve at all?

Recompilation of any extension with one command. This is most useful for upgrading a package to a newer version, which many times requires nothing more than changing the download url and download/build again. This means faster access to the latest version of a package; most importantly, a user could do it himself instead of requesting it on the forum and waiting for the maintainer to do it because only he knows how. Add another command to contribute back the newly built extension, and you could have many more people upgrading extensions. Gobolinux for instance has this cycle automated with two simple commands: NewVersion and ContributeRecipe. There are more use cases but it would make a very long post.

This is how portage (gentoo), Compile (gobolinux), tazwok (slitaz) work, this is nothing new.

But I'm not advocating a bloated build system with compilation "recipes" full of variables for every corner case like these systems have[1]. You can very easily KISS tinycore-style which means *do* script it -- a sh script is much more transparent and hackable than a declarative recipe, and you avoid the necessarily bloated build system required to act on that recipe. So you would still make the same build scripts no more easy or hard than you do now. But the user on the other hand could at any time rebuild, upgrade, contribute back extensions.

[1]http://wiki.gobolinux.org/index.php?title=Recipe_format_specification

[hiro]

I can update any extension I've ever submitted in under a minute, of course I also have my own build system. It takes about 2 minutes to skim through the enormous man page of yet-an-other-exotic-build-system and 10 seconds to adjust the scripts to make it build.

Everyone can create working systems with tiny scripts and nobody has to use any bloated interfaces besides the file system.
Some may want feature havy scripts ready to eat, but I prefer the simple way.
The great thing about tinycore: Everyone can have it their way with the help of extensions.

[cosmin_ap]

I can update any extension I've ever submitted in under a minute, of course I also have my own build system.

I can say the same about my own extensions. However, I can't say it for your extensions as you can't say it for mine. This exactly the itch I want to scratch here.

[hiro]

I don't want other people to compile my extensions. I have put time into it and learned the merits and pitfalls, so I want people to come to me if they have a problem or think they need an upgrade, so that other people will also profit.