Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #10105 > unrolled thread

Move to salsa? Merge modules and apps team?

Back to article view | Back to linux.debian.maint.python

Contents

  Move to salsa? Merge modules and apps team? "W. Martin Borgert" <debacle@debian.org> - 2018-02-07 08:40 +0100
    Re: Move to salsa? Merge modules and apps team? Piotr Ożarowski <piotr@debian.org> - 2018-02-07 13:20 +0100
    Re: Move to salsa? Merge modules and apps team? Ghislain Vaillant <ghisvail@gmail.com> - 2018-02-07 09:10 +0100
    Re: Move to salsa? Merge modules and apps team? Ondrej Novy <novy@ondrej.org> - 2018-02-07 09:50 +0100
    Re: Move to salsa? Merge modules and apps team? Matthias Klose <doko@debian.org> - 2018-02-07 10:00 +0100
      Re: Move to salsa? Merge modules and apps team? Matthias Klose <doko@debian.org> - 2018-02-07 10:20 +0100
      Re: Move to salsa? Merge modules and apps team? Ghislain Vaillant <ghisvail@gmail.com> - 2018-02-07 10:20 +0100
      Re: Merge modules and apps team? "W. Martin Borgert" <debacle@debian.org> - 2018-02-07 10:40 +0100
    Re: Move to salsa? Merge modules and apps team? Piotr Ożarowski <piotr@debian.org> - 2018-02-07 10:30 +0100
      Re: Move to salsa? Merge modules and apps team? Ole Streicher <olebole@debian.org> - 2018-02-07 11:40 +0100
      Re: Move to salsa? Merge modules and apps team? Thomas Goirand <zigo@debian.org> - 2018-02-08 10:40 +0100
      Re: Move to salsa? Merge modules and apps team? Andreas Tille <andreas@an3as.eu> - 2018-02-12 00:20 +0100
        Re: Move to salsa? Merge modules and apps team? Piotr Ożarowski <piotr@debian.org> - 2018-02-12 10:20 +0100
          Re: Move to salsa? Merge modules and apps team? Andreas Tille <andreas@an3as.eu> - 2018-02-12 11:20 +0100
    Re: Move to salsa? Merge modules and apps team? Raphael Hertzog <hertzog@debian.org> - 2018-02-07 11:10 +0100
    Re: Move to salsa? Merge modules and apps team? Antoine Musso <hashar@free.fr> - 2018-02-08 19:40 +0100
      Re: Move to salsa? Merge modules and apps team? Lars Kruse <lists@sumpfralle.de> - 2018-02-09 02:30 +0100

#10105 — Move to salsa? Merge modules and apps team?

Hi,

how about moving the Python team(s) to salsa?
And how about merging the modules and apps teams into one?

Moving git packages (modules team) is very easy using
import.sh from https://salsa.debian.org/mehdi/salsa-scripts.git

Moving svn packages (apps team) is probably more work.

Any opinions? Any doubts?

TIA & Cheers

[toc] | [next] | [standalone]

#10106

[Ole Streicher, 2018-02-07]
> Piotr Ożarowski <piotr@debian.org> writes:
> > [W. Martin Borgert, 2018-02-07]
> >> And how about merging the modules and apps teams into one?
> >
> > I don't understand this, though. Why you want to merge them?
> > Sure, packaging Python applications is very similar to packaging
> > libraries but the difference is very significant - unfortunately many
> > application maintainers don't know or care about it and pollute global
> > Python namespace with private libraries.
> 
> So, why would you like to keep them separate?

Could you start with why do you want to merge them first?
If there are no advantages, why change?

> > If not separated at team level, I definitely want to have them somehow
> > separated at repository level so that it's clear which package is which
> > type or to easily checkout libraries only.
> 
> At least in the field where I package (astronomy), this does not work:
> many of our packages are libraries *and* apps. Often they come as a big
> (public) library with a small startup wrapper, and it is a matter of
> taste (and of how deep an astronomer digs into Python) whether it is
> used from the shell or from a Jupyter notebook.

well, if your application provides public library, it's a library to me
to be honest. It has to be taken care of in each transition and so on
so an additional tiny script in /usr/bin doesn't matter (I even install
such scripts in python*-foo binary packages)

> The rules for both are (should be) the same, right? So, what is the
> difference? 

