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.
>> 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 :) > 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
