Re: Some ideas...

[n0g0013 <tt...@co...>]

On 06.02-16:10, Peter �?strand wrote:
[ ... ]
> > from looking at the current state of the repo it doesn't look like
> > we have much anyway.  my impression is that we're simply importing
> > the latest realvnc code and hacking the tight extensions back in.
> 
> Have you actually looked at the code? There's nothing under the "xc" 
> directory that has do to with Tight extensions. Those are in the rfb 
> library. 
> 
> You might think that the code has no value, but RENDER, OpenGL and stuff 
> like that are very important to us. 

yes but not understanding how that relates to the original comment.

[ ... ]
> > i would suggest that we need vendor imports of any code that we intend
> > to merge.  
> 
> Basically, I agree, but all Real versions are already imported under 
> /vendor. I'm not sure if Baracuda should be treated as a vendor, though, 
> since the current plan is to close the project.

i would suggest importing as vendor tree is best irrespective of the
above.

[ ... ]
> > it strikes me as strange that we have no XFree/Xorg code,
> > for example, but i expect this is because we are simply using what
> > realvnc produce.
> 
> Having the X source in the tree is a major pain. It's a very good thing 
> that you can select your own version. 

when you say "select your own version".  i'm assuming that alludes to
the fact that Xvnc appears to compile against base system's X11.
which has me slightly more confused.  i'll need to see the proposed
Xorg diffs to understand this better.

anyway, assuming we do re-use Xorg code, we wouldn't need to import
the entire Xorg tree, only the bits relevant/used.

> > as for the rest of the proccess it really depends on which will produce
> > the fewest code deltas.  lots of small commits may require more
> > branching than a simple baracuda import as well as being difficult to
> > decifer and will not necessarily produce a more consistent or stable
> > codebase.
> 
> I disagree. You don't need to branch just because you are using 
> self-contained, atomic commits. 

indeed but are you disagreeing with the principle?  my comment was
similar to yours, i.e. one metric will not tell us the best way to
merge.

it may be that, upon analysis, it makes more sense to branch, replace
the xc with baracuda code and re-merge the tight extensions.  maybe
not.  let's pull in the vendor branch (baracuda) and branch/merge as
appropriate.

but i think we're on the same page so put me as 0+ to actual decisions
as i'm not knowledgable enough to comment further.

-- 
        t
 t
                 w