Re: What to do for new packages
Reinhard Tartler schrieb: I really don't mind using pkg-multimedia-maintainers, since it is more active. I've setup a doodle poll, please vote here: http://doodle.com/v6df6bx2akdft73f I have voted for "pkg-multimedia-maintainers", because "debian-multimedia" is allready too closely connected to Marillat's archive. -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Multimedia Teams in Debian
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]
Re: What to do for new packages
Hi Felipe, |--==> On Wed, 26 Nov 2008 12:27:52 -0300, Felipe Sateler <[EMAIL PROTECTED]> said: FS> OK, so I'm about to co-maintain liblo, which is an OSC library, and can be FS> considered a multimedia package (csound, rosegarden and ardour are some "big" FS> packages using it). FS> So... I want to bring it under the scope of the teams-to-become-one. I have FS> imported the sources into a git repository. demudi already has a git area FS> enabled in alioth, pkg-multimedia doesn't. Should I use the demudi area? I would like to have an Alioth project name consistent with the mailing list name and with the git repository name, something like: http://alioth.debian.org/projects/ @lists.debian.org, http://git.debian.org//some-package where could be pkg-multimedia, or debian-multimedia or whatever else. FS> What list should I put in the Maintainer field? I'd suggest @lists.debian.org Ciao! Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What to do for new packages
Free Ekanayaka <[EMAIL PROTECTED]> writes: > FS> What list should I put in the Maintainer field? > > I'd suggest @lists.debian.org please note that we have more control over mailman controlled lists than over debian listadmin maintained lists. That's why I'd prefer the lists.alioth.debian.org lists. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What to do for new packages
El 27/11/08 18:01 Reinhard Tartler escribió: > Felipe Sateler <[EMAIL PROTECTED]> writes: > > OK, so I'm about to co-maintain liblo, which is an OSC library, and can > > be considered a multimedia package (csound, rosegarden and ardour are > > some "big" packages using it). > > ok. cool! > > > So... I want to bring it under the scope of the teams-to-become-one. I > > have imported the sources into a git repository. > > IIRC we agreed on tracking upstream releases in an upstream branch, > maintain debian packaging in a branch derived from the upstream branch > but keep patches to the upstream source in quilt. Is that correct? > > We should really document that somewhere. Probably on wiki.debian.org > would be a good place. OK, I've started a page: http://wiki.debian.org/DebianMultimedia/Merge. Please add, edit, remove whatever you think necessary. I just filled a stub based on what I think we have agreed. > > > demudi already has a git area > > enabled in alioth, pkg-multimedia doesn't. Should I use the demudi area? > > What list should I put in the Maintainer field? > > Given that pkg-multimedia is more active maybe we should it? > > I really don't mind using pkg-multimedia-maintainers, since it is more > active. I've setup a doodle poll, please vote here: > > http://doodle.com/v6df6bx2akdft73f Great! I placed my vote. I agree with Fabian that debian-multimedia may be associated with Marillat's repository, and we should avoid that. Free's point about using the same project for lists and everything is also important. Using different alioth projects would be confusing, I think. > > > BTW, I have applied for joining the pkg-multimedia project, in case we > > end up using any resources there. > > I noticed you have already been added! welcome! Cool. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: Multimedia Teams in Debian
On Sat, Nov 22, 2008, Felipe Sateler wrote: > In the case of ffmpeg, where there are no released > tarballs, it would make sense to directly track the git repository (ie, the > upstream branch is a clone of upstream's master branch). In either > case, "upstream" releases should be tagged (eg, upstream/x.y.z~svn123 as > git-buildpackage tags them). The debian diff is not a diff against upstream's > tip, but against these tags. Unless there's absolutely no generated files when disting ffmpeg, I prefer we don't do that and instead import tarballs in the git tree. I understand this is archaic, but all situations can be handled simply in this scheme, with a classical approach. When you try git pulling from upstream, you might end up with removed files reappearing from the tarball, or keeping generated data in git. > 2. The maintainer field should be set to... A real maintainer when there's an interested one -- when this happens people care more personally for the package -- and the team as uploader. The team as maintainer when nobody wants to take primary reponsability for a source. > 4. How to manage upstream sources? Import tarballs, stripped or not or both. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Multimedia Teams in Debian
On Fri, Nov 28, 2008, Free Ekanayaka wrote: > 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. That doesn't make any sense to me: - demudi: non-DD have to ask, DD have to ask - collab-maint: non-DD have to ask, DD don't Besides, you ask only once for collab-maint membership, but it's not only about multimedia packages. > 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. Please, no; you can create the patches from local git branches when you prepare them, but it doesn't make sense if we export branches to patches because what we might receive are ... updated patches. > 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 Sounds right! Thanks, -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
