open development of tinycore

[cosmin_ap]

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.

[curaga]

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.

[cosmin_ap]

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.

[curaga]

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.

[mladen]

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.

[cosmin_ap]

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?

[bmarkus]

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.

[cosmin_ap]

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.

[bmarkus]

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.

[cosmin_ap]

Tip: follow the "?" sign.

[curaga]

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.

[cosmin_ap]

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.

[roberts]

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.

[danielibarnes]

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.

[cosmin_ap]

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.