the difference is you install an application in private dir and care
about default Python change only (less work for us, less disk space,
less buildd time, etc.) and less problems with conflicting names (why
would you bother searching for an unique name for a private lib?).
If you want to write a script that checks something in all of team
packages, it's easier if you can assume all of them are libraries.
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

[toc] | [prev] | [next] | [standalone]

#10107

[Multipart message — attachments visible in raw view] — view raw

Le 7 févr. 2018 07:38, "W. Martin Borgert" <debacle@debian.org> a écrit :

Hi,

how about moving the Python team(s) to salsa?


I'd be in favour for that.

And how about merging the modules and apps teams into one?


Same here. A single Python Team (python-team in salsa) would make sense.


Moving git packages (modules team) is very easy using
import.sh from https://salsa.debian.org/mehdi/salsa-scripts.git

Moving svn packages (apps team) is probably more work.


Could the import be done in stages then? Imo, packages which are ready for
transition should not have to wait.


Any opinions? Any doubts?

TIA & Cheers

[toc] | [prev] | [next] | [standalone]

#10108

[Multipart message — attachments visible in raw view] — view raw

Hi,

2018-02-07 8:37 GMT+01:00 W. Martin Borgert <debacle@debian.org>:

> how about moving the Python team(s) to salsa?
>

+1


> And how about merging the modules and apps teams into one?
>

+1


> Moving git packages (modules team) is very easy using
> import.sh from https://salsa.debian.org/mehdi/salsa-scripts.git


 I think we can migrate all git-based packages (all DPMT) at once

Moving svn packages (apps team) is probably more work.
>

and do this in second step.

-- 
Best regards
 Ondřej Nový

Email: novy@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

[toc] | [prev] | [next] | [standalone]

#10109

On 07.02.2018 08:37, W. Martin Borgert wrote:
> Hi,
> 
> how about moving the Python team(s) to salsa?
> And how about merging the modules and apps teams into one?
> 
> Moving git packages (modules team) is very easy using
> import.sh from https://salsa.debian.org/mehdi/salsa-scripts.git
> 
> Moving svn packages (apps team) is probably more work.
> 
> Any opinions? Any doubts?

I don't think that is a good idea.  Both teams are not very active when it comes
to address RC issues and updating to new upstream versions.  From my point of
view the apps team is worse than the modules team in this regard.  Currently
both teams really don't care about packages which are uploaded by other team
members.  Maybe it's time to clean up the teams before any considerations to
merge them?  For single maintainers we do have process for MIA, and for QA
uploads, however both python teams are escaping such efforts.

Matthias

[toc] | [prev] | [next] | [standalone]

#10110

On 07.02.2018 10:12, Ghislain Vaillant wrote:
> 2018-02-07 8:58 GMT+00:00 Matthias Klose <doko@debian.org>:
>> On 07.02.2018 08:37, W. Martin Borgert wrote:
>>> Hi,
>>>
>>> how about moving the Python team(s) to salsa?
>>> And how about merging the modules and apps teams into one?
>>>
>>> Moving git packages (modules team) is very easy using
>>> import.sh from https://salsa.debian.org/mehdi/salsa-scripts.git
>>>
>>> Moving svn packages (apps team) is probably more work.
>>>
>>> Any opinions? Any doubts?
>>
>> I don't think that is a good idea.  Both teams are not very active when it comes
>> to address RC issues and updating to new upstream versions.
> 
> How does that affect moving our hosting to salsa? Or is your point
> against merging both teams? I am confused.
> 
>>  From my point of
>> view the apps team is worse than the modules team in this regard.  Currently
>> both teams really don't care about packages which are uploaded by other team
>> members.  Maybe it's time to clean up the teams before any considerations to
>> merge them?  For single maintainers we do have process for MIA, and for QA
>> uploads, however both python teams are escaping such efforts.
> 
> Still unclear what all of this has to do with the salsa migration. I
> understand your concerns, but imo they are orthogonal to the
> transition.

no, it's about merging the teams, not the move to the new infrastructure.

[toc] | [prev] | [next] | [standalone]

#10111

