On Tue, Jun 15, 2010 at 9:15 AM, Felipe Sateler wrote:
> The only problem I see is that PET does not really scale well to lots of
> packages, the page gets quite cluttered. So I don't know if pulling the
> whole collab-maint area will be of any use.
I suppose that depends on how much or little w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 14/06/10 01:55, Ansgar Burchardt wrote:
> I started working on a version of PET that supports several VCS
> backends, even for a single instance: all packages show up on a single
> package no matter in which of the known VCS they live in.
> For no
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 13/06/10 10:05, Tim Retout wrote:
> Proposal
>
>
> I am considering creating a new workflow for my sponsoring:
>
> * Maintaining packages in git in collab-maint. (I don't think we
> want a separate pkg-mentors repository,
Ben Finney writes:
> Ansgar Burchardt writes:
>> All of these notes are removed before the upload so they do not show up
>> in the released packages.
>>
>> I think this is a very good method to communicate with other team
>> members about the current state of packages.
This works brilliantly, b
On Mon, Jun 14, 2010 at 12:25:07PM +0200, Jakub Wilk wrote:
>> Ansgar Burchardt writes:
>>> I think this is a very good method to communicate with other team
>>> members about the current state of packages.
> Leaving notes is a good communication method? Seriously?
> How about *talking* to eac
Ansgar Burchardt writes:
All of these notes are removed before the upload so they do not show
up in the released packages.
I think this is a very good method to communicate with other team
members about the current state of packages.
Leaving notes is a good communication method? Seriously?
Tim Retout writes:
> I'm not particularly attached to the choice of VCS; but what I do
> think is important is that people /do/ choose a VCS.
Rather, I think it's important (for the good reasons you explained) that
a package maintainer *use* a VCS for their packaging work.
They don't have to ch
On 14 June 2010 02:20, Ben Finney wrote:
> Paul Wise writes:
>
>> As said on IRC, "cue anti-git flamage". In debian we use a multitude
>> of version control systems and we shouldn't impose choice of a
>> specific VCS nor force people to use a VCS. I personally maintain
>> packages in git, in SVN
Ansgar Burchardt writes:
> Ben Finney writes:
>
> > I'm not sure what “coordinating via notes at the top of
> > debian/changelog” means. Bear in mind that the changelog is
> > primarily for communicating package changes *to users* of those
> > packages.
>
> The Perl Group makes use of this: in t
Hi,
Ben Finney writes:
> Paul Wise writes:
>
>> As said on IRC, "cue anti-git flamage". In debian we use a multitude
>> of version control systems and we shouldn't impose choice of a
>> specific VCS nor force people to use a VCS. I personally maintain
>> packages in git, in SVN and in no VCS an
Paul Wise writes:
> As said on IRC, "cue anti-git flamage". In debian we use a multitude
> of version control systems and we shouldn't impose choice of a
> specific VCS nor force people to use a VCS. I personally maintain
> packages in git, in SVN and in no VCS and prefer either no VCS or SVN
> f
On Sun, Jun 13, 2010 at 10:05 PM, Tim Retout wrote:
> * Maintaining packages in git in collab-maint. (I don't think we
> want a separate pkg-mentors repository, because once people
> graduate from mentors they would feel compelled to move away.)
As said on IRC, "cue anti-git f
Quoting "Tim Retout" :
[Please excuse the long email. I welcome comments.]
Hi,
a lot of helpful technical details, already used for years [1] (though
I don't know what PET is), however I still can't see how the 'splitted
brain syndrome' is dealt with, the logical problem, i.e. mentee X
[Please excuse the long email. I welcome comments.]
There has been some recent discussion on debian-mentors about the
difficulties being faced by contributors seeking sponsorship, i.e. that
DDs willing to sponsor packages are short on time and/or motivation.
In my view, this is an important issue
14 matches
Mail list logo
