On Sat, May 9, 2009 at 23:11, Lukas Renggli <[email protected]> wrote: > I guess you are talking about named branches. This was broken for a > while as people used dots in their initials, but Julien and I provided > patches that are included in recent versions of Pharo. We use > named-branches in Seaside and in various commercial projects > extensively.
Exactly. And of the lack of support from MC Browser or Squeaksource at the user level. I know that each snapshot is a branch, but relying on a naming convention that isn't even enforced kinda sucks (what breaks if I commit MyPackage.initials.42.mcz, but change the file name to foobar.mcz before saving?). In Seaside, you can maintain it because you really pay attention or are used to it and know MC well. > My take on this is the following: If you fork you create your own > branch. It is not the job of people that fork to keep compatible with > the rest of the world or to merge changes back into the main trunk. > Sometimes it happens that original project merges changes from a fork, > but the initiative has to come from the original maintainers. This is > a good read on the topic: <http://producingoss.com/en/forks.html>. Sure, but it's also good practice to announce at least that you do changes, or better send the changes (fire and forget, but at least the upstream maintainers can go through them and follow if they wish). I have friends working for a linux distro and they often complain that some other distro fixes stuff without notifying upstream, so not only upstream is not notified of bugs and fixes, but every distro duplicates some the fixes and misses some others. Since most fixes could benefit to most forks, it's just a waste of ressources and does more against propagating fixes than otherwise. -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