2018-02-07 8:58 GMT+00:00 Matthias Klose <doko@debian.org>:
> On 07.02.2018 08:37, W. Martin Borgert wrote:
>> Hi,
>>
>> how about moving the Python team(s) to salsa?
>> And how about merging the modules and apps teams into one?
>>
>> Moving git packages (modules team) is very easy using
>> import.sh from https://salsa.debian.org/mehdi/salsa-scripts.git
>>
>> Moving svn packages (apps team) is probably more work.
>>
>> Any opinions? Any doubts?
>
> I don't think that is a good idea.  Both teams are not very active when it comes
> to address RC issues and updating to new upstream versions.

How does that affect moving our hosting to salsa? Or is your point
against merging both teams? I am confused.

>  From my point of
> view the apps team is worse than the modules team in this regard.  Currently
> both teams really don't care about packages which are uploaded by other team
> members.  Maybe it's time to clean up the teams before any considerations to
> merge them?  For single maintainers we do have process for MIA, and for QA
> uploads, however both python teams are escaping such efforts.

Still unclear what all of this has to do with the salsa migration. I
understand your concerns, but imo they are orthogonal to the
transition.

Cheers,
Ghis

[toc] | [prev] | [next] | [standalone]

#10113 — Re: Merge modules and apps team?

On 2018-02-07 09:58, Matthias Klose wrote:
> I don't think that is a good idea.  Both teams are not very active when it comes
> to address RC issues and updating to new upstream versions.  From my point of
> view the apps team is worse than the modules team in this regard.

In fact, this is one of the reasons I like to merge them. I hope,
that the slightly better situation of the modules will rub off on
the apps.  My illusions might be in vain, but at least I do not
see any disadvantage in the merge.

[toc] | [prev] | [next] | [standalone]

#10112

[W. Martin Borgert, 2018-02-07]
> how about moving the Python team(s) to salsa?

that's the natural place to move from alioth for both teams.
PAPT's repos will also have to be converted from svn to git.
All we need is a volunteer who will prepare it and supervise the
process.

> And how about merging the modules and apps teams into one?

I don't understand this, though. Why you want to merge them?
Sure, packaging Python applications is very similar to packaging
libraries but the difference is very significant - unfortunately many
application maintainers don't know or care about it and pollute global
Python namespace with private libraries.

If not separated at team level, I definitely want to have them somehow
separated at repository level so that it's clear which package is which
type or to easily checkout libraries only.

The only advantage I can see is less hassle with join requests, but
I don't think it's a big problem (you have to join once).

I also have a feeling the more packages (team members?) we have, the
less people care about packages without their name in
Maintainer/Uploaders fields (even those who did team-wide changes in the
past are not so active now, including myself) and the team name should
be changed to collab-maint-2 or collab-maint-py. 

> Moving git packages (modules team) is very easy using
> import.sh from https://salsa.debian.org/mehdi/salsa-scripts.git

looks like it takes only one repo at a time
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

[toc] | [prev] | [next] | [standalone]

#10115

Piotr Ożarowski <piotr@debian.org> writes:
> [W. Martin Borgert, 2018-02-07]
>> And how about merging the modules and apps teams into one?
>
> I don't understand this, though. Why you want to merge them?
> Sure, packaging Python applications is very similar to packaging
> libraries but the difference is very significant - unfortunately many
> application maintainers don't know or care about it and pollute global
> Python namespace with private libraries.

So, why would you like to keep them separate?

> If not separated at team level, I definitely want to have them somehow
> separated at repository level so that it's clear which package is which
> type or to easily checkout libraries only.

At least in the field where I package (astronomy), this does not work:
many of our packages are libraries *and* apps. Often they come as a big
(public) library with a small startup wrapper, and it is a matter of
taste (and of how deep an astronomer digs into Python) whether it is
used from the shell or from a Jupyter notebook.

The rules for both are (should be) the same, right? So, what is the
difference? 

Best regards

Ole

[toc] | [prev] | [next] | [standalone]

#10118

On 02/07/2018 10:29 AM, Piotr Ożarowski wrote:
> If not separated at team level, I definitely want to have them somehow
> separated at repository level so that it's clear which package is which
> type or to easily checkout libraries only.

That can be done at least with subgroups. I've done that for OpenStack
and created 11 subgroups where repositories are stored, just to sort
things out.

>> Moving git packages (modules team) is very easy using
>> import.sh from https://salsa.debian.org/mehdi/salsa-scripts.git
> 
> looks like it takes only one repo at a time

