[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[hackdaworld] Read carefully this please

hi all
the last time i was doing sth for hdw... the hdw structure wasn't so nice, this might be caused by base implementations... alike, "in architectures and software.. things move around the implemented base".
i am not bothering, and i am not a native hdw developer.. and i ve been apart of this stuff during several months, but what i think is that hdw implemented base was done still with testing purposes. at least last time i left hdw we discused this. hdw needs a new implementation and may cause a different version (cause of substantial changes if these are given).
ive learned that "implemented base" in architectures and massive software is the one which defines complexity in the project. conforming project grows, added stuff is related around of the installed base. and therefore is recommendable (cause of possibly large changes) put new stuff around installed base instead of modifying this one to get rest of stuff working propertly too.
for example.. if i desing a software code model, with an interface which will be the "core" of future implementations (cause this decide how the rest of stuff will work) and i want to add what i will call "objects" or "modules".. might be many of those, i should ensure that those objects will be treated with the same maneer than others.
if suddenly i note that one of the "objects" i want to add doesnt fit the rules to be managed by the "core" section, the best thing i could do is to change "object" model to make it fit in the mode defined by the "core". otherwise, if i modify installed base or "core" part, it's possible that this will produce inconsistent and ugly code, that in fact, doesnt correspond with other object model ive used with the other "objects" already added.
Other solution is the "expensive" and massive morfism, which consist in make change the current "objects" models, to also make them similar to the new code model i am incorporating with this new "object" which is causing confusion. aside, this idea will spend much time and it's common to see that the code of everthing (core and objects) will increase, not so efficient.
the last solution, and not liked by many people.. but fastest one. is the choice of ignoring the code model presented by this new object, and just reject it with its stuff. although it is not a good solution for many people, this could be the best one in environments where those object models are not common and possibly not so important for the complete software specification, and time and money is valuable.
so !
my point here is to demonstrate some way that hdw implementation model is cool by the moment.. but like evolution story.. things change.. and they should mutate to fit new objectives. In this case, with several purposes:
    *     make software developer coding easier
    *     distributed code environment
        -    integrated development around a futurist and open base
        -    new object models which share features decided by base
        -    independant objects themselves and dependant objects for base.
    *    distribution main focuses and purposes. relative to targets too.
    *    current software models for an easier objects fit in the new base.
    *    users
those are strongly my main purposes with the development of a new hdw version. i dont want to see hdw left behind cause a new idea wasnt incorporated cause base implementation didnt allow this. with this i do not mean the current state of hdw is bad. instead, i see beyond.
other thing preocupate me is the amount of developers now working in hdw. i know that most of people who want to help and colaborate with hdw can't dedicate full time to this.. and at least, package maintenance is a hard work.. and this is my main focus when i say this. i thing that if people want to see hdw up-to-day and satisfacing needs .. many hands should be used to make this possible. if u support me... i'll try to get interested people to support hdw.
feel free to critic those aspects:
    *    spend some time making an analysis of current problems and proposes.
    *    list shared characteristics of packages hdw will work on
    *    describe and discuss users, different hdw targets and their promotion
    *    patching and developers source code management in the project
    *    documentation. new users and developers must see this.
    *    code modulation. that what we structured in scripts: "Download","Puzzle","Build".. you know.
    *    complete packages management discussion. this might be the most tedious thing here. how to distribute packages configuration files.
    *    hdw build settings. previous build procedures, build procedures, post build procedures.
    *    hdw install settings. previous install procedures, install procedures, post install procedures.
    *    build settings. how to build hdw. a cool way to make build powerful and efficient.
    *    build stages.
    *    upgrade support. most people like to see systems up-to-date.
    *    system configuration. support users and developers a nice interface to simplify system administration.
    **    there are a lot of other aspects.. i can't remember all of them now.. but i know they will surge with time.
remember i am just another voice and opinion.
i am not saying "good bye hdw"... i am saying "hello hdw.. u will stay a long time with people".
those are aspects i suggest to analize. i am not suggesting now my opinions about implementation, not until things will be discussed.
as i said before with my previous example.. the fastest and cheap solution is to ignore new object models that comes and that things continue as they are.
but i wonder if ignoring new object models and things that grow around will be the best solution. other people are not tied with hdw, hdw should be tied with other people. this is not comunism.
the only thing i ask for is to notify me what u think clearly. i dont ask for anything else.
excuse me for the talk if i am bothering. just giving my opinion as the hdw list if for i guess.