On Tue, 14 Jan 2003, Mike A. Harris wrote:
> On Tue, 14 Jan 2003, Vladimir Dergachev wrote:
>
> >I hear that discussion is the foundation of democracy and it seems that
> >devel list is getting quiet again ;)
> >
> >So another suggestion:
> >
> > Mike, what do you think about setting up a separate (entire) tree
> >someplace else like SF ?
>
> I think it would be a very large amount of work for very little
> gain personally. One would have to constantly monitor XFree86
> CVS changes and merge them across. Doing so for a small portion
> of the tree such as a single driver, or for something like
> fontconfig or whatnot would be rather trivial, but doing the
> whole tree would be an amazing amount of work IMHO.
Maybe. On the other hand if one separates out several pieces of the tree
the question comes up whether it would be better to have the whole tree.
Also there is no need to keep current with XFree86 CVS. One could use the
latest released stable version. There aren't that many changes in between,
and definitely ver few radical ones.
>
> Also, while Sourceforge is great for smaller projects, I think it
> is not that great for larger ones. The sourceforge bug tracker
> also leaves a lot to be desired IMHO. Other than that though, I
> think sourceforge is a wonderful tool for open source projects.
I never used SF bug tracker..
>
> >The reason I am thinking about it is that it looks like I
> >finally fixed the problem that GATOS memory controller changes
> >induced in DRI Mesa driver. The fix is simple but it is not
> >likely to merged anytime soon into either XFree86 or DRI trees
> >as it breaks compatibility with older modules.
>
> It might be more beneficial for us to discuss that on dri-devel.
E-mail seems to work better - you seem to be someplace else even though
it says you were idle just a few minutes.
> It might be possible perhaps to provide a mechanism to do both,
> and allow backward compatibility perhaps. Also, if it is
> possible to create a solution that solves the problem and remains
> backward compatible, and the DRI team is happy with it, any one
> of a number of people have CVS write permission in DRI CVS and
> can commit the changes.
I don't know of a good way to be backward compatible.. But there could be
one.
>
> >There are a few more difficult changes that I want to try:
> >
> > * switching from xmkmf to configure
>
> Ick. Sounds like a lot of work for little gain IMHO. A lot of
> people suggest that XFree86 would be better off with autoconf,
> however I disagree for a few reasons:
>
> 1) Imake comes with XFree86 itself, so you _know_ that the
> version of Imake being used is compatible with the XFree86
> source that you are trying to build. Any glitches in the
> Imakefiles are usually (but not always) simple to fix even if
> one isn't an Imake genius.
>
> 2) Personal experience with a fair amount of software that does
> use GNU autotools, is that whenever you upgrade autotools to
> newer versions, a lot of software that used to build before,
> does not build anymore, due to a combination of bugs in either
> autotools or in the particular software's autotool scripts and
> configuration. Fixing these types of issues is a PITA for me,
> and while autotools is a useful thing, I'd rather personally
> avoid autotools while building XFree86.
>
> 3) A conversion to autotools would be quite a bit of work I
> believe, and without core team buy-in to the conversion would
> result in basically a complete fork of the tree which someone
> would have to maintain, and also much more work integrating
> changes.
>
> 4) The amount of work necessary in the above 3, doesn't result in
> an appropriate gain in benefit for making the changes IMHO.
>
* I did say it was a _difficult_ change
* I was not planning on doing it by hand - rather making a tool that
would use Imakefiles as input
* My take on it was that at the very least it would be an interesting
exercise in using autoconf. I have converted a few of my other projects
to it and things do not look that bad.
>
> > * switching Xserver configuration and control from current C code to
> >Tcl/Tk
>
> I think I'd rather get my eyelids pierced with rusty nails
> personally. ;o)
>
* hmm..
* I do think that a lot of setup code even inside drivers could benifit.
This code is typically non-critical
* I did mention it was a _difficult_ change
>
> > I probably won't bother if this is just me, but if you (and/or anyone
> >else) wants another tree for experimentation it could be worth it.
>
> I've got DRI-CVS write privs, and it's possible the DRI guys most
> likely wouldn't mind a branch created in there as long as it had
> a good purpose behind it and they agreed to it first. Other than
> that, I'd probably just use my own local repository.
Good point. Btw, do you know of any tool to merge one CVS repository into
another ?
>
> Why don't you drop by the next #dri-devel meeting on next Monday
> at 2100 UTC on irc.freenode.net. I think the problem that you're
> discussing WRT DRI would be a great topic to chat live with jens,
> keith, et al. and see if perhaps a solution can be determined
> that is backward compatible. If it is possible, it'd save us
> from yet-another-separate-tree, and benefit more people in the
> end I believe. It'd probably also eventually get into XFree86
> CVS.
I've been there on one or two and I missed all the others. The benifit of
the mailing list is that I can check it when I get a free half-hour or so.
With IRC there is always some meeting, seminar or appointment that I need
to be at.
best
Vladimir Dergachev
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
