9 replies to this topic

[pscEx]

In this post olegpov asked to publish the source code of two mini-apps which made troubles at the user.

I considered a long time before I posted the code.

The reason was not that I wanted to hold 'my' secret. (The code was not my possession, it has been written by other members and posted anywhere before)

The reason was, that I'm afraid of this scenario:

The code is published, and several members find some improvements, implement them and publish.
After a while we have a collection of 'original-code-childs'.
They are downloadable from different servers. Unfortunatelly the apps are different, too ...
(See the 'Common Tools' discussion in a different topic)

Therefore I would prefer not to publish such small aps here.
But they are not a secret. If anybody wants, he / she can get the sources by PM.

What do you think?

Peter

[Brito]

There is a good solution.

Use a project repository on google: http://code.google.com/hosting

People can download the source code and binaries and update the code using subversion.

A simpler in-house solution would be using a shared folder on dropbox like it was done for wb's documentation. Easier to use than SVN.

[was_jaclaz]

People can download the source code and binaries and update the code using subversion.

Sure they can.

Point that peter is raising seems to me: will they?

Or the result will be a "version nightmare"?



jaclaz

[MedEvil]

Or the result will be a "version nightmare"?

You mean like with all the different Linux?
I consider that an improvement and nobody stops one from going back to Debian.

Our problem with stuff like that is not the branching, but that we have so few developers, that any branching usually means veeeery slow development and that the projects die rather quickly.

[was_jaclaz]

You mean like with all the different Linux?

Yep, though I was thinking more at tools like mkisofs.exe, or the actual (at least for me) completely ununderstandable situation of "our own" Winbuilder .scripts/projects .

Our problem with stuff like that is not the branching, but that we have so few developers, that any branching usually means veeeery slow development and that the projects die rather quickly.

That is another BIG problem, yes.



jaclaz

[Brito]

I consider that an improvement and nobody stops one from going back to Debian

Well.. you might notice a lot of different linux'es going about but the vast majority is concentrating their eyes on Ubuntu and this is bringing very good results.

Yep, though I was thinking more at tools like mkisofs.exe, or the actual (at least for me) completely ununderstandable situation of "our own" Winbuilder .scripts/projects

The situation is not so ununderstandable. People work on scripts or projects according to their willingness.

That's as much as one can request, we do make an effort on ensuring that critical components aren't left on the hands of a single developer to avoid stagnation but sometimes it's not possible to avoid this situation or convince developers to follow a more organized way of working as a team.

[was_jaclaz]

The situation is not so ununderstandable.

The situation IS ununderstandable (for me at least).

Any normal member would, when approaching Winbuilder for the first time, try to understand what options there are, and this kind of info is almost, but not quite, completely unlike existant or findable.
Once he/she has spent some time and has hopefully gathered that there are several different main projects, he/she will start searching for them (not so easy, if you put yorself in "dumb" mode and try doing it).
Then it finds out that each app needs a .script, and that there is no practical way to find such a .script.
Then he/she is lucky and actually finds the actual .script, only to find out that:

• it does not work with the Winbuilder release he is using
• it does conflict with another .script he is wishing to use
• it does have a dependency (undocumented) from another .script

Of course in the meantime the "dependent" .script has been updated and is not anymore compatible with the "main" .script or with the Winbuilder version that is needed for yet another .script, and the "old" version has been removed or expired on the free-hosting-site where it was uploaded or whatever.

The exception being of course "monolithic" "pre-assembled" projects like LiveXP, which is what most people will finally use, once found that the "right" path is impossible to follow.

What I expected (and I am still expecting ) from Winbuilder and boot-land is a "better" BartPE, not a number of ("better" or "worse" it doesn't matter) UBCD4WIN's.

These:

People work on scripts or projects according to their willingness.

That's as much as one can request, we do make an effort on ensuring that critical components aren't left on the hands of a single developer to avoid stagnation but sometimes it's not possible to avoid this situation or convince developers to follow a more organized way of working as a team.

are the causes of the situation, and I can understand them all right .



jaclaz

[MedEvil]

What I expected (and I am still expecting ) from Winbuilder and boot-land is a "better" BartPE, not a number of ("better" or "worse" it doesn't matter) UBCD4WIN's.

I would be very very happy, if we could have half the amount of developers that the BartPE system had.
But we don't.

So saying you want our PE to work like BartPE did, is like saying, you want Haiku to have the amount of 3rd party software available that windows has.
Ain't gonna happen unless the numbers change drasticly.
Which i don't see happen.

[pscEx]

Sorry all!

Maybe I'm stupid, but in the last posts I miss any relation to my question ...

Peter

[was_jaclaz]

Maybe I'm stupid, but in the last posts I miss any relation to my question ...

You are right.

Back to OPQ:

What do you think?

There are historically and logically TWO working (and each with it's own drawbacks and merits) development models:

• centralized
• collaborative/distributed

#1 works, but is limited by the amount of resources the "central" (and only) programmer can pour into any given project
#2 works, it is as well dependent, besides the "central" resources, on the amount and "quality" of the "satellites" gravitating around the still needed "central" core AND needs organizational protocols to avoid duplicates, conflicts and simply have things working smoothly

As I see it Winbuilder is a "mixed environment" which results in having all the drawbacks of both the above and only a few of the advantages.

My personal advice is, in the specific case:

• post anyway the source CODE
• let's see what happens, in the worst case we will have, exactly as we already have for all the rest, a bit of chaos in these few apps also (a drop in the sea)

jaclaz