Some ideas...

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Some ideas...

Adam Tkac
Hi all,

I have some general ideas what will be done in trunk unix branch very
soon

1. start using automake and libtool in build process
  - source code will be more portable

2. svn cleanup, keep only files whose are necessary (so only
   Makefile.am and configure.ac will be located in svn, noting else)
  - repository will look better, "bogus" is not needed there (scripts
    whose are generated etc.)

3. remove unix/xc subtree and create unix/xserver tree and use Xvnc
   codebase from baracuda project
  - it's logic way if we want Xvnc based on xorg instead XFree

4. revise RH patches and port them to TightVNC if needed
  - why don't fix already fixed bugs :)


Do you have any hints/arguments what else should be done (or not
done)?

Regards, Adam

--
Adam Tkac, Red Hat, Inc.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas...

ttw+vnc
On 05.02-19:38, Adam Tkac wrote:
[ ... ]
> I have some general ideas what will be done in trunk unix branch very
> soon

without being very familiar with with repo i'd suggest that it's a
little hodgepodge at the moment (too many branches and not all that
logical).  we may wish to take this opportunity to revise the
general structure as well as branching and merging procedures.

for item "3" (merging baracuda into the mix) we need to make ensure
the above is correct.  if that is relatively well defined it sounds
good to me.

as to the other points.  +1 FWIW

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas...

astrand (Bugzilla)
In reply to this post by Adam Tkac
On Tue, 5 Feb 2008, Adam Tkac wrote:

