texmacs-dev
[Top][All Lists]
Advanced

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

Re: [Texmacs-dev] Monitoring changes in mainline


From: david
Subject: Re: [Texmacs-dev] Monitoring changes in mainline
Date: Sat, 19 Apr 2003 02:51:24 +0200
User-agent: Mutt/1.5.3i

On Sat, Apr 19, 2003 at 01:19:04AM +0200, Joris van der Hoeven wrote:
> On Sat, 19 Apr 2003 address@hidden wrote:
> > I think it would be nice for those who have an interest in closely
> > following the changes the code base if you could post patches for
> > the changes you make on the source.
> 
> I think that this is really not necessary. The potential benefit is
> certainly much smaller than the administration this requires. I
> think that you are very much exagerating the need for such a thing.
> Don't forget that new releases are quite frequent.

That is essentially the answer I expected. No offense.

As a developer I could use even more frequent releases so changes are
more easily understood and showstopper oopses can be fixed
immediately.

> > Currently my plan is to maintain a public arch repository for
> > mainstream in which I will reverse engineer the changes in
> > mainline. Not really the ideal solution, but that is going to be
> > good enough for experimentation. And anyway I am already doing
> > this reverse engineering work for my own benefit.
> 
> I also regret to see you spending a lot of time on this kind of
> issues. I think that good documentation of the source code and
> working towards a more stable API is far more important. IMHO, your
> focus on live patches and changelogs costs a lot of time which is
> better spent elsewhere.

I agree with all you say here.

I wish I spent less time on reverse engineering new releases, and that
is why I am asking for ideas to make it easier with the minimal cost
on your side.

Anyhow, I am not going to stop monitoring what is going on. Putting
that work in a good revision control system (*not* CVS) just seems the
best way to make it reusable.

Live patches are important, I do need them to do my work. If other
people need them too and contribute to a distributed development
system, everybody win.

<flame>I think that you are very much underestimating the frustration
experienced by contributors to the project. You previously noted that
the linux kernel does not have a CVS, and that contributors submit
patches to the maintainer. Do not forget that the linux kernel has an
insanely branched code base.</flame>

Really, I am not trying to start a flame. I am just looking for ways
to improve everyone effectiveness and avoid uneeded frustration.
--
                                                            -- DDAA




reply via email to

[Prev in Thread] Current Thread [Next in Thread]