Bug#515793: RFP: cgit -- C-code Web Front-end to GIT

[Oxan van Leeuwen]

Hi,

On 19-02-14 00:47, YAEGASHI Takeshi wrote:

Oxan, have you already worked on your own cgit package built with
something like git-source binary package?  Please let me know if you
made any progress.  I might be able to contribute to your package!


No, unfortunately I hadn't made any progress. I tried to get it working 
using a git-source package, but the Git package is quite complex and I 
couldn't get it working, so I gave up in the end. The lack of debhelper 
in the git package didn't help either (which might be because I'm not 
very knowledgeable on low-level package building).


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: RFP: cgit -- C-code Web Front-end to GIT

[YAEGASHI Takeshi]

Hi Jonathan,

2014-02-19 8:58 GMT+09:00 Jonathan Nieder :
> I can write a patch demonstrating what I mean making use of your
> packaging from http://git.keshi.org/debian/cgit.git if you like.  What
> do you think?

I appreciate your help and would like to see how it will go with the
git package with cgit.  I could contribute as a co-maintainer for cgit
in that case.

Basically I think it's a bad idea to add more complexity to the git
package and cgit/git should be decoupled in some way as Oxan stated,
but we might be able to overcome possible downsides with your (the git
maintainer's) assurance.

Regards,
-- 
YAEGASHI Takeshi 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#515793: RFP: cgit -- C-code Web Front-end to GIT

[Jonathan Nieder]

Hi,

YAEGASHI Takeshi wrote:

> I know such a package is undesirable, but I wonder if it's completely
> unacceptable for the Debian distribution.

As mentioned a few times before, I think it would be simplest to just
add cgit to the git package.  If someone using cgit wants to be a
co-maintainer I'm happy to let them maintain the cgit packaging
however they like.

I can write a patch demonstrating what I mean making use of your
packaging from http://git.keshi.org/debian/cgit.git if you like.  What
do you think?

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: RFP: cgit -- C-code Web Front-end to GIT

[YAEGASHI Takeshi]

Hi,

Without noticing this RFP [1], I made another ITP [2] and experimental
cgit package [3][4] which contains full source of git of specific
version.

I know such a package is undesirable, but I wonder if it's completely
unacceptable for the Debian distribution.  Isn't it possible for
collaborative developers to keep maintaining this with support from
the security team? [5] (I'd like to ask for co-maintainers if my
package happens to be accepted)

Oxan, have you already worked on your own cgit package built with
something like git-source binary package?  Please let me know if you
made any progress.  I might be able to contribute to your package!

Thanks,

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515793
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739231
[3] http://debian.keshi.org/cgit/
[4] http://git.keshi.org/debian/cgit.git
[5] https://wiki.debian.org/EmbeddedCodeCopies

-- 
YAEGASHI Takeshi 


-- 
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

[Oxan van Leeuwen]

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

[Jonathan Nieder]

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

[Jonathan Nieder]

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

[Oxan van Leeuwen]

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:

[Sander van Zoest]

It seems like there was some work done on creating a cgit debian package by
Stefan Bühler.
See http://stbuehler.de/debianserver/cgit.html

Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT

[Marc Singer]

On Mon, Jul 30, 2012 at 9:43 AM, Jonathan Nieder  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

[Jonathan Nieder]

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

[Marc Singer]

On Sun, Jul 29, 2012 at 9:20 PM, Jonathan Nieder  wrote:

> Hi Marc,
>
> Marc Singer wrote:
> > On Sun, Jul 29, 2012 at 6:36 PM, Jonathan Nieder 
> 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 .
>
> 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

[Jonathan Nieder]

Hi Marc,

Marc Singer wrote:
> On Sun, Jul 29, 2012 at 6:36 PM, Jonathan Nieder  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 .

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

[Jonathan Nieder]

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: cgit: changing back from ITP to RFP

[Lucas Nussbaum]

retitle 515793 RFP: cgit -- C-code Web Front-end to GIT
noowner 515793
thanks

Hi,

This is an automatic email to change the status of cgit back from ITP
(Intent to Package) to RFP (Request for Package), because this bug hasn't seen
any activity during the last 6 months.

If you are still interested in adopting cgit, please send a mail to
 with:

 retitle 515793 ITP: cgit -- C-code Web Front-end to GIT
 owner 515793 !
 thanks

However, it is not recommended to keep ITP for a long time without acting on
the package, as it might cause other prospective maintainers to refrain from
packaging that software. It is also a good idea to document your progress on
this ITP from time to time, by mailing <515...@bugs.debian.org>.

Thank you for your interest in Debian,
-- 
Lucas, for the QA team 



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#515793: Get cgit included with statically linked libgit.a?

[Paul Menzel]

Am Montag, den 15.03.2010, 12:47 -0700 schrieb Marc Singer:
> On Mon, Mar 8, 2010 at 2:26 AM, Paul Menzel wrote:
> > Am Sonntag, den 07.03.2010, 15:51 -0800 schrieb Marc Singer:
> > > On Sun, Mar 7, 2010 at 1:14 PM, Paul Menzel  > > wrote:
> > > > Am Dienstag, den 17.02.2009, 09:40 -0800 schrieb Marc Singer:
> > > > > 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/
> > > >
> > > > the blocking bug 407722 [1] is marked »wontfix« and judging from the
> > > > answers on my question sent to the Git list (also cc-ed to [1]) it looks
> > > > like the only option is to link statically against libgit. :(
> > > >
> > > > Can some Debian Developers please comment on this? And if no other
> > > > solution is proposed could we get cgit included into the Debian package
> > > > repository and with luck cgit might be available in Debian squeeze.
> > >
> > > I'm not optimistic that the git developers will support development
> > > against the library.  It's really a shame since it would benefit some
> > > kinds of projects that are performance bound
> >
> > You are right, as can be seen by the replies to bug #407722 [1].
> >
> > So we should deal with this situation and link against libgit
> > statically. What do I miss?
>
> IMHO, that would be an unwise path.  The GIT developers
> are committed to being able to change the interface.   Seems
> like the design of cgit needs to change in order to move forward.

I thought the replies from the Git developers to [1] (especially [2])
meant that it is ok to link it statically.

What harm would it do if we link it statically. Would not that only
affect cgit?


Thanks,

Paul


PS: Could you please just send plain text messages? Evolution has some
problems with quoting GMail HTML messages and it saves some
bandwidth. ;-)


> > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407722
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407722#84


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Bug#515793: Get cgit included with statically linked libgit.a?

[Marc Singer]

On Mon, Mar 8, 2010 at 2:26 AM, Paul Menzel wrote:

> Am Sonntag, den 07.03.2010, 15:51 -0800 schrieb Marc Singer:
> > On Sun, Mar 7, 2010 at 1:14 PM, Paul Menzel  >wrote:
> > > Am Dienstag, den 17.02.2009, 09:40 -0800 schrieb Marc Singer:
> > > > 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/
> > >
> > > the blocking bug 407722 [1] is marked »wontfix« and judging from the
> > > answers on my question sent to the Git list (also cc-ed to [1]) it
> looks
> > > like the only option is to link statically against libgit. :(
> > >
> > > Can some Debian Developers please comment on this? And if no other
> > > solution is proposed could we get cgit included into the Debian package
> > > repository and with luck cgit might be available in Debian squeeze.
> >
> > I'm not optimistic that the git developers will support development
> > against the library.  It's really a shame since it would benefit some
> > kinds of projects that are performance bound
>
> You are right, as can be seen by the replies to bug #407722 [1].
>
> So we should deal with this situation and link against libgit
> statically. What do I miss?
>
>
IMHO, that would be an unwise path.  The GIT developers
are committed to being able to change the interface.   Seems
like the design of cgit needs to change in order to move forward.



>
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407722
>

Bug#515793: Get cgit included with statically linked libgit.a?

[Paul Menzel]

Am Sonntag, den 07.03.2010, 15:51 -0800 schrieb Marc Singer:
> On Sun, Mar 7, 2010 at 1:14 PM, Paul Menzel wrote:
> > Am Dienstag, den 17.02.2009, 09:40 -0800 schrieb Marc Singer:
> > > 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/
> >
> > the blocking bug 407722 [1] is marked »wontfix« and judging from the
> > answers on my question sent to the Git list (also cc-ed to [1]) it looks
> > like the only option is to link statically against libgit. :(
> >
> > Can some Debian Developers please comment on this? And if no other
> > solution is proposed could we get cgit included into the Debian package
> > repository and with luck cgit might be available in Debian squeeze.
>
> I'm not optimistic that the git developers will support development
> against the library.  It's really a shame since it would benefit some
> kinds of projects that are performance bound

You are right, as can be seen by the replies to bug #407722 [1].

So we should deal with this situation and link against libgit
statically. What do I miss?


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407722


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Bug#515793: Get cgit included with statically linked libgit.a?

[Marc Singer]

On Sun, Mar 7, 2010 at 1:14 PM, Paul Menzel wrote:

> Dear Marc,
>
>
> Am Dienstag, den 17.02.2009, 09:40 -0800 schrieb Marc Singer:
> > 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/
>
> the blocking bug 407722 [1] is marked »wontfix« and judging from the
> answers on my question sent to the Git list (also cc-ed to [1]) it looks
> like the only option is to link statically against libgit. :(
>
> Can some Debian Developers please comment on this? And if no other
> solution is proposed could we get cgit included into the Debian package
> repository and with luck cgit might be available in Debian squeeze.
>
>
I'm not optimistic that the git developers will support development
against the library.  It's really a shame since it would benefit some kinds
of projects that are performance bound

Bug#515793: Get cgit included with statically linked libgit.a?

[Paul Menzel]

Dear Marc,


Am Dienstag, den 17.02.2009, 09:40 -0800 schrieb Marc Singer:
> 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/

the blocking bug 407722 [1] is marked »wontfix« and judging from the
answers on my question sent to the Git list (also cc-ed to [1]) it looks
like the only option is to link statically against libgit. :(

Can some Debian Developers please comment on this? And if no other
solution is proposed could we get cgit included into the Debian package
repository and with luck cgit might be available in Debian squeeze.


Thanks,

Paul


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407722


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Bug#515793: (no subject)

[Pablo Castellano]

Okay I answer myself. I haven't read about the bug that blocks this one.
--
Regards,
Pablo.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#515793: Status

[Pablo Castellano]

Hello.

What's the status of this ITP?
Any progress?

Regards,
Pablo.



--
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

[Stefano Zacchiroli]

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

[Marc Singer]

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