Albrecht Schlosser <[email protected]> wrote: > Greg Ercolano wrote: >> Gerry Weaver wrote: >>> Greg: >>>> I think that as you start into coding, those folks will weigh in, >>>> so be ready for that. Take your time putting it all together, and >>>> that way it will allow some time for everyone to become familiar >>>> with what you're proposing. >>> [..]I guess one of my major concerns would be the initial reaction >>> to the first pass APIs. Unless a person followed the forum >>> threads, they wouldn't really understand what that is all about. [..] >>> damn the torpedoes I guess ;-). >> >> Indeed; I think just take a small piece on, submit as a patch, >> and see what the response is. >> >> Maybe a good approach would be to attack some existing bug >> that can be fixed by rewriting a small portion of the low level >> code using the new FLA interface. This would show the direction >> things are going, and would set an example, then slowly take on >> larger parts of the code. >> >> This would be a kind of 'slow motion' change, but in the end >> might avoid having to create separate branches that have to later >> be carefully merged back into the maintenance stream. > > I'm not absolutely sure about it, but I would prefer a different branch for > starting the FLA upgrade. I don't think that an incremental update would be > possible, and this would ((maybe)) make the code unstable. OTOH, having a > different branch would enable interested developers to review the code and > even > to participate in development. Something like Fabien did before he added > basic > Cairo support to the mainstream. > > I can also see the problem if this approach takes a longer time to merge the > changes later, but I think that this would be much better because it wouldn't > block development (and release !) of FLTK 1.3.0. > > What I would do: > > Step 1: create a development branch, e.g. branch-1.3-fla > > Step 2: add all necessary code to this branch, but don't merge mainstream > changes until a "milestone" is reached. This will enable developers to see > the > changes in the FLA branch without seeing mainstream updates. Diffs will be > much > better to interpret. We can always test the branch independent of mainstream > changes. > > Step 3: When a milestone is reached, decide what to do: > > (3a) either the changes are okay to merge back to mainstream, then do that, > or > > (3b) if the changes are not yet okay to be merged back, then merge > mainstream > changes into the FLA branch. > > Step 4: start a new development cycle (go to step 2). > > Note: this would imply that Gerry (or his team) would need development access. > > That's just my opinion, but I think that the main point is that this can all > be > done independently of each other, and that we can incorporate changes when we > are confident that it will work as intended. And if it doesn't, nothing needs > to > be removed again.
I'm just an fltk user not a developer, but I also wanted to make some invasive changes to an existing project some time ago. I chose to import the existing tree into a DVCS (mercurial in that case, but git would have worked just the same). Then I started hacking without needing commit access or in-repository branches. Developers could easily track my progress in my public mercurial repository and merging upstream changes was easy. Once the prototype was in shape it was imported into the main repository (the project actually switched to mercurial at that point, but that's a different story). Cheers, Johannes _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