(I'm using the Python voting scheme from
http://www.python.org/dev/process/)

> I have some general ideas what will be done in trunk unix branch very
> soon
>
> 1. start using automake and libtool in build process
>   - source code will be more portable

+1. Pure Autoconf + libtool is also very much better than Imake. One
    argument (?) for staying with only Autoconf is compatibility with the
    Real version, but Automake is also nice, OTOH.


> 2. svn cleanup, keep only files whose are necessary (so only
>    Makefile.am and configure.ac will be located in svn, noting else)
>   - repository will look better, "bogus" is not needed there (scripts
>     whose are generated etc.)

+1. I've been trying to keep the repo fairly clean, but perhaps some
"bogus" was introduced when Constantin migrated to the new dir structure.



> 3. remove unix/xc subtree and create unix/xserver tree and use Xvnc
>    codebase from baracuda project
>   - it's logic way if we want Xvnc based on xorg instead XFree

About the name: xc is no longer used in modular Xorg? In that case, I'm
positive to a rename.

How much different is the directory layout in the modular tree? We want to
preserve as much history as possible, so perhaps a SVN rename can be used?

Of course, we also wants to preserve our actual work done on the xc tree.
The current diff is 2104 lines; not unmanagable, but some files (such as
programs/Xserver/vnc/Xvnc/xvnc.cc) are heavily modified. We want to make
sure that we don't introduce any regressions. Things like RENDER, OpenGL
etc must work with the new Xorg as well.

I don't like the idea of "importing" the baracuda codebase. That won't
give us any history. If we reject the method of renaming "xc" to "xserver"
and working from there, I think we should instead use an approach like
this:

* Copy the unmodified 4.1.2 source to the "xserver" directory.
  (svn copy
  https://svn.sourceforge.net/svnroot/vnc-tight/vendor/realvnc/current/unix/xc ...)

* Adapt to modular Xorg using your (small, well-defined) patches, from
  Baracuda.

* Port everything from the the existing "xc" tree, again using atomic
  well-defined patches. To get the diff between our xc and the 4.1.2 one,
  you can use:

  svn diff
  https://svn.sourceforge.net/svnroot/vnc-tight/vendor/realvnc/current/unix/xc 
  https://svn.sourceforge.net/svnroot/vnc-tight/trunk/unix/xc

* Then, delete the xc tree.

What do you think of this?


> 4. revise RH patches and port them to TightVNC if needed
>   - why don't fix already fixed bugs :)

+1.


Regards,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.se
Wallenbergs gata 4
583 30 Linköping Phone: +46-13-21 46 00
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas...

ttw+vnc
On 06.02-10:37, Peter �?strand wrote:
[ ... ]
> I don't like the idea of "importing" the baracuda codebase. That won't
> give us any history. If we reject the method of renaming "xc" to "xserver"
> and working from there, I think we should instead use an approach like
> this:

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.

i would suggest that we need vendor imports of any code that we intend
to merge.  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.

i would like to see 'orig/*' move into some meaningful branches
or vendor trees.

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.

basically, i think you're metrics for the process are based on weak
assumptions and we need better management of the repo first.

p.s: i realise i'm writing this "from the hip" and hope it doesn't
come off rude.
--
        t
 t
                 w

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas...

Constantin Kaplinsky
Hello all,

>>>>> n0g0013 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.

It's already based on the latest free RealVNC code (despite version
numbers that can be obsolete -- I'll fix that), and has support for
TightVNC extensions.

> i would like to see 'orig/*' move into some meaningful branches
> or vendor trees.

The orig/* tree should not be used for this project (porting the code to
x.org). Just ignore orig/*.

> 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'd prefer small incremental commits to current trunk/unix/xc code (of
course it's ok to rename the directories if needed).

The primary rule is the following: ideally, each commit should be
represented by an easily-readable diff. Anything I can't easily read and
understand is bad. :)

Also, I'd like to ask not to change anything outside trunk/unix/xc tree
without notifying me first. I need to keep certain things consistent
under trunk/common/ and trunk/unix/ (notably, x0vncserver).

--
With Best Wishes,
Constantin


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas...

astrand (Bugzilla)
In reply to this post by ttw+vnc
On Wed, 6 Feb 2008, n0g0013 wrote:

> > I don't like the idea of "importing" the baracuda codebase. That won't
> > give us any history. If we reject the method of renaming "xc" to "xserver"
> > and working from there, I think we should instead use an approach like
> > this:
>
> 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.


> 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.


> 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.


> i would like to see 'orig/*' move into some meaningful branches
> or vendor trees.

I agree, it's confusing. Constantin, what's the purpose of the orig/ tree?


> 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.

Again, it's not just about size, as in number of lines. It's about
meaningful and understandable patches. Bad commit:

"Many changes, merged the Baracuda project".

Good commit:

"Adopting build environment from Imake to Autoconf"

or

"Adapted RENDER support for the modular Xorg, based on revision XYZ"


Rgds,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.se
Wallenbergs gata 4
583 30 Linköping Phone: +46-13-21 46 00
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas...

ttw+vnc
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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas...

ttw+vnc
In reply to this post by Constantin Kaplinsky
On 06.02-21:03, Constantin Kaplinsky wrote:
[ ... ]
> > i would like to see 'orig/*' move into some meaningful branches
> > or vendor trees.
>
> The orig/* tree should not be used for this project (porting the code to
> x.org). Just ignore orig/*.

understood but wouldn't it be better to move "orig/*" into correct
branches / tags? i assume truck was branched from orig somewhere or
was it branched from realvnc 4?

> > 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'd prefer small incremental commits to current trunk/unix/xc code (of
> course it's ok to rename the directories if needed).
>
> The primary rule is the following: ideally, each commit should be
> represented by an easily-readable diff. Anything I can't easily read and
> understand is bad. :)

i think we're saying "easy" but really mis-representing the word and
VCS procedures.  having numerous small commits does not necessarily
make things easier or better.  it may also make the codebase less
stable as far as building and testing go.

"correct" procedure (IMHO) is to branch and merge.  then we can
review the small commits while leaving current in coherent state.
people can also easily follow a branch or wait and merge from current
when branches come back to mainline.

of course, it would be best to discuss branches before doing them.

--
        t
 t
                 w

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas...

Constantin Kaplinsky
In reply to this post by astrand (Bugzilla)
Hello Peter,

>>>>> Peter Åstrand wrote:

> I agree, it's confusing. Constantin, what's the purpose of the orig/ tree?

It includes the code for current stable versions. It's not a branch or a
vendor tree -- it's a completely separate codebase.

We'll get rid of the confusing directories some day, but not right now.

--
With Best Wishes,
Constantin

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas...

Constantin Kaplinsky
In reply to this post by ttw+vnc
>>>>> n0g0013 wrote:

> it may be that, upon analysis, it makes more sense to branch, replace
> the xc with baracuda code and re-merge the tight extensions.

That's a bad way to go. Moreover, I'd say it's unacceptable. There
should be no "replacements", it should look like a sequence of small
incremental changes.

Also note that TightVNC extensions have nothing to do with the the
unix/xc subtree, they are in common/rfb.

--
With Best Wishes,
Constantin

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas...

Adam Tkac
In reply to this post by Adam Tkac
On Tue, Feb 05, 2008 at 07:38:54PM +0100, Adam Tkac wrote:
>
> 1. start using automake and libtool in build process
>   - source code will be more portable
>

Ok, I have some free time so I've rewrited current Makefiles and
configure to be more portable. My work is located on
http://people.redhat.com/atkac/tightvnc-autotools.tar.bz2. It contains
configure.ac and Makefile.ams. Build process is now much more simplier
and portability should be increased. I've merged common and unix
subdirectories (because it doesn't make sence to have two configures
because always when you building stuff in unix you need rfb library).
You will build tightVNC on your systems with those commands:

$ autoreconf (you need automake, autoconf and gettext installed)
$ ./configure
$ make

those things were done
- general cleanup
- better detection of system libz/libjpeg libraries (fully automatical
  now)
- I've dropped unix/intl subdirectory because it doesn't make sence
  try build translated messages on systems whose doesn't support it
- all is now compiled with -Wall and -Wextra (we will find strange
  statements with those options)
- fixed some missing includes and added #include <config.h> where
  needed

Minor patches whose are needed for correct build are attached

Any feedback is welcomed

Regards, Adam

--
Adam Tkac, Red Hat, Inc.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas...

Constantin Kaplinsky
In reply to this post by ttw+vnc
>>>>> n0g0013 wrote:

> understood but wouldn't it be better to move "orig/*" into correct
> branches / tags?

No, it would be better to leave it as is. ;)

> i assume truck was branched from orig somewhere or
> was it branched from realvnc 4?

No. It has no direct relation to the trunk/ code.

> having numerous small commits does not necessarily
> make things easier or better.

For me, it does.

--
With Best Wishes,
Constantin


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas...

Adam Tkac
In reply to this post by ttw+vnc
On Wed, Feb 06, 2008 at 04:46:56PM +0000, n0g0013 wrote:

> > > 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'd prefer small incremental commits to current trunk/unix/xc code (of
> > course it's ok to rename the directories if needed).
> >
> > The primary rule is the following: ideally, each commit should be
> > represented by an easily-readable diff. Anything I can't easily read and
> > understand is bad. :)
>
> i think we're saying "easy" but really mis-representing the word and
> VCS procedures.  having numerous small commits does not necessarily
> make things easier or better.  it may also make the codebase less
> stable as far as building and testing go.

As far as I know small changes are better when we are talking about
stability. Patch review process is easier with small and well defined
patches.

>
> "correct" procedure (IMHO) is to branch and merge.  then we can
> review the small commits while leaving current in coherent state.
> people can also easily follow a branch or wait and merge from current
> when branches come back to mainline.

It is good procedure when you're using decentralised VCS, each
developer could have his own branch, do what they want and when things
work in his branch he will merge it to main branch. With svn is this
procedure possible but it doesn't mean it is good.

Adam

--
Adam Tkac, Red Hat, Inc.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas...

Adam Tkac
In reply to this post by astrand (Bugzilla)
On Wed, Feb 06, 2008 at 04:10:47PM +0100, Peter Åstrand wrote:

> On Wed, 6 Feb 2008, n0g0013 wrote:
>
> > > I don't like the idea of "importing" the baracuda codebase. That won't
> > > give us any history. If we reject the method of renaming "xc" to "xserver"
> > > and working from there, I think we should instead use an approach like
> > > this:
> >
> > 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.

As far as I know it works well with modular X codebase.

>
>
> > 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.

Definitely, it doesn't make sence import baracuda to svn. It's nearly
same source as trunk.

>
>
> > 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.
>

In the one hand is good have X source in project because uneducated
users can simply compile it. But on the other hand it needs some
manpower to maintain it. Final decision should be based on fact if
tightvnc is more used by OS vendors (then don't adopt X code) or by
common users (adopt it)

Adam

--
Adam Tkac, Red Hat, Inc.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas...

ttw+vnc
In reply to this post by Constantin Kaplinsky
On 06.02-22:52, Constantin Kaplinsky wrote:
[ ... ]
> It includes the code for current stable versions. It's not a branch or a
> vendor tree -- it's a completely separate codebase.
>
> We'll get rid of the confusing directories some day, but not right now.

understand and respect you may not have time for house keeping
right now but would like to say, just because it's a separate
codebase doesn't mean it can't be left in an orderly system under
"branches" and "tags".

--
        t
 t
                 w

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas...

ttw+vnc
In reply to this post by Adam Tkac
On 06.02-18:07, Adam Tkac wrote:
[ ... ]
> > "correct" procedure (IMHO) is to branch and merge.  then we can
> > review the small commits while leaving current in coherent state.
> > people can also easily follow a branch or wait and merge from current
> > when branches come back to mainline.
>
> It is good procedure when you're using decentralised VCS, each
> developer could have his own branch, do what they want and when things
> work in his branch he will merge it to main branch. With svn is this
> procedure possible but it doesn't mean it is good.

branching and merging is critical and normal under any decent VCS.
the centralised / decentralised is not relevant to the usefulness of
branching.

in fact, branching should allow me to create numerous small commits
that will be well logged / traceable while still merging back to
trunk with a useful subset of code.

--
        t
 t
                 w

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas...

ttw+vnc
In reply to this post by Constantin Kaplinsky
On 06.02-22:59, Constantin Kaplinsky wrote:
[ ... ]
> > it may be that, upon analysis, it makes more sense to branch, replace
> > the xc with baracuda code and re-merge the tight extensions.
>
> That's a bad way to go. Moreover, I'd say it's unacceptable. There
> should be no "replacements", it should look like a sequence of small
> incremental changes.
>
> Also note that TightVNC extensions have nothing to do with the the
> unix/xc subtree, they are in common/rfb.

which is exactly the point really, it should merge back seamlessly
and we would end up with the following.

- import baracuda code
- branch "trunk" to "branches/tight-1_5-xorg"
- replace 'xc' with xorg mods from baracuda import
- (other changes and commits)
- merge back to current (with no conflicts of course! ;-)

of course if adam is saying that the baracuda code is easier to merge
as individual patches then we'd drop item 1 and change item 3 above
to a series of commits.

anyway, i'm well over my 2 cents at this stage.

--
        t
 t
                 w

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas...

Adam Tkac
On Wed, Feb 06, 2008 at 05:46:09PM +0000, n0g0013 wrote:

> On 06.02-22:59, Constantin Kaplinsky wrote:
> [ ... ]
> > > it may be that, upon analysis, it makes more sense to branch, replace
> > > the xc with baracuda code and re-merge the tight extensions.
> >
> > That's a bad way to go. Moreover, I'd say it's unacceptable. There
> > should be no "replacements", it should look like a sequence of small
> > incremental changes.
> >
> > Also note that TightVNC extensions have nothing to do with the the
> > unix/xc subtree, they are in common/rfb.
>
> which is exactly the point really, it should merge back seamlessly
> and we would end up with the following.
>
> - import baracuda code
> - branch "trunk" to "branches/tight-1_5-xorg"
> - replace 'xc' with xorg mods from baracuda import
> - (other changes and commits)
> - merge back to current (with no conflicts of course! ;-)
>
> of course if adam is saying that the baracuda code is easier to merge
> as individual patches then we'd drop item 1 and change item 3 above
> to a series of commits.
>
> anyway, i'm well over my 2 cents at this stage.
>

As I told above I think I don't need branch for such changes. I'm
going to create patches whose will be acceptable by you and send them
there. Btw question is if you (or we? :) ) are going to support old
XFree servers or only newer modular X

Ada,

--
Adam Tkac, Red Hat, Inc.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas...

Adam Tkac
In reply to this post by astrand (Bugzilla)
On Wed, Feb 06, 2008 at 10:37:45AM +0100, Peter Åstrand wrote:

> > 3. remove unix/xc subtree and create unix/xserver tree and use Xvnc
> >    codebase from baracuda project
> >   - it's logic way if we want Xvnc based on xorg instead XFree
>
> About the name: xc is no longer used in modular Xorg? In that case, I'm
> positive to a rename.
>
> How much different is the directory layout in the modular tree? We want to
> preserve as much history as possible, so perhaps a SVN rename can be used?
>

modular X tree is quite different, it is more flat. It looks like:

xserver -- configure.ac
        |
        -- Makefile.am
        |
        -- hw -- Makefile.am (all servers are located here, in hw
              |               subdirectory)
              -- vnc -- Makefile.am
                     |
                     -- all sources from xc/programs/Xserver/..
                        (xvnc.cc should not be in Xvnc subdirectory)

You will see source tree yourself :)
$ git clone git://anongit.freedesktop.org/git/xorg/xserver xorg-server-1.5


> Of course, we also wants to preserve our actual work done on the xc tree.
> The current diff is 2104 lines; not unmanagable, but some files (such as
> programs/Xserver/vnc/Xvnc/xvnc.cc) are heavily modified. We want to make
> sure that we don't introduce any regressions. Things like RENDER, OpenGL
> etc must work with the new Xorg as well.

Definitely, I'm going to patch TightVNC sources

>
> I don't like the idea of "importing" the baracuda codebase. That won't
> give us any history. If we reject the method of renaming "xc" to "xserver"
> and working from there, I think we should instead use an approach like
> this:
>
> * Copy the unmodified 4.1.2 source to the "xserver" directory.
>   (svn copy
>   https://svn.sourceforge.net/svnroot/vnc-tight/vendor/realvnc/current/unix/xc ...)
>
> * Adapt to modular Xorg using your (small, well-defined) patches, from
>   Baracuda.
>
> * Port everything from the the existing "xc" tree, again using atomic
>   well-defined patches. To get the diff between our xc and the 4.1.2 one,
>   you can use:
>
>   svn diff
>   https://svn.sourceforge.net/svnroot/vnc-tight/vendor/realvnc/current/unix/xc 
>   https://svn.sourceforge.net/svnroot/vnc-tight/trunk/unix/xc
>
> * Then, delete the xc tree.
>
> What do you think of this?
>

Best will be straightforward approach:
1. create unix/xserver/hw/vnc/ directory
2. copy all sources from unix/xc there (as I wrote above I prefer flat
   structure so all sources/headers will be in vnc directory)
3. then I'm going to create Makefile.am for Xvnc and small patch for x
   source (will be used directly from baracuda)
4. in the end I will start creating small patches to make Xvnc
   compilable

With this approach we don't miss any your change and we potentially
don't bring any regression

Adam

--
Adam Tkac, Red Hat, Inc.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas...

astrand (Bugzilla)
In reply to this post by Adam Tkac
On Wed, 6 Feb 2008, Adam Tkac wrote:

> > 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.
>
> As far as I know it works well with modular X codebase.

If possible, please verify this. We have added some extra VNC hooks, so to
me, it seems unlikely that RealVNC 4.1.2 will support this without
patches, no matter what kind of Xorg version is used.


> > 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.
>
> Definitely, it doesn't make sence import baracuda to svn. It's nearly
> same source as trunk.

Good.


Regards,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.se
Wallenbergs gata 4
583 30 Linköping Phone: +46-13-21 46 00
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
12