[s1mp3-dev] Project polictics was :Trac and subversion and DSP

Wladston Viana F Filho wladston at gmail.com
Thu Jun 29 20:25:18 CDT 2006 

I think we should look into how successful open source organizations (like
mozilla, rockbox, ipodlinux) works - and stick with a similar way.

I personally agree more with Legolas - usually we work with very nice and
smart people. Wiki is free for anyone to edit - there are some people who
doesn't make things right - but the majority makes nice work. Having an open
wiki has given much more goods than problems. I manage all the changes with
the "recent changes" + "diff/merge" recourse - that is present on  trac too.

Experienced people are invited to put their valuable opinion here...

This is what has been proposed so far. The # marked are the polemic ones:

*People that decide to join the project have the option to join an specific
project team.
*Work will happen trough these teams, doing all the parallel jobs together.

#Each module have its very small group of maintainers with write access
##If someone is working on the module, the maintainer will give him write
access

#All the people accepted on the teams are smart people
##All the team members have write access

**Others could contribute by submitting patches to the mailing list
**The maintainers + people working on the module are responsible by
guaranteeing that the patch isn't dangerous (asking for tests and so) and by
applying it.

Please, everybody, confirm these ideas, and put what is missing on ...

I think we shall now list the pros/cons of each site, and finally make a
decision ...

