Am Donnerstag, 16. Juni 2011, 20:47:41 schrieb Andrew: > 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_p > > osition=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.
ok, so we'll follow David's proposal. > >> 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. What will change for my local git? What has to be changed in the docs? > 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... PLS don't change it! The current release process is the work of day; and it relies on the binaries being in git. I do not want to deal with file archive or ftp on SF more than necessary. kp ------------------------------------------------------------------------------ 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
