[Yanel-dev] New toolbar (using superfish) doesn't use full width re menu items on IE

baszero at gmail.com baszero at gmail.com
Fri Jan 28 07:56:10 CET 2011


I would suggest to clean up the house before building a new one:

- somebody must take the lead in patch tracking / appliance
- create a component in Bugzilla so that patches can be easily found in Bugzilla (and interested people get notified automatically upon changes of their patches)
- move all patches available in EMails to Bugzilla
- analyze which patches must be applied immediately and which ones can be postponed (maybe tracked in the new system)

Cheers


_____________________
CTO
www.zwischengas.com

Sent from my iPhone
My latest Fotos: 
http://tinyurl.com/lm2010pics

On 28.01.2011, at 00:13, Michael Wechner <michael.wechner at wyona.com> wrote:

> On 1/27/11 11:57 PM, Cedric Staub wrote:
>>> This doesn't scale!
>>> 
>>> So what can we do about this?
>> The first problem is that sending patches around by mail requires a lot
>> of work just to track the patches themselves, e.g. what they do, where
>> they apply, who wrote them and so forth. We need a tool that allows to
>> us/you to track patches consistently.
>> 
>> Now we just have Subversion and Bugzilla, but the developers have to do
>> all the bookkeeping. We generate patches in Subversion manually while
>> having to make sure we don't mix changesets from two different features
>> that are in concurrent development. Then submit them to Bugzilla, and if
>> the patch needs improvement re-generate it again. And if we want to test
>> a patch, download and apply it manually and so forth.
>> 
>> We need to optimize the workflow and reduce the bookkeeping. All of
>> those things should be automatic, the developer shouldn't have to spend
>> time on tedious tasks like this.
>> 
>> My suggestions:
>> 
>> 1. Switch to a distributed version control system. That way the
>> development of new features can be split into "branches", allowing new
>> features to be developed in isolation which makes it easier to deal with
>> them. This also makes it easier to test new features from other
>> developers, because you can just test their branch while leaving your
>> code untouched.
>> 
>> 2. Install a patch/issue tracker that integrates with the version
>> control system. This makes it possible to automatically link commits and
>> issues, discuss changes, perform code reviews, send pull requests, and
>> lots of other stuff.
>> 
>> I hope that's realistic enough ;-).
> 
> definitely, and I agree with you, whereas I hear "Mercurial" ;-)
> 
> We are investigating Mercurial and actually have been offered some great help by Martin Geisler.
> We are currently exporting our public SVN to test a migration (Maybe you want to talk to Simon), but to be honest I am not sure yet if it really will help actually solve the problems discussed above.
> 
> I would suggest let's simulate the toolbar example based on your suggestions above in order
> to find out what problems it will solve and which other problems will need to be tackled differently.
> 
> WDYT?
> 
> Thanks
> 
> Michael
>> Just my two cents,
>> Cedric
> 
> -- 
> Yanel-development mailing list Yanel-development at wyona.com
> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development


More information about the Yanel-development mailing list