On Thu, 2011-06-16 at 21:47 +0300, Andrew wrote: > 16.06.2011 21:07, KP Kirchdoerfer пишет: > > hello gents; > > > > Am Dienstag, 14. Juni 2011, 22:40:55 schrieb Andrew: > >> 14.06.2011 22:31, davidMbrooke пишет: > >>> Hi, > >>> > >>> We are getting a few requests for additional kernel modules for 4.0: one > >>> request on leaf-user for asix.ko and I also got a direct request for > >>> r8168.ko the other day. IMHO it would be good to make those available > >>> via version 4.0.1 and maybe later a 4.0.2 etc. > >>> > >>> We also have a large number of fairly major changes (including a kernel > >>> version change) building up in Git. My expectation is those will take a > >>> while to mature, via several Beta releases, and so aren't likely to make > >>> it to "final" release status anytime soon. > >>> > >>> I therefore suggest that we call the next release of the Git HEAD > >>> 4.1-beta1 and then also release 4.0.1 as a "branch" release containing > >>> just *minor* enhancements and bug fixes for 4.0. > >>> > >>> Comments? > > I like the idea. Time to rethink our version strategy we have outlined for > > the > > versions< 3.x > > http://leaf.sourceforge.net/bering- > > uclibc/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=8&MMN_position=8:8 > > > > This approach is coming into age and should be updated, as all of the > > remaining pages needs a review. > > > >>> davidMbrooke > >> IMHO before tagging other versions we should make decisions on some > >> questions on git: > >> 1) In what way we should maintain releases - as branches, or as > >> repositories? 1st IMHO is preferrable when there is not many different > >> branches; > > Andrew; I think for Bering-uClibc we will have less than five branches: > > 1. fixes for the stable version (Davids 4.0.1 branch) > > 2. the development branch (Davids Git HEAD 4.1-beta1) > > 3. a "playground branch" where for example a move to a new kernel or uClibc > > can be tested > > 4. one I forgot yet... > > > > Do you think, that is too much to maintain in branches? > No, this is not much branches. > Main advantage of branches - ability to do 'git rebase' to import all > fixes from one branch into another (for ex., if other branches are based > on stable one) - actually each branch is subset of diffs(patches) that > are applied to first commit. I agree. A few Branches in one Repository are OK (at least for now). dMb > > >> 2) How about reducing directory depth? IMHO it'll be good to move > >> buildtool and binary to the git root - separate directories for projects > >> are meanles for git (for that purposes there are repositories)ю Ьфниу we > >> should bove BuC4 into separete gepository (for ex., leaf/buc4 instead of > >> leaf/leaf)? > > Hmm; I don't have any pb with depth - I'm used to it and it will cause some > > work to change it. I just do not understand what we win changing it - but > > then > > I'm no git expert. Maybe you can explain to a mere git user? > > > IMHO it isn't good if there are meanless directories. At least it > requires more time to change directory :) OK with me to rename the "leaf" repository to e.g. "buc4" and to remove the "bering-uclibc4" level. dMb > > Anway, if you think it's necessary to refine and can provide patches that > > makes > > it seamless, I for shure won't oppose :) > > > > kp > git mv should do all job without problems. If nobody has objections - > IMHO we should move all on top. > > P.S. Should we store compiled packages into git? Maybe there are more > useful places for them (file archive/FTP/etc)? Git is more oriented for > source distribution/versioning...
------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
