Hi, I spent some time reading the mailing list and irc logs. Because of the distributed nature of the communications channels, the discussion is difficult to follow if you are not at the right time in the right place.
What follows is a summary of the ideas floating around as I understood them. It may help us make a decision or maintaining the discussion constructive. I haven't put names (or source urls) in this summary because of the extra time needed (that I don't have) and because, at the end, it doesn't really matter. Incompleteness and misunderstandings on this document are my responsibility and I'll be more than happy to correct them. Several developers feel that Padre is at a point where some stability is expected. While this is extremely good news for a young project like ours, it also means that "fast moving target" releases from the beginning are --or should be-- behind us: users rely on our project to do their work. Also, Padre is now released by third parties (e.g. GNU/Linux distributions) where a specific Padre version is included and only security enhancements are accepted afterwards. A broken or sub-par padre version is damaging for future adoption. While everyone seems to agree on principle, it has been remarked that it may be appropriate to postpone the move to a more conservative release management when we hit the 1.0 version in the near future. A new Release Process will explicitly take into account the time needed by Release Managers (release notes, announcements, etc) and translators (freeze of strings). A proposed solution is the creation of a stable (or release) svn branch, something possible within present infrastructure. An alternative is moving to github which seems to make merging easier. Both propositions would also mark the shift to a more controlled development model where branching and code reviews would be required. We should also invest time in running manual GUI testing while researching automated alternatives at the same time (e.g. litmus). Experimental branches and freezing of branches could be integrated in these approaches. New features should be first implemented as plugins and -when mature- possibly merged into core. Besides the classic "1 feature, 1 plugin" approach, there is the proposition of an ExperimantalFeatures plugin to lower the code effort. However, it has to be noted that this will made the merging effort more complicated. Nevertheless, additions and changes of the Padre plugin API are needed because the many things that plugins are not able (or allowed) to do yet in Padre. A often heard remark is that we all want to reduce the number of bugs and release a stable Padre while not making development too complicated. The codebase must be accessible and understandable to many Padre developers. Documentation and and planning will help in this endeavour. On what concerns the development (team) model, a proposition was put forward to restrict the core developers team to the more experienced developers (like PostgreSQL) and limit this way the introduction of new bugs. The counterargument, on the other hand, is that keeping the threshold low to participate in Padre development may reduce the workload of leading developers. New of less experienced developers can take care of more trivial bugs and enhancement requests, specially taking into account that Padre itself is written in Perl where every user --a developer!-- is a potential Padre developer. Claudio _______________________________________________ Padre-dev mailing list Padre-dev@perlide.org http://mail.perlide.org/mailman/listinfo/padre-dev
