[s1mp3-dev] Trac and subversion and DSP

Thu Jun 29 15:19:55 CDT 2006

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
>