On 6/29/06, seventh guardian <seventhguardian at gmail.com> wrote:
>
> On 6/29/06, Legolas <legolas558 at email.it> wrote:
> > seventh guardian ha scritto:
> >
> > >On 6/29/06, Legolas <legolas558 at email.it> wrote:
> > >
> > >
> > >>Mateus Del Bianco ha scritto:
> > >>
> > >>
> > >>
> > >>>Hello everybody! Great News!
> > >>>
> > >>>- A long time ago, this guy [_DefToneR_] offered hosting help to the
> > >>>project. Last week we were discussing in the channel and decided to
> > >>>ask him to help, giving us a place to install svn and trac.
> > >>>Today I finished this instalation, and now we have trac and
> subversion
> > >>>for the project! What I still don't now (and maybe wlad could help me
> > >>>with this later) is how should we manage trac/subversion access
> > >>>control. Who should have write access to trac, and who can just read
> > >>>things...
> > >>>
> > >>>
> > >>I propose to give read access to everybody in the world and write
> access
> > >>to the members. I also propose the members to start registration on
> TRAC.
> > >>
> > >>
> > >>
> > >
> > >I opose to the write access: you shouldn't give write access to all
> > >members. That would make maintenance as difficult (or more) as without
> > >svn.
> > >
> > >
> > members = developer members. I expect all our members to be smart
> > people, and write access should be granted to all developers. Consider
> > how lengthy would be to apply a good patch if you don't have write
> > access. The mantainer can always revert the commitments too. I don't
> > think developers will mess up things on purpose and I am sure that the
> > mantainer will review all the changes with the due attention.
> >
>
> No one said it would be on purpose. Things happen mostly by accident,
> the less people actually change the _central code_ the better chances
> that other developpers aren't developing over a buggy code. Also,
> reviewing a patch before commiting avoids having the code all confused
> and wrongly indented. It's very easy to get the code out of hand if
> everyone can change it in a second.
>
> Besides, it's allways better to have the patches reviewed before
> commiting than after, when some other dev is already using the new
> code.
>
> > >Each module (a program or a library) should have its _very_small_
> > >group of maintainers (the creators) with write access, and others
> > >could contribute by submitting patches to the mailing list. The
> > >maintainers would then be responsible by guaranteeing that the patch
> > >isn't dangerous (asking for tests and so) and by applying it. Of
> > >course, if someone is clearly working on the module it should then be
> > >given write access _by the maintainer_.
> > >
> > >It's a matter of creating a "karma based" member list. Since this is a
> > >voluntary project and as usually people come and go, I opose the
> > >creation of a member list. I don't think there should be a permanent
> > >rank of "team leader", or equivalent. Of course, with the exception of
> > >the maintainer of a particular module, which is usually the creator
> > >himself or someone nominated by him.
> > >
> > >
> > I didnt say to keep members lists, I said to split the one we have in
> > teams using TRAC.
>
> Yes I know. But the whole idea of having teams usually means that the
> members should do specific tasks. It defeats the purpose of helping
> where you want. I don't work well under that responsability, at least
> if I'm not paid to :p I prefer helping where I feel like. That's why I
> never signed myself on the original team list. (can someone back me up
> here? Do I hear a "me to"? lol )
>
> >
> > >In our case, we have Wladston already as the wiki maintainer. Jeroen
> > >should be the loadram maintainer, and so on. Accordingly with this
> > >model, these maintainers are allowed to "invite" others to help..
> > >
> > >
> > "invite"? In a free project I would personally consider more the people
> > who do without having been invited to.
> >
>
> Well, they can propose also! Lol..
>
> The less people doing the "dangerous chores" the better, as the others
> can help in the creative side without needing to wory about the
> project intergity. So, having the original writers maintaining their
> software is a logical idea. They "usually know best". Of course if one
> doesn't feel like doing it he can delegate the task, hence the whole
> "invitation" idea. On the other hand, it is a bit unpolite to say "hey
> let me maintain your software".. lol
>
>   Renato
>
> > >Summing up, no one is required to be in a member list in order to
> > >help. Everyone can have their name in the authors list of some
> > >particular module, even if not having svn write access. This way we
> > >avoid the responsability burden of managing a team (the commercial
> > >model). Instead, people manage code/resources.
> > >
> > >This is my proposal, you are allways free to accept it or not..
> > >
> > >Cheers
> > >  Renato
> > >
> > >
> > Regards
> >
> > --
> >   Legolas
> >
> > >
> > >
> > >>>- Alistair is working in a display detection program, so we should
> > >>>have something new to test.
> > >>>
> > >>>
> > >>>- And another thing, for the "DSP team"
> > >>>
> > >>>
> > >>Mmmh...I propose to better organize ourselves on TRAC. Did I already
> say?
> > >>
> > >>
> > >>
> > >>>Who wrote this page:
> > >>>http://www.s1mp3.org/wiki/index.php/ATJ2085_DSP
> > >>>
> > >>>Didn't read this one:
> > >>>http://www.s1mp3.org/wiki/index.php/DSP_file_format
> > >>>
> > >>>If you follow the second-page, you'll notice that the reference
> > >>>instrucions on the first one is wrong. So the decoded instructions
> for
> > >>>DSP56000 are wrong.
> > >>>
> > >>>Also, offset's and lenght's byte order in .dsp file are big-endian,
> > >>>but z80 uses little-endian. I know that Motorola uses
> > >>>big-endian, another point to DSP56000.
> > >>>
> > >>>DSP56000 uses 24-bits instructions too, and there's a lot of
> > >>>development tools available, including a disassemble library
> (lib5600x).
> > >>>
> > >>>Maybe someone could check if the right bytes in file decodes to
> > >>>DSP56000 instructions...
> > >>>
> > >>>
> > >>They actually were written by the same person, the former is older
> than
> > >>the latter, but I cant see the problem with the second page, which
> > >>specifies a proprietary file format interpretation
> > >>
> > >>
> > >>
> > >>>**
> > >>>**
> > >>>
> > >>>*Mateus M. Del Bianco*
> > >>>Del Bianco Networks
> > >>>
> > >>>
> > >>--
> > >>  Legolas
> > >>
> > >>
> > >>
> >
> >>>------------------------------------------------------------------------
> > >>>
> > >>>_______________________________________________
> > >>>s1mp3-dev mailing list
> > >>>s1mp3-dev at s1mp3.org
> > >>>http://s1mp3.org/mailman/listinfo/s1mp3-dev_s1mp3.org
> > >>>
> > >>>
> > >>>
> > >>>
> > >>_______________________________________________
> > >>s1mp3-dev mailing list
> > >>s1mp3-dev at s1mp3.org
> > >>http://s1mp3.org/mailman/listinfo/s1mp3-dev_s1mp3.org
> > >>
> > >>
> > >>
> > >
> > >_______________________________________________
> > >s1mp3-dev mailing list
> > >s1mp3-dev at s1mp3.org
> > >http://s1mp3.org/mailman/listinfo/s1mp3-dev_s1mp3.org
> > >
> > >
> > >
> >
> >
> > _______________________________________________
> > s1mp3-dev mailing list
> > s1mp3-dev at s1mp3.org
> > http://s1mp3.org/mailman/listinfo/s1mp3-dev_s1mp3.org
> >
>
> _______________________________________________
> s1mp3-dev mailing list
> s1mp3-dev at s1mp3.org
> http://s1mp3.org/mailman/listinfo/s1mp3-dev_s1mp3.org
>



-- 
Wladston Viana Ferreira Filho
Belo Horizonte - MG, Brasil
Visit the project: s1mp3.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://s1mp3.org/pipermail/s1mp3-dev_s1mp3.org/attachments/20060629/02915aa2/attachment-0001.htm

More information about the s1mp3-dev mailing list