Repository switch over to Salsa?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Repository switch over to Salsa?

Helge Kreutzmann-2
Hello Guilllem,
are you (when?) switching over to salsa? Are you reestablishing commit
access as it is currently?

Thanks!

Greetings

          Helge
--
      Dr. Helge Kreutzmann                     [hidden email]
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/

signature.asc (828 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Repository switch over to Salsa?

Guillem Jover
Hi!

On Sat, 2018-02-03 at 19:11:42 +0100, Helge Kreutzmann wrote:
> are you (when?) switching over to salsa?

I'm still not sure yet. I started a wiki page with some of my concerns
at <https://wiki.debian.org/Teams/Dpkg/AliothEscape>, I should update
it because some things have been fixed meanwhile.

At least salsa.d.o would keep hosting a mirror, but I'm not sure whether
to make it the canonical hosting.

> Are you reestablishing commit access as it is currently?

This is also something I'm not entirely sure about. One problem I've
had in the past is when preparing releases, if someone pushes then it
invalidates the current release process, which is annoying. Also
something I think I agree with the APT team, which they kind of
decided as policy recently with the switch to salsa is that if the
committers are not following very closely the project (so both mailing
lists and IRC), it makes it more difficult to coordinate or be on top
of what's going on.

What I've been pondering about is whether switching to a merge-request
based workflow for translations, or perhaps even a switch to weblate
might work better for everyone?

Thanks,
Guillem

Reply | Threaded
Open this post in threaded view
|

Re: Repository switch over to Salsa?

Helge Kreutzmann-2
Hello Guillem,
On Fri, Feb 09, 2018 at 03:31:00AM +0100, Guillem Jover wrote:
> On Sat, 2018-02-03 at 19:11:42 +0100, Helge Kreutzmann wrote:
> > are you (when?) switching over to salsa?
>
> I'm still not sure yet. I started a wiki page with some of my concerns
> at <https://wiki.debian.org/Teams/Dpkg/AliothEscape>, I should update
> it because some things have been fixed meanwhile.

Thanks for the pointer. Regarding the hosting site I'm neutral, as
long as I can git push/pull from/to it.

> > Are you reestablishing commit access as it is currently?
>
> This is also something I'm not entirely sure about. One problem I've
> had in the past is when preparing releases, if someone pushes then it
> invalidates the current release process, which is annoying. Also

If there is any indicator I should not push, please let me know. I
hope I did not cause any of those disturbances in the past. I stuck to
to the rules as best of my abilities.

> something I think I agree with the APT team, which they kind of
> decided as policy recently with the switch to salsa is that if the
> committers are not following very closely the project (so both mailing
> lists and IRC), it makes it more difficult to coordinate or be on top
> of what's going on.

I'm reading the mailing list, but I'm not on IRC, so if most important
infos go via the list, then I'm covered.[1]

> What I've been pondering about is whether switching to a merge-request
> based workflow for translations, or perhaps even a switch to weblate
> might work better for everyone?

I would like to stick as closely to the current workflow, as it
provides the lowest barrier. I can use git, vim, diff and friends to
easily work on the translation. Also I have the original files there
as necessary, I'm able to immediatly build everything (to view the
output) and, last but not least, fix obvious errors without disturbing
you (I did so a few times in the past, sometimes even for other
translations).

I'm not intending to switch to a mouse based / graphical / web based
work flow, at least for projects I'm havily working on.

Thanks for taking care.

Greetings

          Helge

[1] I'm not interested in detailed design discussions, so if those
    happen on IRC, I'm perfectly fine.
--
      Dr. Helge Kreutzmann                     [hidden email]
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/

signature.asc (828 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Repository switch over to Salsa?

Helge Kreutzmann-2
In reply to this post by Guillem Jover
Hello Guillem,
Alioth just shut down. Any news on the move?

On Fri, Feb 09, 2018 at 03:31:00AM +0100, Guillem Jover wrote:
> On Sat, 2018-02-03 at 19:11:42 +0100, Helge Kreutzmann wrote:
> > are you (when?) switching over to salsa?
>
> I'm still not sure yet. I started a wiki page with some of my concerns
> at <https://wiki.debian.org/Teams/Dpkg/AliothEscape>, I should update
> it because some things have been fixed meanwhile.

I just rechecked the page and I did not find the answer, just the pros
and cons of the alternatives.

> > Are you reestablishing commit access as it is currently?
>
> This is also something I'm not entirely sure about. One problem I've
> had in the past is when preparing releases, if someone pushes then it
> invalidates the current release process, which is annoying. Also
> something I think I agree with the APT team, which they kind of
> decided as policy recently with the switch to salsa is that if the
> committers are not following very closely the project (so both mailing
> lists and IRC), it makes it more difficult to coordinate or be on top
> of what's going on.
I follow the mailing list. Also I strongly follow your commit policies
(which might be improved, so please let me know). Sometimes I also
fix some very minor issue in the documentation (like spelling fixes, I
think I also unbroke other translations previously).

> What I've been pondering about is whether switching to a merge-request
> based workflow for translations, or perhaps even a switch to weblate
> might work better for everyone?

I'd strongly prefer the current workflow. Having to switch to a
(partial) web based workflow would make me seriously reconsider my
involvement. Also I'm not sure everything I've done so far (like
stated above or fixes for errors in the (old)stable translation)
would still be possible then.

Greetings

       Helge
--
      Dr. Helge Kreutzmann                     [hidden email]
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/

signature.asc (828 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Repository switch over to Salsa?

Guillem Jover
On Thu, 2018-05-31 at 18:20:35 +0200, Helge Kreutzmann wrote:
> Alioth just shut down. Any news on the move?

Yeah, I noticed, and with it even the redirector is down. :(

> On Fri, Feb 09, 2018 at 03:31:00AM +0100, Guillem Jover wrote:
> > On Sat, 2018-02-03 at 19:11:42 +0100, Helge Kreutzmann wrote:
> > > are you (when?) switching over to salsa?
> >
> > I'm still not sure yet. I started a wiki page with some of my concerns
> > at <https://wiki.debian.org/Teams/Dpkg/AliothEscape>, I should update
> > it because some things have been fixed meanwhile.
>
> I just rechecked the page and I did not find the answer, just the pros
> and cons of the alternatives.

I started discussing those options with DSA several weeks ago, but after
the initial brief discussion and conversion into an rt.debian.org ticket,
this went silent. Several days ago I asked for redirects for the dpkg.org
domain, but have not heard anything back yet. :/

I'll ping them again, and wait few more days, otherwise I'd like to
decide something by next week at the latest. Probably including an
upload to update URLs, which should have happened in general way
earlier anyway.

> > > Are you reestablishing commit access as it is currently?
> >
> > This is also something I'm not entirely sure about. One problem I've
> > had in the past is when preparing releases, if someone pushes then it
> > invalidates the current release process, which is annoying. Also
> > something I think I agree with the APT team, which they kind of
> > decided as policy recently with the switch to salsa is that if the
> > committers are not following very closely the project (so both mailing
> > lists and IRC), it makes it more difficult to coordinate or be on top
> > of what's going on.
>
> I follow the mailing list. Also I strongly follow your commit policies
> (which might be improved, so please let me know). Sometimes I also
> fix some very minor issue in the documentation (like spelling fixes, I
> think I also unbroke other translations previously).

Sure, for major releases those could be announced more promintently on
the list, to prevent those kind of situation, and I should probably do
that again more often as I used to do. The problem has usually come from
hot-fix releases which need to be pushed quickly after an initial major
release. In those cases being on IRC is very handy. OTOH using the sid
branch for those, which I was not entirely sold on, means no conflict
should arise, in theory, but one of the main reasons for that branch
usage was precisely to just avoid those racing pushes. :)

> > What I've been pondering about is whether switching to a merge-request
> > based workflow for translations, or perhaps even a switch to weblate
> > might work better for everyone?
>
> I'd strongly prefer the current workflow. Having to switch to a
> (partial) web based workflow would make me seriously reconsider my
> involvement. Also I'm not sure everything I've done so far (like
> stated above or fixes for errors in the (old)stable translation)
> would still be possible then.

Right, I can understand. Would having your own repo (say on salsa or
elsewhere) where you push to, and which I'd have as one of my remotes
(where I already always fetch from all remotes), be a workable workflow?
I'd either notice and then integrate the changes, or a mail could be
sent, in case I've missed some updates? If this would feel too
cumbersome don't hesitate to say, I'm just trying to see the various
possibilities here.

Sven, I'm also interested in your opinion, given that you are the
other active committer.

Thanks,
Guillem

Reply | Threaded
Open this post in threaded view
|

Re: Repository switch over to Salsa?

Joerg Jaspert
On 15055 March 1977, Guillem Jover wrote:
>> Alioth just shut down. Any news on the move?
> Yeah, I noticed, and with it even the redirector is down. :(

That will come back afaik.

--
bye, Joerg

Reply | Threaded
Open this post in threaded view
|

Re: Repository switch over to Salsa?

Helge Kreutzmann-2
In reply to this post by Guillem Jover
Hello Guillem,
On Fri, Jun 01, 2018 at 03:27:44AM +0200, Guillem Jover wrote:
> On Thu, 2018-05-31 at 18:20:35 +0200, Helge Kreutzmann wrote:
> > Alioth just shut down. Any news on the move?
>
> Yeah, I noticed, and with it even the redirector is down. :(

I then simply wait for your heads up. In I keep my fingers crossed
that the setup can be resolved soon.

> > > > Are you reestablishing commit access as it is currently?
> > >
> > > This is also something I'm not entirely sure about. One problem I've
> > > had in the past is when preparing releases, if someone pushes then it
> > > invalidates the current release process, which is annoying. Also
> > > something I think I agree with the APT team, which they kind of
> > > decided as policy recently with the switch to salsa is that if the
> > > committers are not following very closely the project (so both mailing
> > > lists and IRC), it makes it more difficult to coordinate or be on top
> > > of what's going on.
> >
> > I follow the mailing list. Also I strongly follow your commit policies
> > (which might be improved, so please let me know). Sometimes I also
> > fix some very minor issue in the documentation (like spelling fixes, I
> > think I also unbroke other translations previously).
>
> Sure, for major releases those could be announced more promintently on
> the list, to prevent those kind of situation, and I should probably do
> that again more often as I used to do. The problem has usually come from
> hot-fix releases which need to be pushed quickly after an initial major
> release. In those cases being on IRC is very handy. OTOH using the sid
> branch for those, which I was not entirely sold on, means no conflict
> should arise, in theory, but one of the main reasons for that branch
> usage was precisely to just avoid those racing pushes. :)
I check my repositories on a daily basis (when I'm near my primary
machine). So any strings available at least 24 hours should be
translated (dpkg is also my highes priority project), unless of
course, several dozen strings appear at once, but this happens rarely.

If it is a hotfix then I fully understand that a translation might
only make it in the next (sub-)release.

(Since I don't have access to public IRC at work, I would be blind on
that spot most of the time anyway).

> > > What I've been pondering about is whether switching to a merge-request
> > > based workflow for translations, or perhaps even a switch to weblate
> > > might work better for everyone?
> >
> > I'd strongly prefer the current workflow. Having to switch to a
> > (partial) web based workflow would make me seriously reconsider my
> > involvement. Also I'm not sure everything I've done so far (like
> > stated above or fixes for errors in the (old)stable translation)
> > would still be possible then.
>
> Right, I can understand. Would having your own repo (say on salsa or
> elsewhere) where you push to, and which I'd have as one of my remotes
> (where I already always fetch from all remotes), be a workable workflow?
If everything is automated, i.e. once you update your strings the
salsa copy would by synced automatically (this happens for another
project where I translate) and vice versa (i.e. no manual interception
on my side necessary) I'm fine with it. And it would be great if
I could still fix (if applicable) those minor issues (mainly obvious
spelling fixes).

> I'd either notice and then integrate the changes, or a mail could be
> sent, in case I've missed some updates? If this would feel too
> cumbersome don't hesitate to say, I'm just trying to see the various
> possibilities here.A

… but sending e-mails I'd rather avoid. I remember times when strings
arrived regularly or at least twice when you improved the man pages
changing quit a few strings in the process. And given that po files
are sometimes nasty in conflict resolution, I'd rather avoid
situations where you are N commits ahead because either of us
delayed/failed to send/read an e-mail and then tricky things need to
be done to sync the strings again.

Thanks for taking care.

Greetings

         Helge
--
      Dr. Helge Kreutzmann                     [hidden email]
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/

signature.asc (828 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Repository switch over to Salsa?

Sven Joachim
In reply to this post by Guillem Jover
On 2018-06-01 03:27 +0200, Guillem Jover wrote:

> On Thu, 2018-05-31 at 18:20:35 +0200, Helge Kreutzmann wrote:
>
>> On Fri, Feb 09, 2018 at 03:31:00AM +0100, Guillem Jover wrote:
>> > On Sat, 2018-02-03 at 19:11:42 +0100, Helge Kreutzmann wrote:
>
>> > > Are you reestablishing commit access as it is currently?
>> >
>> > This is also something I'm not entirely sure about. One problem I've
>> > had in the past is when preparing releases, if someone pushes then it
>> > invalidates the current release process, which is annoying. Also
>> > something I think I agree with the APT team, which they kind of
>> > decided as policy recently with the switch to salsa is that if the
>> > committers are not following very closely the project (so both mailing
>> > lists and IRC), it makes it more difficult to coordinate or be on top
>> > of what's going on.
>>
>> I follow the mailing list. Also I strongly follow your commit policies
>> (which might be improved, so please let me know). Sometimes I also
>> fix some very minor issue in the documentation (like spelling fixes, I
>> think I also unbroke other translations previously).

I also follow the mailing list, but am not on IRC 24/7.  But I could
show up there and ask before pushing to the repository, if that is
desired.

> Sure, for major releases those could be announced more promintently on
> the list, to prevent those kind of situation, and I should probably do
> that again more often as I used to do. The problem has usually come from
> hot-fix releases which need to be pushed quickly after an initial major
> release. In those cases being on IRC is very handy. OTOH using the sid
> branch for those, which I was not entirely sold on, means no conflict
> should arise, in theory, but one of the main reasons for that branch
> usage was precisely to just avoid those racing pushes. :)
>
>> > What I've been pondering about is whether switching to a merge-request
>> > based workflow for translations, or perhaps even a switch to weblate
>> > might work better for everyone?
>>
>> I'd strongly prefer the current workflow. Having to switch to a
>> (partial) web based workflow would make me seriously reconsider my
>> involvement. Also I'm not sure everything I've done so far (like
>> stated above or fixes for errors in the (old)stable translation)
>> would still be possible then.

Any web based workflow would be a turn-off for me.

> Right, I can understand. Would having your own repo (say on salsa or
> elsewhere) where you push to, and which I'd have as one of my remotes
> (where I already always fetch from all remotes), be a workable workflow?
> I'd either notice and then integrate the changes, or a mail could be
> sent, in case I've missed some updates?

Manual steps should be avoided as much as possible since they are
error-prone and tend to cause additional work.

My preference would be to keep the current workflow, but using a second
repository would also be fine as long as I don't have to deal with
resolving merge conflicts. :-)

Cheers,
       Sven

Reply | Threaded
Open this post in threaded view
|

Re: Repository switch over to Salsa?

Sergio Basto
In reply to this post by Helge Kreutzmann-2
On Fri, 2018-06-01 at 19:06 +0200, Helge Kreutzmann wrote:
> > > Alioth just shut down. Any news on the move?
> >
> > Yeah, I noticed, and with it even the redirector is down. :(
>
> I then simply wait for your heads up. In I keep my fingers crossed
> that the setup can be resolved soon.

On https://tracker.debian.org/ some redirects are working like:

https://tracker.debian.org/pkg/dpkg

but others not, like :

https://anonscm.debian.org/git/pkg-amule/amule.git

Best regards,
--
Sérgio M. B.

Reply | Threaded
Open this post in threaded view
|

Re: Repository switch over to Salsa?

Guillem Jover
In reply to this post by Sven Joachim
Hi!

On Sat, 2018-06-02 at 18:59:22 +0200, Sven Joachim wrote:
> On 2018-06-01 03:27 +0200, Guillem Jover wrote:
> > On Thu, 2018-05-31 at 18:20:35 +0200, Helge Kreutzmann wrote:
> >> On Fri, Feb 09, 2018 at 03:31:00AM +0100, Guillem Jover wrote:
> >> > On Sat, 2018-02-03 at 19:11:42 +0100, Helge Kreutzmann wrote:
> >> > > Are you reestablishing commit access as it is currently?

Hey, so the migration is almost done, I need an account name and ssh
public keys from both of you. I'll send another mail announcing the
new setup.

Thanks,
Guillem

Reply | Threaded
Open this post in threaded view
|

Re: Repository switch over to Salsa?

Ian Jackson-2
Guillem Jover writes ("Re: Repository switch over to Salsa?"):
> Hey, so the migration is almost done, I need an account name and ssh
> public keys from both of you. I'll send another mail announcing the
> new setup.

On a tangent: I recently had cause to `dgit clone dpkg' and I was
disappointed that I didn't get the proper git history.  Is there a
reason you are not using `dgit push' ?

Regards,
Ian.

--
Ian Jackson <[hidden email]>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply | Threaded
Open this post in threaded view
|

Re: Repository switch over to Salsa?

Guillem Jover
[ I had a drafted reply but lost it on a system crash and its
  subsequent /tmp cleanse. :( ]

On Mon, 2018-06-18 at 12:51:31 +0100, Ian Jackson wrote:
> Guillem Jover writes ("Re: Repository switch over to Salsa?"):
> > Hey, so the migration is almost done, I need an account name and ssh
> > public keys from both of you. I'll send another mail announcing the
> > new setup.
>
> On a tangent: I recently had cause to `dgit clone dpkg' and I was
> disappointed that I didn't get the proper git history.  Is there a
> reason you are not using `dgit push' ?

Yes, there are several reasons.

I've made a point to only use dpkg itself (the actual version being
released actually) as part of its release process, so that obvious
issues can be spotted before it even gets uploaded into the archive.
I don't even use debuild, nor any other wrapper. The process involves
mainly just a clean schroot and dpkg-buildpackage, in addition to
installing the result and rebuilding using that, then comparing the
two build artifacts, running lintian and the functional test-suite.
After that debsign (which I consider a bug in the process, that
should be fixed with the "upcoming" dpkg-sign), and dupload. Using
dgit would interfere with all this.

Another reason is that it requires to tolerate ugly history, for
which I have a very low-tolerance. :)

And another one is the implications when it comes to autogenerated
files shipped in tarballs. I find all the proposed solutions
completely unsatisfying. And this is obviously a matter of opinion,
but personally I find them all to be just bad practices. :)


When it comes to VCS and packaging workflows, I consider the native
case a non-issue. For non-native I think all of them suck, TBH. Even
the one I'm using! Where I only store the debian/ packaging bits. But
for me that's the one that sucks less. I don't think we have yet found
a VCS workflow that is universally good.

Regards,
Guillem