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

Groups > linux.debian.maint.java > #10409 > unrolled thread

Re: Import git repo from alioth to salsa

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

Contents

  Re: Import git repo from alioth to salsa Andreas Tille <andreas@an3as.eu> - 2018-04-16 20:40 +0200
    Re: Import git repo from alioth to salsa Emmanuel Bourg <ebourg@apache.org> - 2018-04-16 22:20 +0200
      Re: Import git repo from alioth to salsa tony mancill <tmancill@debian.org> - 2018-04-19 22:00 +0200
        Re: Import git repo from alioth to salsa Emmanuel Bourg <ebourg@apache.org> - 2018-04-28 10:00 +0200
          Re: Import git repo from alioth to salsa Emmanuel Bourg <ebourg@apache.org> - 2018-04-28 13:00 +0200
          Re: Import git repo from alioth to salsa Paul Wise <pabs@debian.org> - 2018-04-29 04:10 +0200
            Re: Import git repo from alioth to salsa tony mancill <tmancill@debian.org> - 2018-04-29 19:20 +0200
              Re: Import git repo from alioth to salsa Thorsten Glaser <t.glaser@tarent.de> - 2018-04-29 22:50 +0200
                Re: Import git repo from alioth to salsa Markus Koschany <apo@debian.org> - 2018-04-29 23:20 +0200
                  Re: Import git repo from alioth to salsa Markus Koschany <apo@debian.org> - 2018-05-01 14:50 +0200
                  Re: Import git repo from alioth to salsa Giovanni Mascellani <gio@debian.org> - 2018-05-01 20:40 +0200
                    Re: Import git repo from alioth to salsa Markus Koschany <apo@debian.org> - 2018-05-01 21:20 +0200
                      Re: Import git repo from alioth to salsa Emmanuel Bourg <ebourg@apache.org> - 2018-05-01 22:50 +0200
                        Re: Import git repo from alioth to salsa Markus Koschany <apo@debian.org> - 2018-05-01 23:00 +0200
                          Re: Import git repo from alioth to salsa Emmanuel Bourg <ebourg@apache.org> - 2018-05-01 23:20 +0200
                            Re: Import git repo from alioth to salsa Markus Koschany <apo@debian.org> - 2018-05-01 23:30 +0200
                              Re: Import git repo from alioth to salsa Emmanuel Bourg <ebourg@apache.org> - 2018-05-01 23:40 +0200
                                Re: Import git repo from alioth to salsa Markus Koschany <apo@debian.org> - 2018-05-01 23:50 +0200
              Re: Import git repo from alioth to salsa Paul Wise <pabs@debian.org> - 2018-04-30 04:30 +0200
            Re: Import git repo from alioth to salsa Emmanuel Bourg <ebourg@apache.org> - 2018-04-30 09:30 +0200
              Re: Import git repo from alioth to salsa Giovanni Mascellani <gio@debian.org> - 2018-04-30 13:50 +0200
                Re: Import git repo from alioth to salsa Emmanuel Bourg <ebourg@apache.org> - 2018-04-30 19:30 +0200
                  Re: Import git repo from alioth to salsa Markus Koschany <apo@debian.org> - 2018-04-30 21:30 +0200
                    Re: Import git repo from alioth to salsa Emmanuel Bourg <ebourg@apache.org> - 2018-05-01 22:10 +0200
                      Re: Import git repo from alioth to salsa Markus Koschany <apo@debian.org> - 2018-05-04 11:50 +0200
                        Re: Import git repo from alioth to salsa Emmanuel Bourg <ebourg@apache.org> - 2018-05-04 15:30 +0200
                          Re: Import git repo from alioth to salsa Emmanuel Bourg <ebourg@apache.org> - 2018-05-04 15:50 +0200
                          Re: Import git repo from alioth to salsa Markus Koschany <apo@debian.org> - 2018-05-04 15:50 +0200
                  Re: Import git repo from alioth to salsa Giovanni Mascellani <gio@debian.org> - 2018-04-30 22:10 +0200
                    Re: Import git repo from alioth to salsa Emmanuel Bourg <ebourg@apache.org> - 2018-05-01 22:30 +0200
                      Re: Import git repo from alioth to salsa Giovanni Mascellani <gio@debian.org> - 2018-05-02 09:10 +0200

Page 1 of 2  [1] 2  Next page →

#10409 — Re: Import git repo from alioth to salsa

Hi,

On Thu, 1 Feb 2018 Emmanuel Bourg wrote:
> I personally would prefer migrating all
> the repositories simultaneously, leaving only the packages still managed
> by Subversion on Alioth for a migration later.

