Hi, Derrell!
[EMAIL PROTECTED] wrote:
> Andreas & Sebastian,
>
> I hope all of the changes to 'namespaces' are going well.
Yes, it is being stabilized, so expect an announcement pretty soon.
> In the future, I think it's important that the process for this kind of
> massive change be accomplished very differently than it was this time:
There's plenty of room for improvement as well as discussion...
> 1. There should be discussion on the mailing list about what's proposed,
> rather than making unilateral significant decisions. This is a team
> project, and the team should be involved in major decisions. (I don't have
> a good idea of what all of the changes are that are being made and I
> believe that I should.
Yes, you are absolutely right, the development should be made as
transparent as feasible. While we both share the same opinion in many
aspects of qooxdoo development, I think we sometimes have different
ideas of what the practical level of transparency is. ;-) Anyway, I
value the input and feedback of yours a lot to further improve the
development process.
Often it is very hard to know beforehand where exactly any proposed
changes will lead to. Sometimes changes start out as rather neglegible
modifications but then get bigger for a reasonable solution. There is
hardly any ad-hoc implementation in qooxdoo. Most development steps are
commonly discussed and agreed upon between at least two developers to
raise code and feature quality. Many proposed changes or improvements
are made public on the mailinglist or bugzilla before any real
implementation starts to allow for other people's input.
It is impractical for some tasks to start a discussion on the mailing
list. Those cases should be clearly seen as exceptions and will
certainly decrease as the developer base increases. Some tasks simply
need fast decisions at any critical situation and it is not acceptable
to pause implementation (time shifts make this worse). For sure, qooxdoo
is JavaScript development at the bleeding edge, so pace is high.
For some other tasks commonly involving deep understanding of various
core features or critical internal changes, it is also impractial to
have a in-depth discussion first. We will try to have those cases down
to a minimum. Still, we need to have the communities' and fellow
developers' support for and trust in our work. Complex tasks often
require actual tackling and trial and error rather than purely a prior
discussion. We work on transparency, but please bear with us. ;-)
> I've tried to follow the check-ins in order to keep
> up-to-date. I'm not thrilled, for example, about the extra levels of
> directory structure that have been added; the paths were already quite
> long, and the new structure just adds to that without any real benefit. In
> any case, I would have liked to have had some input into this whole process
> before the work began.)
Nobody loves either longer class names (see feedback for namespaces
branch) or a deeper file structure _per se_. Often it is not a matter of
personal likes or dislikes (that could sparkle a lot of discussion). It
often comes as a necessity in any sufficiently complex framework.
We are all open minded, so any critisism and feedback is welcome. We
certainly try to convince people rather than to have them simply accept
the facts, and are open to be convinced as well.
> 2. When a change is occurring which causes this much disruption, the branch
> being modified should be copied to a new, temporary branch, the changes
> made, and then the temporary branch overlayed on the original. For
> example, in this case, 'namespaces' would have been copied to something
> like 'namespaces-to-trunk-changes' and the changes done there. Once the
> changes were complete, they'd be copied back to either 'namespaces', or
> replace 'trunk' (or both).
Agreed, it could have been done that way. But it did not have to. It is
a development branch after all, and as I mentioned above, it was not
expected that the actual modifications would take so long. It has been
announced that the branch will be unstable for several days and how
people could still use the previous revision.
> 3. I commented on this once before, but I'll mention it again. SVN check-in
> messages should have sufficient detail to explain what's going on. A
> message that just says, "minor changes" or "renamed" is useless to anyone
> else who's trying to figure out what is changing or to discover by
> reviewing the log later, when a particular change occurred. (This comment
> applies to these massive changes, but also to every-day changes.)
>
> BTW, there's no reason that numerous changes, all doing the same thing to
> different files, need be separate check-ins. A single check-in with a
> reasonably detailed message such as:
>
> Change image paths to use the singular forms "image" instead of "images",
> and "theme" instead of "themes" for consistency. All paths are now in
> the singular form.
>
> would have been much easier to follow than the numerous check-ins, first of
> the Image class, then of a few examples, then of a few tests, then...
This particular problem is caused by flaky Subversion moves ("svn mv").
Unfortunately it is not stable at all. :-( We have had many errors with
commits of multiple changes done at once. The only solution was to
revert all changes and do a fresh checkout of the affected folders. Not
a very productive way to work. So we have to do the svn mv one by one.
Since the intermediate results were of no interest, the svn comments
were rather short. In general all developers should try to be as verbose
as reasonable in terms of svn comments. You're certainly a role model
here. ;-)
> The discussion suggested in comment 1 will likely yield a better design, given
> the input of more people. The process in comment 2 will allow the repository
> to continue to be useful both to the developers not involved in the massive
> change, and to new users. (This is particularly true as we already have a
> steady influx of new people checking out the code from svn, and that influx is
> likely to continue and increase as time goes by.)
You have to break an egg to make an omelet, right? :-)
A development branch does not have to be stable at any time. That is
also true for any snapshot of the trunk. A trunk from KDE also doesn't
compile successfully each day, for example. That a development branch is
so attractive for newcomers will change once qooxdoo 0.6 is generally
available. We're getting closer...
> Keep up the good work!
qooxdoo owes you a lot for your contribution, collaboration, well, and
patience,
Andreas & Sebastian
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
