Re: Ten years later
- From: "rhyde@xxxxxxxxxx" <rhyde@xxxxxxxxxx>
- Date: 5 Mar 2007 06:54:16 -0800
On Mar 4, 9:20 am, Betov <b...@xxxxxxx> wrote:
Sure. And where you will not even need the fix will be with
real bugs fixes, as long as, on one hand, nobody ever wrote
and will ever write anything real with your absurd HLL, and,
on the other hand, you are not at the point where one more
bug, or one bug less, could make any difference, would it,
clown?
When I first read this unparsable English, I think that I mistook what
you were trying to say; particularly as your main point was completely
obfuscated by your inability to make a point without attacking HLA in
every sentence.
On further reflection, I think that what you're trying to say is that
maintaining a branch of FASM will not be easy because of changes to
the trunk (original) version and those changes will not get folded
into a branch such as the one I'm creating. That being your original
intent, all you've done is, once again, demonstrate your inexperience
with modern software engineering practices.
I realize that *you* think that "community development" consists of
having one "dictator in charge" accept all the changes and put those
changes into the "one and only copy" of the software. In your model no
branches can exist because your model provides no way to conveniently
maintain consistency across branches. This mode of software
development flew out the window decades ago when it became apparent
that it doesn't scale up to medium sized system much less large scale
systems.
Just to educate you a little bit, there are software development tools
that make maintenance of a branch fairly simple. Consider my
particular project. I'm working with the FASM v1.66 branch (which I'm
porting over to HLA source format). So let's say that I am successful
and I get FASM v1.66 working under HLA. By the time I finish this,
let's say that the main branch of FASM has reached v1.70. Okay, how do
I find all the changes so I can roll them back into my branch of the
code? Easy. I use a tool such as "Beyond Compare" or "Araxis Merge"
to compare the FASM v1.70 source code against the original (FASM
source) v1.66 source code that I started with. Now I just evaluate
those differences (and generally there aren't too many between
versions) to determine which ones I want to fold into my branch. Now
I save the v1.70 source code for use as my baseline compare against
future FASM releases.
Short of a major addition (e.g., the inclusion of the x86-64
instructions), it rarely takes more than a couple of hours to
integrate new version changes into a branch. And major additions, such
as the x86-64 stuff, probably wouldn't wind up in my branch anyway, as
HLA wouldn't take advantage of the stuff.
Assuming I do a reasonably faithful translation from FASM source code
to HLA source for FASM v1.66, the same process can be used in reverse
to back-port changes from my branch to the main trunk. That is, once I
get an HLA version working reasonably well, I take a snapshot of the
source code to use as my baseline. After some period of time (and some
number of changes) I can run one of those differencing programs on my
source code and note all the changes that have been made. I can then
communicate those changes to whomever is interested (should there be
an interest).
I realize that this is all new stuff to you because you're not
familiar with modern software development techniques, but rest
assured, the process is not as difficult as you believe it to be.
Cheers,
Randy Hyde
.
- Follow-Ups:
- Re: Ten years later
- From: Betov
- Re: Ten years later
- References:
- Ten years later
- From: Betov
- Re: Ten years later
- From: rhyde@xxxxxxxxxx
- Re: Ten years later
- From: Betov
- Re: Ten years later
- From: rhyde@xxxxxxxxxx
- Re: Ten years later
- From: Betov
- Ten years later
- Prev by Date: Re: FASMLIB 0.5.0 is out
- Next by Date: Re: Ten years later
- Previous by thread: Re: Ten years later
- Next by thread: Re: Ten years later
- Index(es):
Relevant Pages
|
