Re: [leaf-devel] bering-uclibc source tree
On Wednesday 27 November 2002 19:41, Mike Noyes wrote: > On Wed, 2002-11-27 at 14:31, Erich Titl wrote: > > 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) > > I'm not quite grasping your meaning here. Please elaborate. > > > 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. > > Correct. It is up to the release/branch lead developer and team > members to incorporate these extensions/patches. I expect people that > repeatedly provide useful additions would be asked to join the team. Well, if nobody minds too much, I'll add a few comments since I have a few spare moments. Right now, there exists CVS for certain packages, Oxygen, and Uclibc. The parts that pertain to *stein and Bering for the most part are unavailable in a CVS access. This has not been a problem in that most of the core packages for *stein and Bering are not updated and require versioning. To make the source available for many of these packages will require atleast one of three options: 1) Dig through the old LRP SRC tarball and update it to LEAF SRC CVS. 2) Have the individual developer who compiled the program copy the SRC directory on their personal box to LEAF SRC CVS. 3) Locate the proper version of the SRC code and duplicate/update the makefile and upload it to LEAF SRC CVS. Simply put, this NEEDS to be done. I am more than willing to do this myself, but I will definately not have the time until after the first of the year unless someone else wants to start work on it earlier. By having this done, this provides accordance of licensing, easy availability, and a good form of versioning as many of these programs are/should be updated. This also clearly differentiates between the different versions available for LEAF, which could easily become a problem with upcoming image releases/versions. The largest problem I see is getting all programs into CVS there are many little packages to get in there. It would also make things easier if developers want to update/change certain parts of these packages. a check of the PacketFilter changelog shows a huge amount of changes and rework of POXINESS scripts and similar programs. After this is done, then there can be branch updates of these programs via CVS by the lead developer(s). Those submitting changes to these programs outside of the release group should use the patch manager. Everyone simply cannot have access to the release CVS. Development can be done within the branch, but there should be a note stipulating which CVS version of each program is used within a release. I personally see this as the clearest method to work into the new releases that are now becoming available w/o watching the current problems snowball into a huge mess. I know this will require a lot of time to get up, but I don't see a better idea at this time. Any thoughts??? -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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
Re: [leaf-devel] bering-uclibc source tree
On Wed, 2002-11-27 at 14:31, Erich Titl wrote: > At 22:42 27.11.2002, Mike Noyes wrote: > >On Wed, 2002-11-27 at 12:50, Erich Titl wrote: > > > 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? > > 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. Erich, In my opinion endorsed means the developer uses the tree to generate releases. Or, in the case of bering-uclibc K.P. approached Jacques and asked permission to use the bering name for a uclibc based tree. > > > 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. To ensure we're talking about the same things, I have these two definitions: cvs branch == a cvs function 5. Branching and merging http://www.cvshome.org/docs/manual/cvs_5.html#SEC54 release/branch == LEAF project release/branch (e.g. Bering, Dachstein, Oxygen, WISP-Dist, PacketFilter, Lince). > This 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). I agree wholeheartedly. > 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. Correct. (see note at bottom of post) > 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) I'm not quite grasping your meaning here. Please elaborate. > 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. Correct. It is up to the release/branch lead developer and team members to incorporate these extensions/patches. I expect people that repeatedly provide useful additions would be asked to join the team. > 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. Are you talking about LEAF releases/branches or cvs branches? Also note: not all of our releases/branches derive from the same root. > But all this is at of course the discretion of the lead developers. > > OK, I hope I have not insulted anybody. Not in the least. I find this type of discussion stimulating. :-) > Folks, please use my CVS, and fix my bugs on the way ;-) I second that. Note: it is possible with our cvs_acls script to give write access to certain sections of your personal tree to other project members. -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- 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
Re: [leaf-devel] bering-uclibc source tree
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... > 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? 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. > But without his consent to allod/include modifications to the > 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. This 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) 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
Re: [leaf-devel] bering-uclibc source tree
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. > 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 the > 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. Currently, there are three preferred ways to handle patches. One, they can be submitted in our SF patch manager. Two, the person with the patch can be added to the release/branch team, and given write access to the team source tree in cvs. Three, provided the person is a LEAF project member, the patch can be committed to their personal tree in our cvs repository. The least desirable method is direct submission to a lead developer, as there is no way to track the submission. -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- 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
Re: [leaf-devel] bering-uclibc source tree
Mike & List Mike Noyes wrote the following at 17:28 25.11.2002: Everyone, 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. 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. But without his consent to allod/include modifications to the tree such a venture is near to pointless. 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. Just my 2c 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
[leaf-devel] bering-uclibc source tree
Everyone, 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. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/src/bering-uclibc/ http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/src/oxygen/ Note: project members should subscribe to our leaf-cvs-commits list. https://lists.sourceforge.net/lists/listinfo/leaf-cvs-commits -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
