On 2/12/2011 10:09 AM, Claudio Ramirez wrote:
>
> 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.
Yes, especially if one is not part of IRC discussions.
> 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.
I am one of the users who could try Padre but hasn't
yet for several reasons including:
(1) My main platform is cygwin and I have not
been able to install Padre for that platform.
I'm not motivated to learn a new IDE for only
a subset of my perl usage platforms
(2) If the basic architecture and structure of
Padre is in constant flux: working, not working,
changing user interface, unclear or out of date
documentation, that is a barrier to potential
new Padre users.
(3) The "quick start" options to get Padre up on
the web page seem to be out of date and/or
incomplete.
The two things that would most help me try/use/develop
with/for Padre include:
(1) up to date, simple installs of the latest Padre
(1-click or less :-) for all the Perl platforms
(win32, *ix, macosx, cygwin),
(2) up to date, clear and directly accessible docs
from the Padre web page
A side benefit of the very easy install availability
is that the fact that Padre is still growing and
evolving would not be as much of an obstacle for
folks to try it along the way. Once it was clear
that Padre evolution had slowed and that growth
and maturing was mostly happening, that would be
the time for introducing a "stable" branch.
Regards,
Chris
> 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
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1204 / Virus Database: 1435/3435 - Release Date: 02/10/11
>
>
_______________________________________________
Padre-dev mailing list
Padre-dev@perlide.org
http://mail.perlide.org/mailman/listinfo/padre-dev
