On 6/24/12 10:49 AM, David R. Morrison wrote: > > On Jun 24, 2012, at 10:17 AM, David Lowe wrote: > >> On 2012 Jun 22, at 2:35 PM, Hanspeter Niederstrasser wrote: >> >>> Buildworlds and dist-wide package roundups (like unstable->stable >>> or multi-package dep upgrades) need a lot of overlapping local >>> modifications and VCS-updating steps, and I stopped trying to do local >>> fixes in the only non-Fink git repo I look at, because there simple >>> local fixes kept getting in the way of easily merging upstream changes. >> >> Even though git is being sold as a plug-in replacement for cvs, it >> shouldn't be approached the same. An ideal workflow in git is to >> immediately create a local branch every time you work on something. You can >> update the master all you want, and the temporary branch shouldn't need >> updating unless the master gets a new patch that you want. The biggest >> difficulty is overcoming old habits… >> > > This sounds great for people writing code for fink-the-program, but I'm still > trying to understand how we would use git to manage our large collection of > fink ".info" files which make up the various "dists" directories. > > The workflow for these has always been that there is a single master > repository, all package maintainers are allowed to update their own packages > within that master repository, and those changes are immediately propagated > to users via the more static rsync selfupdating method. > > It's as if every update by a package maintainer is supposed to trigger a > release, which should include everything from the previous releases as well. > > How should I be thinking about this workflow in a git context? > > -- Dave > >
One advantage is in handling package submissions. Assuming we don't want everybody to have unfettered access, then there are a couple of workflow options: 1) If a maintainer has a github (or other provider) account, then maintainer can update his packages in his/her own master distribution tree or a public branch, and submit a pull request to get the packages validated upstream (by us). The person doing the validation can get the changed package descriptions more or less automatically by switching their active branch to a copy of the submitter's branch. If the package(s) pass[es] then the changes can be merged or cherry-picked into the master branch, pushed upstream, and available via the next selfupdate. 2) Maintainers without such accounts could diff their changes against the upstream (us) master, and submit a patch (via email or on the tracker). The person who validates the submission can apply the patch straightforwardly. I've been _against_ this option in the past, but there are good number of user-friendly tools to make applying patches and viewing changes less of a chore. 3) Or, a maintainer can do individual .info and .patch files, as we've been handling all along. Another advantage is for power users who like to roll their own options. As David L. mentioned, they can keep their own branch active, but still have easy access to any changes from upstream. (basically making their whole branch into the local tree) -- Alexander Hansen, Ph.D. Fink User Liaison My package updates: http://finkakh.wordpress.com/ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
