Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: cosmin_ap on June 30, 2011, 08:12:38 AM
-
Hi,
I'd like to open this discussion regarding the open development of TC/MC with some questions to the core devs. By open development I mean a development process that allows, tracks and coordinates user contributions. For starters:
1) putting everything in source control in separate projects: kernel, base scripts, GUIs, tools, extensions, etc.
2) use a bug tracker to coordinate bugs and feat requests and track changes
3) automatic build of tinycore.gz/microcore.gz (and .iso) on each commit (or nightly) to allow immediate access to bugfixes and beta features
4) develop extension building tools (eg. see tcztools.googlecode.com) to allow users to rebuild extensions automatically
So are the core devs interested in opening up the development of TC/MC? If yes, can we start thinking about ideas such as the ones above? I am willing to contribute to any one of them in whatever time I got. Free tools like googlecode and github etc. could be considered too to help with some of these points.
So what does anyone think?
Cosmin.
-
For 2), we initially decided against a mailing list and a bug tracker because a forum is much friendlier. I'm still of the same opinion.
4), we already have several, competition is good. I would not want to force a one-size-fits-all solution. Such would eventually grow out of bounds to handle all corner cases, and would still not be suitable for every package.
-
Regarding friendliness, both a bug tracker and the forum present a list of topics where you read/write messages and get notified when a topic is updated. So how does a forum differ in friendliness from a tracker? Sure, there are bad complicated trackers out there, but also very good ones (eg. the googlecode tracker).
But regardless of the difference in friendliness, the tracker serves a different purpose than a forum. The tracker is a coordination tool between developers, so that each contributor knows who's working on what at the moment, and along with a source versioning tool, also manages releases (i.e. which fixes are done in which version -- you also get a changelog for free).
For instance, I would like to contribute to tinycore myself, but I have no clue who is fixing what right now, and without source versioning and a bug tracker I have no way of finding that out. How would someone contribute code in absence of these basic coordination tools?
So initial question stands: are the tinycore devs interested in adding more devs to the project, i.e. opening up the development process? It's fine if they aren't, question answered, topic closed. But if they do, let's find out what is needed for this.
-
From my POV, a tracker is for users to report bugs. That doesn't happen if they are turned off by the tracker front page, required to register yet another account, etc.
IMHO, direct VCS output makes for terrible, terrible changelogs ;)
I'll let others comment though.
-
In my opinion tinycore team is doing excelent job not only regarding a quality of product, but also from metodology aspect.
Philosophy of tinycore system must not be changed, unless we want to convert it to something else !
Functionality and size of tinycore.gz/microcore.gz does not need a greater team of active developers. I think that automatization of any part of development process for tinycore.gz/microcore.gz will not give benefits.
If I have any idea for improvement of tinycore.gz/microcore.gz I will submit it to the forum, and if it can improve any aspect of tinycore I am sure development team will allow me to contribute.
-
So everything's in apotheotic state already and as such opening the dev. of tc can only make things worse, not better.
Say I report a bug today, when will I be able to access the fix? If it's quicker for me to just fix it locally would I even bother to report it? For what benefit? How do you measure the loss of input (bug/feature reporting/fixing) from people who just don't bother because there is no process in place to acquire their input? The only question is: do tc devs consider additional dev. involvement welcome or are they self-sufficient?
-
svn/git, tracker, etc. are just tools which may or may not fit to the actual development and communication method, work style of developers and they are not for themselve.
Current communication solution is working, fast and efficient, core team is responsive and ready to discuss and accept ideas, proposals. If not, there is a reosanable explanation why.
Let core team decide how to work. It is their baby.
-
Guess my message was misunderstood. I wasn't in anyway trying to change how the core team is working. As already stated a few times already, the first question is whether they need additional dev. input or not. If the answer is a straight "no, thank you", then the other questions are of no consequence.
-
Guess my message was misunderstood. I wasn't in anyway trying to change how the core team is working. As already stated a few times already, the first question is whether they need additional dev. input or not. If the answer is a straight "no, thank you", then the other questions are of no consequence.
You were talking about these tools and not about ideas, proposals related to TC/MC, see original post.
-
Tip: follow the "?" sign.
-
The only question is: do tc devs consider additional dev. involvement welcome or are they self-sufficient?
Of course more help is welcome. But you seem to be conflating it with a specific dev style, they are two separate issues to me.
If you find something broken or in need of improvement, post saying so. If nobody's on it, post patches, etc.
-
If you find something broken or in need of improvement, post saying so.
For what benefit would I do that? If I have to wait for two months to access the fix, why would I bother, when it would be much quicker and less painful to silently fix it for myself locally and go on with life? Now, sure, if I could just commit the fix painlessly and then just wait another day for the snapshot build, it would be an entirely different matter and anyone would benefit. There's a threshold of effort/pain one is willing to accept for any task, and as you noted yourself (when you mentioned the tracker fronted page), many times it's quite thin.
If nobody's on it, post patches, etc.
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?
If you tell me these issues are just a matter of development style, then sorry for the noise, I'll throw myself outta here.
-
Our development style has been and is working fine. I see no need to change.
I have been using this style for the past nine years (over two Linux distributions).
You come across as "if I don't get my way" then "I won't participate".
That is, of course, your choice.
-
the first question is whether they need additional dev. input or not.
To add to the other comments, not only do they ask for it (that is the purpose of RC releases), but I have always found Robert and team very helpful and responsive. That's a rare thing.
it would be much quicker and less painful to silently fix it for myself locally and go on with life
Typically, yes. Many of us do just that. If it's a general fix or I think it might be of value to someone else, then I humbly post it to the forum. That's the current process. Basically, you are looking for a formal development environment. I'm sorry if what you've found doesn't meet your needs (like nightly builds), but as Robert just said, it truly is possible to do quite a bit with what we are provided. Maybe all of the things you mention will happen someday, but it isn't there yet.
Most of all, have fun with what you find and just enjoy being part of the project. I know I do.
-
You come across as "if I don't get my way" then "I won't participate".
That is, of course, your choice.
Whether I choose to contribute or not is of no relevance. I wasn't taking about me and what I want. Statements like this add no value to the discussion.
Our development style has been and is working fine. I see no need to change.
Glad to see your approach is of an open mind :) That effectively closes the subject.
-
You can please some of the people some of the time...
Doing a distro is such a thankless task!
-
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.
-
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.
-
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.
-
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?
-
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.
-
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.
-
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
-
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.
-
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.
-
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?
-
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
-
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.
-
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.
-
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.
-
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.
Making people dependent on my own availability is not my idea of open source.
-
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.
See, the key point is just to destroy the whole TC model, forcing community. There are no need to wast time for such trolling, wanting to have benefits of others investment without partitipating and giving back. A well known mentality, unfortunately.
It's a shame.
-
Is that the TC model, forcing community? This model has a well established name, and a logo, and it's not blue.
-
It's your proposed TC model.
-
Making people dependent on my own availability is not my idea of open source.
Bullshit, everyone is still free to compile what he wants on his own.
-
At the beginning cossmin_ap started with:
" 3) automatic build of tinycore.gz/microcore.gz (and .iso) on each commit (or nightly) to allow immediate access to bugfixes and beta features"
and
" So are the core/devs interested in opening up the development of TC/MC? "
In recent discussions, extensions are dominant subject.
Are we talking about opening a development process for tinycore.gz/microcore.gz or for extensions ?
I think that optimization of development process for those two subjects can not use the same criteria.
Automatisation of development process with:
" 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..."
and increasing the speed of recompilation will not improve quality of tinycore.gz/microcore.gz in any aspect.
Let discuss functionalitys we would like tinycore/microcore to have and why, how it affect size, speed and reliability of the package - this is also a part of development process, even more important than the speed of compilation of tinycore.gz!.
Dynamics of appearing new release candidates is higher than for some other comparable distributions, steps between them are not revolutionary what is good IMO ( suppose you will understand why).
Criteria and arguments are different when we speak about extensions and their repository and :
" 4) develop extension building tools (eg. see tcztools.googlecode.com) to allow users to rebuild extensions automatically"
are intriguing and can be useful.
Ah yes, one thing more.
Does TC model has to be blue ? All colors cosmin_ap is talking about on 07/03/2011 have dirty and bright versions, so I would suggest that we exclude political discussions from this place because it will not help us in any way.