Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT
Hi, On 04-08-13 00:59, Jonathan Nieder wrote: I'd like to propse another solution for this: let git build a git-source binary package, and build cgit using that package. I would prefer not to go this way. It would mean that when I make git uploads, they'd always have a chance of breaking the cgit build without notice. And it would also mean that whenever I fix an important bug I have to track down whether cgit needs to be rebuilt. Yes, that's true. (Unfortunately Debian doesn't have CI-infrastructure available to rebuild cgit on all commits to the git package. I think that could have been a good compromise). An alternative that is not as bad is to export libgit.a (or .so, for that matter) and headers for cgit use. Wouldn't exporting the static library suffer from the same problems as exporting the source? cgit will still need to be rebuild to profit from bug fixes in git, and git can still break its build without notice. Exporting the shared library would of course prevent the first problem. However, some of the discussion in #407722 indicated that git upstream doesn't want libgit to be exported, and the Debian maintainers didn't want to overrule them. If that has changed, great :) I think git breaking cgit's build isn't that big of a problem. cgit upstream seems to be active enough in fixing compatiblity with newer git versions, and the required changes are in general quite small (upgrade from 1.7.7.4 to 1.8.3 required just 6 lines of code in total). So if you don't have a problem with exporting libgit anymore, I think that's the way we should go, and I'll create cgit packages using them. I'd far prefer to just have a copy of cgit built as part of the git build. It doesn't have to involve multiple upstream tarballs: e.g., cgit can be included in the debian/ directory in the debian.tar.xz in the short term, and in the long term I think it would be a candidate for inclusion in contrib/ upstream. Building two projects with separate release cycles and upstreams from the same source package just feels wrong to me, and I prefer to not do it, especially as the git package already seems quite complex. All that said, if someone wants to add another binary package like git-source to the git build and is willing to maintain it in the long term, I'll be glad to help (and wash my hands of the day-to-day maintenance :)). See /usr/share/doc/git/README.source for hints on working with the package. Packaging is at git://git.debian.org/~jrnieder-guest/git.git I'll take a stab at doing that. Maintaining it long-term shouldn't be a problem. (fyi, the Vcs-* fields in the package indicate another repository. Might be useful to synchronize the repositories and/or changes the Vcs-* fields.) Cheers, Oxan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT
Hi Jonathan, Marc, On 29-07-12 18:19, Jonathan Nieder wrote: I would be very happy to see cgit in Debian. Perhaps we could approach this by building cgit from the git source package, either using dpkg source format 3.0's multiple-tarball feature or by including cgit in the Debian patch. Would you be interested in this approach? Do you have initial cgit packaging to play with? I'd like to propse another solution for this: let git build a git-source binary package, and build cgit using that package. I see a few advantages for this over building cgit from the git source package: - It doesn't group multiple separate projects into a single source package. While technically possible with the 3.0 source format, having separate source packages is more logical imo. - If cgit is broken due to a change in git, the git package doesn't FTBFS. This has the added advantage of cgit not holding up new releases, testing migrations, etc. of git. - Smaller packages are easier to maintain in my experience, though that's a bit subjective of course. The obvious downside is introduction of a new -source package. Since we cannot build-depend on source packages yet, and there are already ~80 such packages in the archive, I think this is acceptable. With the recent Built-Using introduction this also doesn't impose any licensing problems. If this route is acceptable for the git maintainers, I'm willing to step up as cgit (co-)maintainer. If someone else wants to join too, that's great! ;) Regards, Oxan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT
Hi, Oxan van Leeuwen wrote: On 29-07-12 18:19, Jonathan Nieder wrote: I would be very happy to see cgit in Debian. Perhaps we could approach this by building cgit from the git source package, either using dpkg source format 3.0's multiple-tarball feature or by including cgit in the Debian patch. Would you be interested in this approach? Do you have initial cgit packaging to play with? I'd like to propse another solution for this: let git build a git-source binary package, and build cgit using that package. I would prefer not to go this way. It would mean that when I make git uploads, they'd always have a chance of breaking the cgit build without notice. And it would also mean that whenever I fix an important bug I have to track down whether cgit needs to be rebuilt. An alternative that is not as bad is to export libgit.a (or .so, for that matter) and headers for cgit use. I'd far prefer to just have a copy of cgit built as part of the git build. It doesn't have to involve multiple upstream tarballs: e.g., cgit can be included in the debian/ directory in the debian.tar.xz in the short term, and in the long term I think it would be a candidate for inclusion in contrib/ upstream. Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT
Jonathan Nieder wrote: Oxan van Leeuwen wrote: On 29-07-12 18:19, Jonathan Nieder wrote: I would be very happy to see cgit in Debian. Perhaps we could approach this by building cgit from the git source package, either using dpkg source format 3.0's multiple-tarball feature or by including cgit in the Debian patch. Would you be interested in this approach? Do you have initial cgit packaging to play with? I'd like to propse another solution for this: let git build a git-source binary package, and build cgit using that package. I would prefer not to go this way. It would mean that [...] All that said, if someone wants to add another binary package like git-source to the git build and is willing to maintain it in the long term, I'll be glad to help (and wash my hands of the day-to-day maintenance :)). See /usr/share/doc/git/README.source for hints on working with the package. Packaging is at git://git.debian.org/~jrnieder-guest/git.git Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT
On Sun, Jul 29, 2012 at 9:20 PM, Jonathan Nieder jrnie...@gmail.com wrote: Hi Marc, Marc Singer wrote: On Sun, Jul 29, 2012 at 6:36 PM, Jonathan Nieder jrnie...@gmail.com wrote: Did you mean this to be a private reply? Not really. Ok, cc-ing the bug. [...] The policy of the git authors is their prerogative. They've made it very clear that they will not support a shared library. I suppose if you could manage the SO as part of the debian packages. Doing so puts the burden on us to track API changes with no promised from upstream. Is this what you are proposing? You're presumably thinking of http://bugs.debian.org/407722. No, I agree with Gerrit and think that shipping libgit.a as a library is a non-starter. Git's internal APIs (that's what libgit.a is) are very unstable, and to provide it as a package, even with a constantly changing name, would be to make an interface promise we couldn't keep. Instead, I was offering to build cgit from the *same* source package as git. I would probably try to upstream the change (putting a submodule with cgit under contrib/), but even if upstream does not accept it, we could build cgit in Debian this way. The main (and only) advantage of this approach is that when an API break causes cgit to stop working, git would FTBFS. This immediate feedback would force the code to keep working together. Hoping that clarifies, Jonathan Sounds like a good plan. Do you need my help?
Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT
Hi Marc, Marc Singer wrote: Do you need my help? Yes, because I do not use cgit. We would need an active user to make sure it keeps working and to evaluate requests that come in through the BTS. In other words, I do not want to be the cgit package maintainer, even though I'd be fine with having the cgit binary package produced by the git source package. Another way to help is to provide any existing starts to packaging cgit in another way, which would provide lots of hints about packaging decisions. That's why I asked whether any work-in-progress packaging exists. Ciao, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT
On Mon, Jul 30, 2012 at 9:43 AM, Jonathan Nieder jrnie...@gmail.com wrote: Hi Marc, Marc Singer wrote: Do you need my help? Yes, because I do not use cgit. We would need an active user to make sure it keeps working and to evaluate requests that come in through the BTS. In other words, I do not want to be the cgit package maintainer, even though I'd be fine with having the cgit binary package produced by the git source package. Another way to help is to provide any existing starts to packaging cgit in another way, which would provide lots of hints about packaging decisions. That's why I asked whether any work-in-progress packaging exists. OK. I'll take a look at where it stands. I didn't spend any time on the package once I found out that there was no library in our future. I'm guessing that it will be a month before I can take a look at this. I'll send a message when I have a chance to review the package.
Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT
Hi Marc, Marc Singer wrote: The upstream build of cgit requires a download of git to build libgit which this package links statically. Thus, this package practically depends on a change to git-core. http://hjemli.net/git/cgit/ I would be very happy to see cgit in Debian. Perhaps we could approach this by building cgit from the git source package, either using dpkg source format 3.0's multiple-tarball feature or by including cgit in the Debian patch. Would you be interested in this approach? Do you have initial cgit packaging to play with? Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT
Hi Marc, Marc Singer wrote: On Sun, Jul 29, 2012 at 6:36 PM, Jonathan Nieder jrnie...@gmail.com wrote: Did you mean this to be a private reply? Not really. Ok, cc-ing the bug. [...] The policy of the git authors is their prerogative. They've made it very clear that they will not support a shared library. I suppose if you could manage the SO as part of the debian packages. Doing so puts the burden on us to track API changes with no promised from upstream. Is this what you are proposing? You're presumably thinking of http://bugs.debian.org/407722. No, I agree with Gerrit and think that shipping libgit.a as a library is a non-starter. Git's internal APIs (that's what libgit.a is) are very unstable, and to provide it as a package, even with a constantly changing name, would be to make an interface promise we couldn't keep. Instead, I was offering to build cgit from the *same* source package as git. I would probably try to upstream the change (putting a submodule with cgit under contrib/), but even if upstream does not accept it, we could build cgit in Debian this way. The main (and only) advantage of this approach is that when an API break causes cgit to stop working, git would FTBFS. This immediate feedback would force the code to keep working together. Hoping that clarifies, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT
On Tue, Feb 17, 2009 at 07:14:45PM -0800, Marc Singer wrote:
Also, it doesn't look like you're a DD. Why are you so keen to
maintain it?
Please consider refraining to post comments like this in the
future. Your intention might have been good, but written as you wrote
it, it can discourage non-DDs to maintain packages.
We have sponsorship in place exactly because we (unless proven
otherwise) want also non-DDs to maintain packages, of course with
mentoring and review in place before uploading.
Also, the Debian Project endorsed the notion of Debian Maintainer [1]
which, again, show our support to non-DDs maintaining packages
(sometime for the interim before becoming DDs, sometime not).
Cheers.
[1] http://www.debian.org/vote/2007/vote_003
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT
Package: wnpp Severity: wishlist The upstream build of cgit requires a download of git to build libgit which this package links statically. Thus, this package practically depends on a change to git-core. http://hjemli.net/git/cgit/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
