[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: team infrastructure (wiki page, doc, bug tracking, etc.)



Le Mon, Nov 19, 2012 at 06:03:33PM +0100, Stefano Zacchiroli a écrit :
> On Wed, Nov 14, 2012 at 09:13:10AM +0900, Charles Plessy wrote:
> 
> > I am not sure if we need an Alioth project.  I would rather recommend
> > to dispatch new package according to their content to existing teams,
> > in particular the Perl, Python and Java packaging teams, which are
> > very open.
> 
> Disclaimer: I'm not doing any packaging work related to Debian "cloud"
> stuff up to now, so I surely welcome living this choice to the people
> who are doing that work.
> 
> Still, I wonder which benefit do you see in scattering the packages
> across the various, programming language oriented, projects you mention
> above. That would mean that people interesting in more than one cloud
> related package will have to join several teams. Clearly, we can turn
> the argument around saying that people interested in, say, Python
> packaging will have to join the cloud Alioth project. But to me the
> former case seems significantly more likely than the latter, no?

Hi Stefano and Thomas

the current situation is that packages are already dispatched in various teams
that are very open.  I propose to refrain from moving packages unless strictly
necessary.

I also would prefer to avoid any situation where it will be asked who has the
right to decide who has commit rights or not, what is the standard VCS
workflow, etc.  The best way for this is to use either existing packaging teams
that widely open to contributors, or collab-maint.

The tool 'mr' can be used to check out packages from multiple repositories if
needed.

For cloud-init, it is maintained in the python-apps, which means
"svn-buildpackage".  I can move it to collab-maint is it will increase the
number of contributors.

For euca2ools, it is currently maintained by the pkg-eucalyptus team in a Git
repository, (where our policy is to use pkg-java or pkg-python as much as
possible).  Contributors are very welcome.  If this is still too much of a
problem, I can move it to collab-maint, but I would prefer to not do it
pre-emptively. 

For new package, I of course do not oppose to people to do what they want.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


Reply to: