Mike At 22:42 27.11.2002, Mike Noyes wrote:
On Wed, 2002-11-27 at 12:50, Erich Titl wrote: > Mike Noyes wrote the following at 17:28 25.11.2002: > >The bering-uclibc team is making good use of our cvs repository. We now > >have two release/branch source trees under construction in cvs. > > > >Other LEAF release/branch lead developers please take note of these > >source trees. I'd like to see more of this. > > Looks like the uclibc is quite a homogeneous group, so they could agree on > the model. Or maybe the lead there just decided to go that way.Erich, How project members reach decisions internal to a team is up to the lead developer. You would have to ask K.P. how the bering-uclibc team decided on a structure for its source tree. Since David is the only team member for Oxygen, he created its structure.
I agree wholeheartedly...
The important word IMHO is _endorsed_. What is the canonical way for this endorsement? I doubt Linus Thorvalds still manages his own kernel CVS tree.> With the > consent of the lead developers of each branch it should be possible to > build a tree which does not necessarily have to be maintained by the lead > developer. I don't think so. By definition a lead developer is in charge of the release/branch purpose and direction. Aren't both lost when abdicating source tree control? I believe a release/branch source tree in our repository not endorsed by it's lead developer would be a new release/branch?
> But without his consent to allod/include modifications to theThis is true and that is why I personally favour an open tree. CVS is a wonderful tool for distributed development. Unfortunately this tool is IMHO not used to its full potential in the LEAF community (which you pointed out in the mail which triggered this thread). For example in my little CVS tree I am the only one doing anything. If someone spots an error in something I did, he can easily get the code, modify it, and make a _redundant_ copy in his own CVS tree. Reporting this back to me is a compulsory thing. I might not spot the same error for a long time, continuing on my erroneous way and someone else might later on find the same error again at nauseam. If I understand CVS correctly that is not the way it was meant to be. CVS allows concurrency and conflicts. What is done with the various branches of a tree is something which can be dealt with at release time (by of course the lead developers or someone charged with the release task)
> tree such a venture is near to pointless.
Agreed.
> Maybe we could invite the lead developers of the various branches to mirror
> their respective cvs tree(s) to a public place where it is possible for the
> other developers to make branches/modifications which eventually would be
> either rejected or make it to the base. Of course this might change the
> development cycle a little.
I'd like to avoid numerous cvs branch creations in our repository.
Merging multiple cvs branches is a significant challenge.
It is even less if someone just adds a little (hopefully not harmful) extension to a part of the software. Unless this extension makes its way to the base distribution it remains in its niche at the developers private tree. For example if I look at the ulibc Bering distribution they certainlly keep parts of Bering as it is, as Jaqcues and Erik kept parts of Dachstein. Some improvement made in a new branch may not find its way back to its predecessor because they are living in different trees in the same forest. Alike development in the main branch requires merging with a foreign CVS tree to make its way to the new branches. This IMHO leads to redundancy.
But all this is at of course the discretion of the lead developers.
OK, I hope I have not insulted anybody. Folks, please use my CVS, and fix my bugs on the way ;-)
cheers
Erich
THINK
Püntenstrasse 39
8143 Stallikon
mailto:[EMAIL PROTECTED]
PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16
-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