I noticed that under

   https://salsa.debian.org/java-team/

some packages are migrated but the mass of packages is on Alioth as far
as I can see.  Is there any migration date?  I'm just asking since Alioth
will be switched of in about two weeks.

Kind regards

        Andreas.

-- 
http://fam-tille.de

[toc] | [next] | [standalone]

#10410

Le 16/04/2018 à 20:30, Andreas Tille a écrit :

> I noticed that under
> 
>    https://salsa.debian.org/java-team/
> 
> some packages are migrated but the mass of packages is on Alioth as far
> as I can see.  Is there any migration date?  I'm just asking since Alioth
> will be switched of in about two weeks.

Hi Andreas,

Markus has created/migrated some packages there, and I've used
java-package as a test repository to experiment with the migration.

So far I've prepared a migration script [1] that does the following:
- Imports the repository from Alioth to Salsa
- Disables the unnecessary Salsa features (issues, snippets, wiki, jobs)
- Configures the hook tagging pending bugs in the BTS
- Configures the hook notifying the #debian-java IRC channel on events
(with KGB)
- Configures the Gitlab's emails-on-push hook (targeting
pkg-java-commits@lists.alioth.debian.org and dispatch@tracker.debian.org)

There is also a repository creation script [2] that can be used instead
of /srv/git.debian.org/git/pkg-java/setup-repository on Alioth.

The migration script is still missing a few things :
1. It doesn't disable the Alioth repository after the migration
2. The emails-on-push hook is incomplete because it only notifies about
pushes and not about other events like comments and merge requests. I
started working on such a hook [3] but it isn't ready yet. It's probably
better to start the migration without this hook and add it latter to the
repositories.

Assuming I complete the script this week we can consider moving the
repositories next week.

Emmanuel Bourg

[1]
https://anonscm.debian.org/cgit/pkg-java/pkg-java-scripts.git/tree/migrate-to-salsa
[2]
https://anonscm.debian.org/cgit/pkg-java/pkg-java-scripts.git/tree/setup-salsa-repository
[3] https://salsa.debian.org/salsa/webhook/merge_requests/6

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

#10421

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

On Mon, Apr 16, 2018 at 10:16:07PM +0200, Emmanuel Bourg wrote:
> Le 16/04/2018 à 20:30, Andreas Tille a écrit :
> 
> > I noticed that under
> > 
> >    https://salsa.debian.org/java-team/
> > 
> > some packages are migrated but the mass of packages is on Alioth as far
> > as I can see.  Is there any migration date?  I'm just asking since Alioth
> > will be switched of in about two weeks.
> 
> Hi Andreas,
> 
> Markus has created/migrated some packages there, and I've used
> java-package as a test repository to experiment with the migration.
> 
> So far I've prepared a migration script [1] that does the following:
> - Imports the repository from Alioth to Salsa
> - Disables the unnecessary Salsa features (issues, snippets, wiki, jobs)
> - Configures the hook tagging pending bugs in the BTS
> - Configures the hook notifying the #debian-java IRC channel on events
> (with KGB)
> - Configures the Gitlab's emails-on-push hook (targeting
> pkg-java-commits@lists.alioth.debian.org and dispatch@tracker.debian.org)
> 
> There is also a repository creation script [2] that can be used instead
> of /srv/git.debian.org/git/pkg-java/setup-repository on Alioth.
> 
> The migration script is still missing a few things :
> 1. It doesn't disable the Alioth repository after the migration
> 2. The emails-on-push hook is incomplete because it only notifies about
> pushes and not about other events like comments and merge requests. I
> started working on such a hook [3] but it isn't ready yet. It's probably
> better to start the migration without this hook and add it latter to the
> repositories.
> 
> Assuming I complete the script this week we can consider moving the
> repositories next week.
> 
> Emmanuel Bourg
> 
> [1]
> https://anonscm.debian.org/cgit/pkg-java/pkg-java-scripts.git/tree/migrate-to-salsa
> [2]
> https://anonscm.debian.org/cgit/pkg-java/pkg-java-scripts.git/tree/setup-salsa-repository
> [3] https://salsa.debian.org/salsa/webhook/merge_requests/6

Hi Emmanuel,

Regarding item (1), perhaps you can leverage the disable-repository
script [4]?  I used the migration scripts from that repo for non-team
migrations with good results.

Cheers,
tony

[4] https://salsa.debian.org/anarcat/alioth-migration/blob/master/disable-repository

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

#10430

On 19/04/2018 21:52, tony mancill wrote:

> Regarding item (1), perhaps you can leverage the disable-repository
> script [4]?  I used the migration scripts from that repo for non-team
> migrations with good results.

