[BW-dev-discussion] Dev model (About the idea of release made every X Month

[jeanyves.hegron at laposte.net]

Hello,

@Jose yes, this is a bit of topic, but in fact a very good idea. (Why didn't
we think about this before ?).

I see such a way (planned date for release, frozen one or two weeks before)
a good solution to motivate people and product results. This provide
concrete goals.

This will also reduce the risk of me (or someone else) pushing for having
his latest code to go online at the bad moment (when things are planned it
is better for everything stability/organization)

JeanYves


-----Message d'origine-----
De : bw-dev-discussion-bounces at bewelcome.org
[mailto:bw-dev-discussion-bounces at bewelcome.org] De la part de Jose Aliste
Envoyé : lundi 23 août 2010 17:53
À : BeWelcome Developers Team
Cc : Uwe Federer (Servas); Gary Sealey; Jean-Yves Hégron
Objet : [BW-dev-discussion] Dev model (was Re: Is it important to adopt a
new framework before proceeding?)


Hi,

I am sorry I go   off-topic, but I wanted to point you out that BW
maybe needs a better model for development. I just saw that the
alpha/production/master(trunk) branches have all very different code,
and I guess that the current dev model (based on these three branches)
might be slowing the development since the process of merging can be
painful.

What I would propose for this would be a more "feature-released" based
dev. model. The idea would be to make releases every x months, so,
one, you can make press releases and give  a good publicity of new
features. The basic idea would be to follow Gnome dev. process. This
is as follows:

You code everything on master, there is a "feature Freeze" at some
point, where you stop adding new features and concentrate on testing
the added features and stabilizing the code. Then you have a "Hard
code Freeze" meaning that only approved code can go in. At this point
you create a new branch called (bw-version-of-the-release) and put
that code on the alpha site.
At this point, people that want to add new features can do so in the
master branch, but if you find some bug in the alpha site, you fix it
in the specific release-branch! Once it's stable enough on alpha, you
make the release (which is just chaging some files with the version of
the software) tag the release and you are back to add new features. If
you find new bugs, you always fix them into the release-branch (of
course you also fix them on the master branch, but you don't need to
merge from the master branch to make the bugfix available to the
users).






On Mon, Aug 23, 2010 at 7:11 AM, Peter Lind <peter.e.lind at gmail.com> wrote:
> On 23 August 2010 11:59, Tobias Brox <tobixen at gmail.com> wrote:
>> On 22 August 2010 14:47, Peter Lind <peter.e.lind at gmail.com> wrote:
>>> This avoids a big-bang strategy (one of the most likely risks of
>>> failure for the project) while easing developers in.
>>
>> I don't know much about the bwrox application ... but I agree quite
>> much to that, I've witnesses several failures or near-failures from
>> when the programmers have become fed up with the mess, and tried to
>> reimplement a project from scratch.  The new code will most likely
>> miss some of the old features and will be with more bugs.  The users
>> will see only the drawbacks, not the benefits with the "new and clean
>> code", and the programmers will become disencouraged because the users
>> prefers to run the old code.
>>
>> Then again ... isn't it slightly ironical, that one of the reasons
>> stated why "bwrox sucks" is exactly because one has several times
>> attempted to "switch framework" without fully succeeding with it?
>
> Sort of. There's been one attempted switch, then one attempt to
> repair/extend the framework we switched to. But yeah, one should
> definitely be aware of the possible risks.
>
>> Except for that, I'm quite much against reinventing the wheel.  For
>> me, bwrox seems like "just another social networking site", with some
>> extra emphasize on geolocation.  I would be amazed if there isn't some
>> ready-to-use software in the open source domain that already supports
>> many of the bwrox features out of the box.  Alternatively, for sure
>> there exists many open-source applications supporting one or some of
>> the features we want to deliver, i.e. discussion forums, wikis,
>> calendar, blog, etc.  It could be possible to "stitch together" (i.e.
>> single signon, good cross-linkage possibilities, etc) existing
>> specialized applications and concentrate on the hospitality exchange
>> specifics in our own application?  Well, I do see drawbacks with such
>> solution ... but at least we would gain on it by having almost
>> feature-complete and bugfree subsystems on our site without too much
>> maintenance efforts.
>
> I agree up to a point. It would be nice to just be able to string
> together a number of products and hey presto, system in place. I don't
> believe this is feasible though, for the following reasons:
> - we've already tried it with the ErfurtWiki we use now. It's utter
> crap, we've had to hack it to make it work as we want it to (and it
> still doesn't quite). The main wiki system that one benchmarks against
> is - according to anecdote) - a nightmare to implement into existing
> systems
> - a platform like BW or the proposed cooperation goal is *not* just
> the sum of it's parts. It's not just a forum with geolocation tacked
> on to the outside. It's a forum where the geolocation is a central
> part - and it's geolocation capable of pulling forum threads, member
> profiles, etc into one. Trying to do this with several stand alone
> components will probably result in massive overhead or a nightmare of
> hacks.
> - creating a uniform experience with several stand-alone projects is
> very hard. It will likely be very easy to see that you're now leaving
> the stand alone forum part and entering the stand alone wiki part.
> That's not a nice user experience
>
> That said, the way one might be able to do this is by creating a set
> of thin adapters/facades to the various systems, pull data out of them
> and then present it outside each system, as a unified whole. That
> might be a *lot* of work though - hard to gauge without experience (if
> one could find a forum with a good api, a wiki with the same, etc,
> then it might be easy enough to simply run those systems on their own
> and just extract data from them).
>
> Regards
> Peter
>
> --
> <hype>
> WWW: http://plphp.dk / http://plind.dk
> LinkedIn: http://www.linkedin.com/in/plind
> BeWelcome/Couchsurfing: Fake51
> Twitter: http://twitter.com/kafe15
> </hype>
> _______________________________________________
> bw-dev-discussion mailing list
> bw-dev-discussion at bewelcome.org
> http://bewelcome.org/mailman/listinfo/bw-dev-discussion
>
_______________________________________________
bw-dev-discussion mailing list
bw-dev-discussion at bewelcome.org
http://bewelcome.org/mailman/listinfo/bw-dev-discussion