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