Thank you Tony. I was leaning toward such a solution, but considering
that Alioth is going to be killed and the repositories archived and
moved offline there is no real point disabling the migrated
repositories. I think I'll just move them under a special directory (for
example /srv/git.debian.org/git/pkg-java/migrated).

Emmanuel Bourg

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

#10431

On 27/04/2018 22:48, Emmanuel Bourg wrote:

> I think I'll just move them under a special directory (for
> example /srv/git.debian.org/git/pkg-java/migrated).

I migrated a first batch of ~100 Maven related packages. Moving the
repositories on Alioth wasn't a great idea since the import process on
Salsa is asynchronous. The migration script moved the repositories
before the import was complete and I had to fix about half of the
migrated repositories manually.

Emmanuel Bourg

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

#10434

On Sat, Apr 28, 2018 at 4:48 AM, Emmanuel Bourg wrote:

> Thank you Tony. I was leaning toward such a solution, but considering
> that Alioth is going to be killed and the repositories archived and
> moved offline there is no real point disabling the migrated
> repositories. I think I'll just move them under a special directory (for
> example /srv/git.debian.org/git/pkg-java/migrated).

I'd suggest deleting the migrated repositories so that DSA doesn't
have to store a copy of them in the alioth archive forever.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

#10435

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

On Sun, Apr 29, 2018 at 10:00:58AM +0800, Paul Wise wrote:
> On Sat, Apr 28, 2018 at 4:48 AM, Emmanuel Bourg wrote:
> 
> > Thank you Tony. I was leaning toward such a solution, but considering
> > that Alioth is going to be killed and the repositories archived and
> > moved offline there is no real point disabling the migrated
> > repositories. I think I'll just move them under a special directory (for
> > example /srv/git.debian.org/git/pkg-java/migrated).
> 
> I'd suggest deleting the migrated repositories so that DSA doesn't
> have to store a copy of them in the alioth archive forever.

Hi Paul,

I realize that this isn't the right forum, so please redirect
appropriately for follow-ups, but do you know whether there is any plan
for a redirect host/service for the alioth repos?  The BTS is full of
links commits in Alioth, so the migration will leave all of these links
broken.

It is for this reason that I have been using the migration scripts + the
disable hooks.  It gives users a pointer of sorts.  (For example, see
[1].)  My concern is that if I delete the repo, the redirect crumbtrail
will be gone forever.

Thanks,
tony

[1] https://anonscm.debian.org/cgit/collab-maint/bobcat

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

#10437

Hi tony,

> On Sun, Apr 29, 2018 at 10:00:58AM +0800, Paul Wise wrote:

> > I'd suggest deleting the migrated repositories so that DSA doesn't
> > have to store a copy of them in the alioth archive forever.

in fact we were *requested* to do so by DSA, so we SHOULD comply.

> appropriately for follow-ups, but do you know whether there is any plan
> for a redirect host/service for the alioth repos?  The BTS is full of
> links commits in Alioth, so the migration will leave all of these links
> broken.

As far as I’m informed, due to the massively different structure
of GitLab, such a service cannot be provided with reasonable or
even somewhat unreasonable effort, and there *were* tons of URL
redirection layers already anyway, so they decided on a clean cut.

I’m afraid you will have to somehow change all these URLs in the
place where they’re written.

Disclaimer: I’m not happy with the entire move either (in fact,
I’ve moved my not otherwise maintained repos to another FusionForge
instance instead of to Salsa), just informing about what I seem to
recall we were told.

bye,
//mirabilos
-- 
Yes, I hate users and I want them to suffer.
	-- Marco d'Itri on gmane.linux.debian.devel.general

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

#10438

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

Am 29.04.2018 um 22:33 schrieb Thorsten Glaser:
[...]
> As far as I’m informed, due to the massively different structure
> of GitLab, such a service cannot be provided with reasonable or
> even somewhat unreasonable effort, and there *were* tons of URL
> redirection layers already anyway, so they decided on a clean cut.
> 
> I’m afraid you will have to somehow change all these URLs in the
> place where they’re written.

It is possible to redirect alioth URLs to salsa. For instance when I
click on the browser link of armagetronad I will be redirected to
salsa.debian.org now. This is implemented for all packages maintained by
the games team.

https://anonscm.debian.org/cgit/pkg-games/armagetronad.git

Creating a similar mapping for pkg-java should be doable.

I'm also not happy with the current approach of changing thousands of
VCS URLs again. It was also made clear that we have to go through the
same renaming again should we ever move away from Gitlab.

I suggest the following:

Let's remove all VCS fields from all our packages. Those fields are
optional and not required. We simply use conventions. All packages are
maintained in Git at salsa.debian.org. Period. The address space always
looks like