I do have scripts to perform API requests on a list of packages. See
things in our stuff repo:

https://salsa.debian.org/openstack-team/debian/stuff/tree/master/salsa-scripts

The only thing you need to adapt is the OPENSTACK_GROUP_ID in the
list-all-subgroups script, and fix it to whatever the Python team will
be. Then you can simply do:

./run-on-all-projects ./set-irker

I don't have anymore the script that was doing the import, because
obviously, everything is done already, but it's quite trivial to write.
I just need to be master or owner on the team's group.

If you want, I can take care of importing the DPMT packages. Didn't we
have already scripts to migrate from SVN, written by tumbleweed? If we
do, then I can also do the work for apps, once they are migrated to Git.

Cheers,

Thomas Goirand (zigo)

[toc] | [prev] | [next] | [standalone]

#10142

Hi Piotr,

On Wed, Feb 07, 2018 at 10:29:37AM +0100, Piotr Ożarowski wrote:
> 
> > And how about merging the modules and apps teams into one?
> 
> If not separated at team level, I definitely want to have them somehow
> separated at repository level so that it's clear which package is which
> type or to easily checkout libraries only.

If you ask me at least cython should go to Python Modules team.  Its
not really just a random Python application and strongly connected
to several Python modules.
 
I see other applications in python-apps that are for no reason there.
We have no team C-apps or Perl-apps or ... LanguageX-apps.  These are
just random applications and could go to collab-maint (where the
Git maintained packages of Python-apps team reside anyway).

Just my 2 cents

      Andreas.

-- 
http://fam-tille.de

[toc] | [prev] | [next] | [standalone]

#10145

Hi Andreas,

[Andreas Tille, 2018-02-12]
> On Wed, Feb 07, 2018 at 10:29:37AM +0100, Piotr Ożarowski wrote:
> > > And how about merging the modules and apps teams into one?
> > If not separated at team level, I definitely want to have them somehow
> > separated at repository level so that it's clear which package is which
> > type or to easily checkout libraries only.
> 
> If you ask me at least cython should go to Python Modules team.  Its
> not really just a random Python application and strongly connected
> to several Python modules.

Cython is a library. I don't care what the description says, if there
are other libraries or applications that import it (and thus it has to
go into dist-packages/) - it's a library from my POV (as we HAVE TO
treat it as a library in the toolchain, transitions, ...)

> I see other applications in python-apps that are for no reason there.
> We have no team C-apps or Perl-apps or ... LanguageX-apps.  These are

"others do it differently" never was and hopefully never will be a valid
argument for me. "Others achieve this and that thanks to doing it this
way" might.

> just random applications and could go to collab-maint (where the
> Git maintained packages of Python-apps team reside anyway).

please point me to them so that I can NMU them removing team from
debian/control
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

[toc] | [prev] | [next] | [standalone]

#10148

Hi Ożarowski,

On Mon, Feb 12, 2018 at 10:09:42AM +0100, Piotr Ożarowski wrote:
> > If you ask me at least cython should go to Python Modules team.  Its
> > not really just a random Python application and strongly connected
> > to several Python modules.
> 
> Cython is a library. I don't care what the description says, if there
> are other libraries or applications that import it (and thus it has to
> go into dist-packages/) - it's a library from my POV (as we HAVE TO
> treat it as a library in the toolchain, transitions, ...)

Fine - so why it is maintained by the apps team?
 
> > I see other applications in python-apps that are for no reason there.
> > We have no team C-apps or Perl-apps or ... LanguageX-apps.  These are
> 
> "others do it differently" never was and hopefully never will be a valid
> argument for me. "Others achieve this and that thanks to doing it this
> way" might.

I did not wanted to use it as an argument.  However, there is also no
argument to have python-apps team at least there is no visible team for
me - just some "random apps that by chance are written in python".
 
> > just random applications and could go to collab-maint (where the
> > Git maintained packages of Python-apps team reside anyway).
> 
> please point me to them so that I can NMU them removing team from
> debian/control

PGPASSWORD="public-udd-mirror" psql --host=public-udd-mirror.xvm.mit.edu --username=public-udd-mirror udd -c "select distinct source, vcs_type, vcs_browser from sources where maintainer_email='python-apps-team@lists.alioth.debian.org' and release = 'sid' and vcs_type = 'Git' order by source;"
        source         | vcs_type |                                 vcs_browser                                 
