open development of tinycore

[cosmin_ap]

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.

[bmarkus]

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.

[cosmin_ap]

Is that the TC model, forcing community? This model has a well established name, and a logo, and it's not blue.

[gerald_clark]

It's your proposed TC model.

[hiro]

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.

[mladen]

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.