https://salsa.debian.org/java-team/${SourcePackageName}

I intend to file bugs against tracker.debian.org tomorrow and request
two new features. The first one is the ability to create custom fields
so that we could make it clear that java-team packages are maintained at
salsa.debian.org. (more use cases are conceivable)

The other one is the ability to override the value of a certain field,
e.g. the VCS field, because tracker.debian.org already knows what
packages belong to a certain team, so it would become trivial to
autogenerate VCS links in the future. No matter what the next service is
called it would be a matter of minutes instead of days to change all VCS
links and make them immediately visible to all users. At the moment we
have lots of broken links anyway and tracker.debian.org seems to me the
best option to maintain such information in an efficient way.

Regards,

Markus

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

#10454

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

Am 29.04.2018 um 23:13 schrieb Markus Koschany:
[...]
> I suggest the following:
> 
> Let's remove all VCS fields from all our packages. Those fields are
> optional and not required. We simply use conventions. All packages are
> maintained in Git at salsa.debian.org. Period. The address space always
> looks like
> 
> https://salsa.debian.org/java-team/${SourcePackageName}
> 
> I intend to file bugs against tracker.debian.org tomorrow and request
> two new features. 

[...]

FTR: Those feature requests are tracked now as

https://bugs.debian.org/897225
https://bugs.debian.org/897227

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

#10457

Hi,

Il 29/04/2018 23:13, Markus Koschany ha scritto:
> Let's remove all VCS fields from all our packages. Those fields are
> optional and not required. We simply use conventions. All packages are
> maintained in Git at salsa.debian.org. Period.

In line of principle I agree that some package meta information like
Vcs-* and others should be maintained in databases that are independent
of the specific .dsc packages and should not require an upload to be
updated. However, I also personally value homogeneity among Debian
packages, a value so rare that I actually would think twice before
dispersing it. Use different conventions with respect to anything else
make contributions more difficult and makes some tools less useful or
even useless.

So, unless the proposal is about pushing for a general acceptance of
this change in Debian and about updating somewhat systematically all the
available tools, I personally disagree with it.

Just my 2 cents, fully aware that my participation in this team is
tangential at its best.

Giovanni.
-- 
Giovanni Mascellani <g.mascellani@gmail.com>
Postdoc researcher - Université Libre de Bruxelles

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

#10458

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

Hi,

Am 01.05.2018 um 20:31 schrieb Giovanni Mascellani:
> Hi,
> 
> Il 29/04/2018 23:13, Markus Koschany ha scritto:
>> Let's remove all VCS fields from all our packages. Those fields are
>> optional and not required. We simply use conventions. All packages are
>> maintained in Git at salsa.debian.org. Period.
> 
> In line of principle I agree that some package meta information like
> Vcs-* and others should be maintained in databases that are independent
> of the specific .dsc packages and should not require an upload to be
> updated. However, I also personally value homogeneity among Debian
> packages, a value so rare that I actually would think twice before
> dispersing it. Use different conventions with respect to anything else
> make contributions more difficult and makes some tools less useful or
> even useless.

The reality is there is no homogeneity in regards with VCS fields in
Debian. They are completely optional. Some people don't use them at all,
some are still stuck with http://git.debian.org addresses, then we have
http|https://anonscm.debian.org or some random github/gitlab address.
Some links are broken for years. I know because I have changed this in
hundreds of packages before. I don't see the technical merit of those
fields if all you have to remember is: the tool is called git and your
source package name.

git clone https://salsa.debian.org/java-team/myawesomepackage

It is a misbelief that contributions would be more difficult without
optional values like VCS fields in debian/control. On the contrary the
work flow would become simpler and less repetitive. No longer updating
VCS or Uploader fields for 1000+ packages. Though our answer to more
boilerplate is to create more tools to deal with it. Instead of
simplicity we force contributors to add and maintain even more information.

> So, unless the proposal is about pushing for a general acceptance of
> this change in Debian and about updating somewhat systematically all the
> available tools, I personally disagree with it.

I have tried to discuss this on debian-devel but as usual there is
always someone who strongly disagrees, mostly those people who update
five packages per year. In my opinion there is no need to convince
everyone. It's completely fine if they want to keep their VCS fields.
I'm talking about a pragmatical decision for one team.

Regards,

Markus

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

#10461

Le 01/05/2018 à 21:18, Markus Koschany a écrit :

> I have tried to discuss this on debian-devel but as usual there is
> always someone who strongly disagrees, mostly those people who update
> five packages per year. In my opinion there is no need to convince
> everyone. It's completely fine if they want to keep their VCS fields.
> I'm talking about a pragmatical decision for one team.