-----------------------+----------+-----------------------------------------------------------------------------
 cppman                | Git      | https://anonscm.debian.org/cgit/collab-maint/cppman.git
 ctop                  | Git      | https://anonscm.debian.org/git/collab-maint/ctop.git
 dodgy                 | Git      | https://anonscm.debian.org/git/collab-maint/dodgy.git
 httpcode              | Git      | https://anonscm.debian.org/cgit/collab-maint/httpcode.git
 kanboard-cli          | Git      | https://anonscm.debian.org/cgit/collab-maint/kanboard-cli.git
 prospector            | Git      | https://anonscm.debian.org/git/collab-maint/prospector.git
 pydocstyle            | Git      | https://anonscm.debian.org/git/collab-maint/pydocstyle.git
 pyp                   | Git      | https://anonscm.debian.org/cgit/collab-maint/pyp.git
 pypass                | Git      | https://anonscm.debian.org/cgit/collab-maint/pypass.git
 sen                   | Git      | https://anonscm.debian.org/git/collab-maint/sen.git
 trac-announcer        | Git      | http://anonscm.debian.org/gitweb/?p=collab-maint/trac-announcer.git
 trac-customfieldadmin | Git      | https://anonscm.debian.org/gitweb/?p=collab-maint/trac-customfieldadmin.git
 trac-diavisview       | Git      | https://anonscm.debian.org/gitweb/?p=collab-maint/trac-diavisview.git
 trac-httpauth         | Git      | https://anonscm.debian.org/gitweb/?p=collab-maint/trac-httpauth.git
 trac-jsgantt          | Git      | https://anonscm.debian.org/gitweb/?p=collab-maint/trac-jsgantt.git
 trac-privatewiki      | Git      | http://anonscm.debian.org/gitweb/?p=collab-maint/trac-privatewiki.git
 trac-subcomponents    | Git      | http://anonscm.debian.org/gitweb/?p=collab-maint/trac-subcomponents.git
 trac-wikiprint        | Git      | https://anonscm.debian.org/gitweb/?p=collab-maint/trac-wikiprint.git
 trac-xmlrpc           | Git      | https://anonscm.debian.org/gitweb/?p=collab-maint/trac-xmlrpc.git
 voltron               | Git      | https://anonscm.debian.org/git/collab-maint/voltron.git
 vulture               | Git      | https://anonscm.debian.org/git/collab-maint/vulture.git
 zktop                 | Git      | https://anonscm.debian.org/cgit/collab-maint/zktop.git
(22 rows)

Hope this helps

      Andreas. 

PS: if you drop "and vcs_type = 'Git'" you also get the remaining ones in SVN which
might need even more care - but your question was targeting at my remark about those
in collab-maint.

-- 
http://fam-tille.de

[toc] | [prev] | [next] | [standalone]

#10114

Hello,

On Wed, 07 Feb 2018, W. Martin Borgert wrote:
> how about moving the Python team(s) to salsa?

Definitely!

But we might want to learn from the perl team to structure the
python-team:
https://lists.debian.org/debian-perl/2018/01/msg00039.html

We could then have everything python related in the same team
but with different sub-groups for modules, applications
and interpreter.

> Moving git packages (modules team) is very easy using
> import.sh from https://salsa.debian.org/mehdi/salsa-scripts.git

I used those scripts with a small loop to migrate pkg-security
and it worked fine.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

[toc] | [prev] | [next] | [standalone]

#10126

On 07/02/2018 08:37, W. Martin Borgert wrote:
> Hi,
> 
> how about moving the Python team(s) to salsa?

Hello,

Does Salsa support merge requests?
If so has any work been done to add support to run tests automatically?

I am being curious since I would contribute more if I had a test
feedback and human reviews :]

-- 
Antoine Musso

[toc] | [prev] | [next] | [standalone]

#10128

Hello Antoine,


Am Thu, 8 Feb 2018 19:18:03 +0100
schrieb Antoine Musso <hashar@free.fr>:
 
> Does Salsa support merge requests?

It is based on the gitlab software - thus it offers merge requests.


> If so has any work been done to add support to run tests automatically?

Yes, it includes the Gitlab-CI runner.

Cheers,
Lars

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web