On Wed, Apr 3, 2013 at 9:37 PM, Peter Koželj <[email protected]> wrote:
> If I understand things correctly we need to get code grant regardless of > the license. > In that case the willingness of authors to give them is more important than > current license. > I discussed the issue of the code grant with the plugin author this evening and he's not willing to sign the document. He has given me full control to develop the plugin wherever and in whatever ways that I see fit, but he has "no interest in entering legal arrangements with the ASF". I have no idea why that is, but I feel that I will make no progress in changing his mind by continuing a discussion of the matter with him. > Technology wise, I would vote for solution that is not tied to particular > relation type on the database > and application layer (on the other hand, some per relation type UX > optimizations are probably desired). Getting from system-only provided > relation types to user-defined ones is then a small step. I had in mind that we would redefine the database schema after merging the MasterTickets and Subtickets plugin code, and primarily try to utilize the existing application layers from the MasterTickets and Subtickets plugins. My progress wrt to the MasterTicketsPlugin is: - Imported the code history from GitHub to the Trac-Hacks SVN. - Resolved the issues that had been reported on GitHub and several of the issues on trac-hacks. There have been several individuals interested in having issues fixed and testing the changes so I have been working to resolve some of the more serious issues. - The codebase is close to being ready for a new release, but I will wait to get feedback on two tickets before proceeding with that. I think there is a pretty serious problem with the design of the database layer. If you look through the open and recently closed tickets, you will find numerous issues that seem to be due to the database getting into an inconsistent state. I have spent some time trying to understand and fix issues with the database layer in `model.TicketLinks.save` and can't say that I understand why it is so complex and fragile. I started noticing a lot of these issue while working on (1). I will try to get my work-in-progress MasterTickets/Subtickets integration pushed tomorrow, and look forward to continue the discussion of how we should proceed. I had hoped we could fix the existing plugins since they are used so widely by the trac community, but the possibility of pushing the changes back directly to the Trac core seems nice to. I currently have more than 20 patches pending in the Trac core, with many of them "scheduled" for integration, so I'm not overly optimistic that whatever we push to Trac will be readily integrated. If anyone want w-access to the trac-hacks repository, please just send along your trac-hacks username. (1) http://trac-hacks.org/ticket/10194