I use debcheckout a lot to fetch the packages I work on, and AFAIK it
relies on the Vcs-* fields. I don't mind dropping the Vcs-* fields in
our packages but only after this tool is updated to use an alternate
source of repository URLs.

Emmanuel Bourg

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

#10462

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

Am 01.05.2018 um 22:49 schrieb Emmanuel Bourg:
> Le 01/05/2018 à 21:18, Markus Koschany a écrit :
> 
>> I have tried to discuss this on debian-devel but as usual there is
>> always someone who strongly disagrees, mostly those people who update
>> five packages per year. In my opinion there is no need to convince
>> everyone. It's completely fine if they want to keep their VCS fields.
>> I'm talking about a pragmatical decision for one team.
> 
> I use debcheckout a lot to fetch the packages I work on, and AFAIK it
> relies on the Vcs-* fields. I don't mind dropping the Vcs-* fields in
> our packages but only after this tool is updated to use an alternate
> source of repository URLs.

debcheckout https://salsa.debian.org/java-team/yourpackage ?

I don't understand why you would need such a tool that simply calls

git clone

though...

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

#10463

Le 01/05/2018 à 22:54, Markus Koschany a écrit :

> debcheckout https://salsa.debian.org/java-team/yourpackage ?
> 
> I don't understand why you would need such a tool that simply calls
> 
> git clone
> 
> though...

It also pulls the upstream tarball and the .dsc of the latest upload.

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

#10464

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

Am 01.05.2018 um 23:17 schrieb Emmanuel Bourg:
> Le 01/05/2018 à 22:54, Markus Koschany a écrit :
> 
>> debcheckout https://salsa.debian.org/java-team/yourpackage ?
>>
>> I don't understand why you would need such a tool that simply calls
>>
>> git clone
>>
>> though...
> 
> It also pulls the upstream tarball and the .dsc of the latest upload.

apt source yourpackage ?

Seriously I can write you a little shell script that does all that for
you too. If this is the only _real_ blocker, I'm more than happy to do that.

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

#10465

Le 01/05/2018 à 23:21, Markus Koschany a écrit :

> apt source yourpackage ?

This doesn't give a Git working copy.


> Seriously I can write you a little shell script that does all that for
> you too. If this is the only _real_ blocker, I'm more than happy to do that.

We'll probably also want to preserve the links to the VCS on
tracker.debian.org.

I think the right plan would be to get #897227 implemented, and then
update debcheckout to use the overridden values from tracker.debian.org.

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

#10466

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

Am 01.05.2018 um 23:35 schrieb Emmanuel Bourg:
> Le 01/05/2018 à 23:21, Markus Koschany a écrit :
> 
>> apt source yourpackage ?
> 
> This doesn't give a Git working copy.

The command git clone will give you a working copy.

You can also use

git clone git@salsa.debian.org:java-team/yourpackagegit.git

if you prefer to have all variables set correctly right from the start.

In addition there is also gbp clone which will automatically checkout
master, upstream and pristine-tar branch in one go. This is usually all
I need to work from. Maybe this is simply a matter of different work
flows but surely not a reason why VCS fields in debian/control fields
are required. You can also call both commands in a script with the
source package name as a parameter.
>> Seriously I can write you a little shell script that does all that for
>> you too. If this is the only _real_ blocker, I'm more than happy to do that.
> 
> We'll probably also want to preserve the links to the VCS on
> tracker.debian.org.
> 
> I think the right plan would be to get #897227 implemented, and then
> update debcheckout to use the overridden values from tracker.debian.org.

Yes, that's certainly a bonus but not a real blocker for me because very
soon all source packages, including the old SVN repos, will be pushed to
salsa.debian.org. Now we have a uniform address space which is easy to
remember. Not really a show stopper for a handful of regular
contributors IMO.

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

#10439

On Mon, Apr 30, 2018 at 1:18 AM, tony mancill wrote:

> I realize that this isn't the right forum, so please redirect
> appropriately for follow-ups, but do you know whether there is any plan
> for a redirect host/service for the alioth repos?  The BTS is full of
> links commits in Alioth, so the migration will leave all of these links
> broken.

The Alioth/Salsa folks are providing a redirector:

https://salsa.debian.org/salsa/AliothRewriter

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

#10440

Le 29/04/2018 à 04:00, Paul Wise a écrit :

> I'd suggest deleting the migrated repositories so that DSA doesn't
> have to store a copy of them in the alioth archive forever.

Yes, I plan to do that once I'm confident the migration worked properly.

Emmanuel Bourg

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web