* [parisc-linux] 2.3 whining
[not found] <387D2F0A.F41A4129@thepuffingroup.com>
@ 2000-01-13 15:43 ` Paul Bame
2000-01-13 16:43 ` Matthew Wilcox
0 siblings, 1 reply; 4+ messages in thread
From: Paul Bame @ 2000-01-13 15:43 UTC (permalink / raw)
To: parisc-linux
A lot of code cleanup occurred and several defects were fixed in 2.2
since the beginning of December. Much of this effort (my effort is
why I'm upset, and some good efforts by John David Angelin too) is now
gone. The dirty code and defects, which *were* fixed, are now holding
us all back in 2.3! Things could've been done better.
When the 2.3 CVS tree was started, it would've been better to copy the
RCS files (and tag the 2.2 ones) instead of checking in a newly-numbered
revision with no past
history attached. Because of the way it was done, it's unnecessarily
difficult to tell which 2.2 file version was used to begin the
2.3 port (because all the versions are 1.1 again), and thus
difficult to figure out which changes need to be re-merged. Also the
comments from the previous authors have been lost in the 2.3 tree.
In going to 2.3 the realmode embedded executable stuff I designed has
been obliterated. I don't know how this was decided but I was not part
of the decision. Even though it might be the right long-term answer,
consequently we now have fragile real-mode C code as we had before, so it
is not a simple matter to re-merge the 2.2 fixes into 2.3
because you're working against the compiler and some other structural
differences, leaving us with a nice mess. (jsm thought up a nice
way to avoid my realmode hack, but I have no incentive to
start coding that to see it disappear too).
If my hacking is unhelpful to palinux, I would prefer knowing
that *before* making changes rather than finding out *after*
doing a bunch of work and watching it disappear.
I'm owed an explanation of why the realmode embedded executable
was wrong for the project and is now gone.
And an explanation of why the defects and improvements
I (and JDA) contributed were wrong for the project too. I'm willing
to learn.
-P
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [parisc-linux] 2.3 whining
2000-01-13 15:43 ` [parisc-linux] 2.3 whining Paul Bame
@ 2000-01-13 16:43 ` Matthew Wilcox
2000-01-13 17:37 ` Paul Bame
0 siblings, 1 reply; 4+ messages in thread
From: Matthew Wilcox @ 2000-01-13 16:43 UTC (permalink / raw)
To: Paul Bame; +Cc: parisc-linux
On Thu, Jan 13, 2000 at 08:43:40AM -0700, Paul Bame wrote:
> A lot of code cleanup occurred and several defects were fixed in 2.2
> since the beginning of December. Much of this effort (my effort is
> why I'm upset, and some good efforts by John David Angelin too) is now
> gone. The dirty code and defects, which *were* fixed, are now holding
> us all back in 2.3! Things could've been done better.
It isn't gone. It's all still there in the 2.2 tree. All that needs to
be done is to move the fixes across to the 2.3 tree. There are plenty of
examples of this sort of thing in regular Linux development. Just ask
Alan; he's moved fixes from 2.0 to 2.2 and is right now moving fixes
to 2.3 from the 2.2 branch. I appreciate it's not a simple process,
but it's a lot easier than tracking down all the bugs again by hand.
I attempted to reinsert some of your changes, but I really didn't
understand the code well enough to do it.
> When the 2.3 CVS tree was started, it would've been better to copy the
> RCS files (and tag the 2.2 ones) instead of checking in a newly-numbered
> revision with no past
> history attached. Because of the way it was done, it's unnecessarily
> difficult to tell which 2.2 file version was used to begin the
> 2.3 port (because all the versions are 1.1 again), and thus
> difficult to figure out which changes need to be re-merged. Also the
> comments from the previous authors have been lost in the 2.3 tree.
The trouble is that doing it the way you suggest was almost impossible.
The only realistic way to get the 2.3 stuff running was to apply the
diff between 2.2.x and the parisc tree to Linus' 2.3 tree which is not
maintained in CVS. As a result, yes, we lost the tags. I did attempt
to explain to you that we can retrieve diffs between any given date that
you want; such as the start of December and now in the 2.2 tree.
Those $Log$ comments are a really bad idea, btw. They grow too long
and contain too much irrelevant crap. If you want to write a comment,
add it manually.
> And an explanation of why the defects and improvements
> I (and JDA) contributed were wrong for the project too. I'm willing
> to learn.
They weren't wrong for the project, they just slipped into a crack.
If I understood this section of the kernel well enough, I would have
added them back before we opened the 2.3 tree.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [parisc-linux] 2.3 whining
2000-01-13 16:43 ` Matthew Wilcox
@ 2000-01-13 17:37 ` Paul Bame
0 siblings, 0 replies; 4+ messages in thread
From: Paul Bame @ 2000-01-13 17:37 UTC (permalink / raw)
To: parisc-linux
My point isn't that we *can* recover, since surely we will. Nor is
it about mechanistic CVS procedures, with which I'm familiar enough
to do date-based diffs and merges.
In *effect* we reverted a lot of code -- trashing our own efforts
without a good reason that I've heard. "Falling through the cracks" is not
something I allow from our caliber of folk. Whenever we revert someone's
code, especially without consultation with them, we make a pretty
clear statement about how much we don't value their effort. AND if
there was value in the lost code, we have a bunch of re-work to do
thus the project loses ground. It hurts the people AND the project.
When I was doing the embedded realmode stuff, which took me quite a
while, I thought it was my duty to continually bring in the changes
others were making to those same files, so that when I committed we
would have the product of all the authors' efforts, not just mine.
The lesson I could take from our 2.3 code reversion is that I
needn't bother eh?
As for $Log$, I abhor using that in source code. But I think the
check-in comments, aka from 'cvs log', are a valuable part of the
authors contribution, and reverting them is just as damaging and
insulting as reverting the code itself.
I can start putting my 2.2 changes back into 2.3, but since I don't
know the reason for their reversion, I really don't have a good
basis upon which to select which features to bring forward and which
to leave. Without the realmode hack some of the features we had in
2.2 can't be coded in C. Should I re-hack the realmode thing or
something which solves the same problem? Will *that* just get reverted
too?
The mechanistic details of diffs and merges are not the issue here.
-P
P.S. I wish we had started the 2.3 port like this:
on puffin.external.hp.com:
cp -r /home/cvs/parisc/linux/arch/parisc /home/cvs/parisc/linux-2.3/arch
cp -r /home/cvs/parisc/linux/include/asm/parisc /home/cvs/parisc/linux-2.3/asm
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [parisc-linux] 2.3 whining
@ 2000-01-13 20:42 Tor Arntsen
0 siblings, 0 replies; 4+ messages in thread
From: Tor Arntsen @ 2000-01-13 20:42 UTC (permalink / raw)
To: Matthew Wilcox, Paul Bame, parisc-linux
I'll leave the rest of the CVS discussions to you guys, however:
On Jun 5, 12:25, Matthew Wilcox wrote:
>Those $Log$ comments are a really bad idea, btw. They grow too long
>and contain too much irrelevant crap. If you want to write a comment,
>add it manually.
This point cannot be stressed enough. $Log$ is an *extremely* bad idea
if you use CVS (it was an ok feature for RCS). Among other things it makes
merges between CVS branches a nightmare: whenever you merge you will get a
conflict in the $Log$ entries which has to be fixed manually, then you
commit the fixed file, which adds *another* $Log$ entry etc.
You will have to manually edit *every single changed file* when you merge,
you lose CVS's otherwise quite good merging capabilities.
It's a good idea to remove any trace of $Log$ whenever you find one
in a file. It will raise its ugly head again in the next merge but
eventually you'll get rid of them.
-Tor
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2000-01-13 21:42 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <387D2F0A.F41A4129@thepuffingroup.com>
2000-01-13 15:43 ` [parisc-linux] 2.3 whining Paul Bame
2000-01-13 16:43 ` Matthew Wilcox
2000-01-13 17:37 ` Paul Bame
2000-01-13 20:42 Tor Arntsen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox