Hi Felipe, |--==> On Sat, 22 Nov 2008 15:15:16 -0300, Felipe Sateler <[EMAIL PROTECTED]> said:
>>Key facts here: >> >>- upstream branch *tracking* upstream >>- patch management using quilt. >> >>For point 1: How often do you "snapshot" upstream? Every upstream commit >>of their VCS or only upstream releases? What to do with upstreams that >>don't do commits in years? (think ffmpeg, toolame). FS> In our case, we track upstream releases only, but only because it doesn't make FS> much sense to do otherwise[1]: csound uses CVS (ugh), thus making it painful FS> to track it directly. In the case of ffmpeg, where there are no released FS> tarballs, it would make sense to directly track the git repository (ie, the FS> upstream branch is a clone of upstream's master branch). In either FS> case, "upstream" releases should be tagged (eg, upstream/x.y.z~svn123 as FS> git-buildpackage tags them). The debian diff is not a diff against upstream's FS> tip, but against these tags. That is the same approach I adopted, and the default one of git-buildpackage, I think it makes sense to stick to it. FS> It's a simple approach, so it would probably minimize confusion. Another way FS> we used to do with csound is: the upstream branch contains the pristine FS> upstream tarball, the dfsg-clean branch has the mangled upstream code and the FS> master branch contains the debian packaging. Then builds are done against the FS> dfsg-clean branch instead of the upstream branch, and unstripped builds can FS> be done agains the upstream branch. The problem with this approach is that FS> the code that you are stripping because you can't/don't want to distribute in FS> Debian is still served by Debian via the vcs in alioth. Well, but is not in the pool and the binary gets build against the stripped version, I think we can live with this. FS> The ffmpeg case is somewhat particular, as the same packaging can build 2 FS> source packages (ffmpeg and ffmpeg-debian). I'm not really sure what approach FS> is the best. I would >> >>> Other people prefer topic branches and an integration branch. This >>> may be better for longer-lived patches. The guys from vcs-pkg seem to >>> swear by this last workflow. TopGit seems to be able to generate a >>> linear quilt patchset, which is nice for people wanting to review the >>> source package. >> >>Exactly. I think we don't do a mistake if we continue maintaining quilt >>patches for now. I'd say let's see how this works out and reconsider >>later. I also would stick to quilt patches, to be included in the debian source package. However I would also keep a long-lived branch for each of them, because it might be useful to track the history of a patch, or split it into individual commits. FS> Lets try to set a few guidelines for new/transitioning packages, then. FS> 1. Packages should be maintained in a git repository (using the pkg-multimedia FS> or demudi namespace?) demudi has already a repo on git.debian.org, and I prefer it over collab-maint because the latter is writable only by DDs (for non-DDs you have to ask for write permission on case-by-case basis), while the former is writable by all the members of the relevant Alioth project, DDs or not. While we are at it we might want to change the name to something different at all, creating a new project called "debian-multimedia" I am the one who created the demudi alioth project, and AFAIR at that time it was not possible to name it "debian-multimedia" because the name was to long, so I went for demudi. Things might be changed now, or we can ask for an exception. FS> 2. The maintainer field should be set to... Personally I don't care too much about the name, as long as bug reports and upload notifications are forwarded to the same list as the team's discussion list. At least initially. FS> 3. Patches to upstream should be stored as quilt patches which are then used FS> in the build process (ie, no direct changes to the source files). I would like to have a git branch for these patches as well, but we might want to make this optional. For very small patches it is probably overkill. FS> 4. How to manage upstream sources? As said, I would stick to the git-buildpackage standards, that means a git branch for upstream sources, which can get imported with git-import-orig Ciao! Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
