Moving away from (unsupportable) FusionForge on Alioth?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
169 messages Options
1234 ... 9
Reply | Threaded
Open this post in threaded view
|

Moving away from (unsupportable) FusionForge on Alioth?

Boyuan Yang
Hello all,

I am worried about the status of FusionForge (and thus the development workflow
around Alioth) for Debian.

Recently I had a discussion on #alioth @OFTC asking for the possibility or
plan of upgrading alioth.debian.org from Wheezy to newer Jessie or Stretch. We
know Wheezy *is* EOL now with extended LTS support till 2018/05. One of the
admins ("formorer") said things won't change till Wheezy LTS EOL since
upgrading will surely break fusionforge and **no one** can fix fusionforge
after that. The last person who touched FusionForge is Roland Mas (in CC
list). In my understanding that means fusionforge is already in an
unmaintained state even for now.

Wheezy LTS EOL will arrive within one year. After that the unavailability of
Alioth will surely break everything around Alioth: the Alioth account system,
Git/SVN/CVS repository and web interfaces, alioth maillist and so on. Debian's
development workflow will just break down. And I believe people will not accept
a platform with security holes as one of Debian's basic infrastructures.

As a result, I'm writing to suggest we find an answer to such a problem soon.
Migration to Jessie or Stretch with new FusionForge version might be possible.
Or we should just drop outdated FusionForge and move to some modern platforms
like GitLab (with an alternated workflow possibly).

There are much room for discussion but we should start evaluation without
delay, since migration would take much time and the time left is pretty
limited.

--
Sincerely,
Boyuan Yang

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

Re: Moving away from (unsupportable) FusionForge on Alioth?

Pirate Praveen-3
On ഞായര്‍ 14 മെയ് 2017 02:23 വൈകു, Boyuan Yang wrote:
> As a result, I'm writing to suggest we find an answer to such a problem soon.
> Migration to Jessie or Stretch with new FusionForge version might be possible.
> Or we should just drop outdated FusionForge and move to some modern platforms
> like GitLab (with an alternated workflow possibly).

This is already planned (though pagure instead of gitlab). Anyone who
wish to see it happen faster can help with
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829046


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

Re: Moving away from (unsupportable) FusionForge on Alioth?

Yao Wei (=?UTF-8?Q?=E9=AD=8F=E9=8A=98=E5=BB=B7?=)
Hi,

Are there a discussion list of people working on the issue? I'd like to
follow and see if there's any I could help.

If no, could this issue be submitted as a Debian bug?

Thanks,
Yao Wei

On Sun, May 14, 2017 at 02:33:19PM +0530, Pirate Praveen wrote:
> This is already planned (though pagure instead of gitlab). Anyone who
> wish to see it happen faster can help with
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829046
>

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

Re: Moving away from (unsupportable) FusionForge on Alioth?

Pirate Praveen-3
On ഞായര്‍ 14 മെയ് 2017 02:46 വൈകു, Yao Wei wrote:
> Hi,
>
> Are there a discussion list of people working on the issue? I'd like to
> follow and see if there's any I could help.
>
> If no, could this issue be submitted as a Debian bug?

As far as I understand, the only thing that is blocking is non
availability of pagure package.

So helping fix this would help move this forward (currently pagure tests
are failing).
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829046
>>

After we have the package, then DSA standard processes for new service
would follow, I assume.


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

Re: Moving away from (unsupportable) FusionForge on Alioth

lumin
In reply to this post by Boyuan Yang

AFIK there is a gitlab instance ready for use:
  http://gitlab.debian.net/

Several months ago when people are talking about
replacing git.d.o with a Gitlab instance, many
Git services, including Gitlab and Gogs, are
compared. However they are Git-only and hence
not so appropriate for Alioth use.

A list of other forges here:
  https://wiki.debian.org/Alioth/OtherForges

On the other hand, I fancy modern platforms such
as Gitlab, as a user. And wondering when Debian
will update its homepage (www.d.o) to a modern
design[1].

[1] This is off-thread, but some of my young
    friends just gave up trying Debian at the
    first glance at our homepage.

Best,
lumin

Reply | Threaded
Open this post in threaded view
|

Re: Moving away from (unsupportable) FusionForge on Alioth?

Boyuan Yang
In reply to this post by Pirate Praveen-3
在 2017年5月14日星期日 CST 下午3:04:26,Pirate Praveen 写道:

> As far as I understand, the only thing that is blocking is non
> availability of pagure package.
>
> So helping fix this would help move this forward (currently pagure tests
> are failing).
>
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829046
>
> After we have the package, then DSA standard processes for new service
> would follow, I assume.
I'm a little bit confused. The bug forwarding address in #829046 points at
http://git.sergiodj.net/, however I couldn't find packaging for pagure
anywhere. Seems all deleted sometime before.

The repository on collab-maint stops at September 2016 and lacks the work
around December 2016.

Could you tell me where can I find the proper packaging repository?

Thanks!

--
Boyuan Yang

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

Re: Moving away from (unsupportable) FusionForge on Alioth?

Pirate Praveen-3
On ഞായര്‍ 14 മെയ് 2017 08:20 വൈകു, Boyuan Yang wrote:
> I'm a little bit confused. The bug forwarding address in #829046 points at
> http://git.sergiodj.net/, however I couldn't find packaging for pagure
> anywhere. Seems all deleted sometime before.

I don't know why Sergio does not want to create a stable repo at alioth.

> The repository on collab-maint stops at September 2016 and lacks the work
> around December 2016.

Sergio,
 Can we finalize on collab-maint and not resetting history for every change?

> Could you tell me where can I find the proper packaging repository?

I have pushed my copy here
https://git.fosscommunity.in/praveen/pagure

It was originally at git://git.sergiodj.net/debian/pagure-new.git


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

Re: Moving away from (unsupportable) FusionForge on Alioth?

Sean Whitton
In reply to this post by Boyuan Yang
Hello,

On Sun, May 14, 2017 at 04:53:18PM +0800, Boyuan Yang wrote:
> As a result, I'm writing to suggest we find an answer to such a problem soon.
> Migration to Jessie or Stretch with new FusionForge version might be possible.
> Or we should just drop outdated FusionForge and move to some modern platforms
> like GitLab (with an alternated workflow possibly).
>
> There are much room for discussion but we should start evaluation without
> delay, since migration would take much time and the time left is pretty
> limited.

One possibility that I don't believe has yet been raised is a minimal
git hosting tool, like gitolite.  This is stable, supported software,
and there is a good Debian package in the archive.

Alitoh is 90% simple git hosting, 5% managing push access to git repos,
and 5% mailing lists.  Alioth lists could be moved to lists.d.o.  As for
access control, the current situation with -guest accounts must be
rewritten anyway, because it is tied to FusionForge.  We could extend
sso.d.o to handle registering -guest accounts, and then use some scripts
to make all sso.d.o users visible to gitolite.

Perhaps it is simply naïve to think that a piece of software as simple
as gitolite could serve our needs.  However, one of the main blockers
that keeps coming up in these threads is that many of us are very uneasy
about monolithic web services like gitlab and pagure.  I suspect that a
big part of the worry is that we'll be in a similar situation to where
we find ourselves with FusionForge, a few years down the line.  So it is
worth discussing alternatives to another monolithic web service.

(None of this helps with non-git repos on alioth, but neither do gitlab
or pagure.)

--
Sean Whitton

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

Re: Moving away from (unsupportable) FusionForge on Alioth?

Ben Hutchings-3
On Sun, 2017-05-14 at 10:49 -0700, Sean Whitton wrote:

> Hello,
>
> On Sun, May 14, 2017 at 04:53:18PM +0800, Boyuan Yang wrote:
> > As a result, I'm writing to suggest we find an answer to such a problem soon.
> > Migration to Jessie or Stretch with new FusionForge version might be possible. 
> > Or we should just drop outdated FusionForge and move to some modern platforms 
> > like GitLab (with an alternated workflow possibly).
> >
> > There are much room for discussion but we should start evaluation
> > without 
> > delay, since migration would take much time and the time left is
> > pretty 
> > limited.
>
> One possibility that I don't believe has yet been raised is a minimal
> git hosting tool, like gitolite.  This is stable, supported software,
> and there is a good Debian package in the archive.
>
> Alitoh is 90% simple git hosting, 5% managing push access to git repos,
> and 5% mailing lists.
Let's say VCS hosting, not git hosting.

> Alioth lists could be moved to lists.d.o.  As for
> access control, the current situation with -guest accounts must be
> rewritten anyway, because it is tied to FusionForge.  We could extend
> sso.d.o to handle registering -guest accounts, and then use some scripts
> to make all sso.d.o users visible to gitolite.

Would gitolite be able to support the most popular types of git hooks
(e.g. mail and IRC notifications for pushes)?

> Perhaps it is simply naïve to think that a piece of software as simple
> as gitolite could serve our needs.  However, one of the main blockers
> that keeps coming up in these threads is that many of us are very uneasy
> about monolithic web services like gitlab and pagure.  I suspect that a
> big part of the worry is that we'll be in a similar situation to where
> we find ourselves with FusionForge, a few years down the line.  So it is
> worth discussing alternatives to another monolithic web service.

There is no free lunch.  The more we want to be able to control our
code hosting, the more time Debian people will have to spend on it over
the long term.  I don't think it makes much difference whether the
implementation is monolithic or put together from more independent
pieces.

> (None of this helps with non-git repos on alioth, but neither do gitlab
> or pagure.)

Here's a tally of live packaging repositories hosted on Alioth, based
on Vcs fields for sources in unstable:

$ for type in arch bzr cvs darcs git hg mtn svn; do
>     printf '%s: ' $type
>     grep-dctrl -FVcs-$type -sPackage 'debian.org' /var/lib/apt/lists/httpredir.debian.org_debian_dists_unstable_*_Sources \
>     | wc -l
> done \
> | sort -k2 -nr
git: 18907
svn: 2377
bzr: 71
hg: 27
darcs: 22
arch: 7
cvs: 2
mtn: 0

It looks like git hosting would cover ~90% and git+svn would cover
>99%.

Ben.

--
Ben Hutchings
Life is what happens to you while you're busy making other plans.
                                                               - John
Lennon


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

Re: Moving away from (unsupportable) FusionForge on Alioth?

Zlatan Todoric-2


On 05/14/2017 11:06 PM, Ben Hutchings wrote:

>
> Here's a tally of live packaging repositories hosted on Alioth, based
> on Vcs fields for sources in unstable:
>
> $ for type in arch bzr cvs darcs git hg mtn svn; do
>>     printf '%s: ' $type
>>     grep-dctrl -FVcs-$type -sPackage 'debian.org' /var/lib/apt/lists/httpredir.debian.org_debian_dists_unstable_*_Sources \
>>     | wc -l
>> done \
>> | sort -k2 -nr
> git: 18907
> svn: 2377
> bzr: 71
> hg: 27
> darcs: 22
> arch: 7
> cvs: 2
> mtn: 0
>
> It looks like git hosting would cover ~90% and git+svn would cover
>> 99%.
>
Or convert svn ones to git and simplify things?

Reply | Threaded
Open this post in threaded view
|

Re: Moving away from (unsupportable) FusionForge on Alioth?

Sean Whitton
In reply to this post by Ben Hutchings-3
On Sun, May 14, 2017 at 10:06:06PM +0100, Ben Hutchings wrote:
> > Alitoh is 90% simple git hosting, 5% managing push access to git repos,
> > and 5% mailing lists.
>
> Let's say VCS hosting, not git hosting.

Yes, I should have said that.

> > Alioth lists could be moved to lists.d.o.  As for access control,
> > the current situation with -guest accounts must be rewritten anyway,
> > because it is tied to FusionForge.  We could extend sso.d.o to
> > handle registering -guest accounts, and then use some scripts to
> > make all sso.d.o users visible to gitolite.
>
> Would gitolite be able to support the most popular types of git hooks
> (e.g. mail and IRC notifications for pushes)?

Yes, it has support for hooks, but it might require admins to enable
those hooks (possibly we could make it possible for all DDs to do this).

> Here's a tally of live packaging repositories hosted on Alioth, based
> on Vcs fields for sources in unstable:

Thank you for gathering this info.  I'm surprised there are so many svn
repos, and that there are so few hg repos.

--
Sean Whitton

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

Re: Moving away from (unsupportable) FusionForge on Alioth?

Ben Hutchings-3
In reply to this post by Zlatan Todoric-2
On Sun, 2017-05-14 at 23:26 +0200, Zlatan Todoric wrote:

>
> On 05/14/2017 11:06 PM, Ben Hutchings wrote:
> >
> > Here's a tally of live packaging repositories hosted on Alioth, based
> > on Vcs fields for sources in unstable:
> >
> > $ for type in arch bzr cvs darcs git hg mtn svn; do
> > >     printf '%s: ' $type
> > >     grep-dctrl -FVcs-$type -sPackage 'debian.org' /var/lib/apt/lists/httpredir.debian.org_debian_dists_unstable_*_Sources \
> > >     | wc -l
> > > done \
> > > | sort -k2 -nr
> >
> > git: 18907
> > svn: 2377
> > bzr: 71
> > hg: 27
> > darcs: 22
> > arch: 7
> > cvs: 2
> > mtn: 0
> >
> > It looks like git hosting would cover ~90% and git+svn would cover
> > >99%.
>
> Or convert svn ones to git and simplify things?
That's not easy to do in general, as svn doesn't require you to label
which parts of the directory hierarchy are tags or branches... or to
separate independent projects.  There are conventions that make it
easier to guess, but:

- Not everything follows them
- Repositories can be reorganised so that branches move between
directories
- It's entirely possible to copy to from the wrong directory level when
tagging, which results in nonsensical history even if you revert the
change

Here's what it took for the kernel svn repository:
https://anonscm.debian.org/cgit/kernel/d-k-conversion.git/tree/kernel.rules
But svn2git still couldn't handle everything, so we needed a lot of
post-processing in this script too:
https://anonscm.debian.org/cgit/kernel/d-k-conversion.git/tree/convert.sh

I suspect this was one of the messier repositories, but I'm also sure
it's not the only one that could not be handled automatically.

Ben.

--
Ben Hutchings
Life is what happens to you while you're busy making other plans.
                                                               - John
Lennon

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

Re: Moving away from (unsupportable) FusionForge on Alioth?

Holger Levsen-2
In reply to this post by Sean Whitton
On Sun, May 14, 2017 at 10:49:34AM -0700, Sean Whitton wrote:
> Alitoh is 90% simple git hosting, 5% managing push access to git repos,
> and 5% mailing lists.

I think you are forgetting about the other 90% of the work here…

And that is a really huge task, I'm wondering whether actually a GR might be
a useful tool for this:

 [1] Yes, we should shutdown (cvs|svn|git|bzr|$some_more|$actually_a_lot_project_pages|lists).alioth.debian.org
     and many many cronjobs on 2018-12-31 and make it readonly on 2018-05-31
     (=end of wheezy LTS).
 [2] further discussion.

If we had this GR in say, a month, projects would have almost a year to migrate
their stuff away nicely, and 18 months to do it a bit more painfully.

And it would give the current alioth maintainer(s?) moral support to do what
technically seems somewhat unavoidable…

The difficulty I here see in wording of the GR, which should not become
bikeshedding, eg. I would leave out such details like how to deal with existing
useraccounts…

My idea with the GR is to give the alioth maintainers moral support
to shutdown this system, which served us well for so long, now & properly.

Maybe a mailinglist discussion is sufficient for this too ;-)

(All this assuming upgrading it is *really* a hopeless task… somewhat I dont
think it is, eg I guess one could put the app into a container and upgrade the
host to jessie and then stretch… but I would really love a clean restart too.
Having a git repo for every Debian package by default and design would
be lovely, despite git is broken because of sha1, yada yada yada.)

I somewhat got distracted from writing a short answer about how some other 90%
are missing in the above "simple description". Guess it's way more complicated
after all… so, thanks to all past and current alioth maintainers, I'd like my
bikeshed blue & new & shiny. ;-)


--
cheers,
        Holger

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

Re: Moving away from (unsupportable) FusionForge on Alioth?

Holger Levsen-2
In reply to this post by Ben Hutchings-3
On Sun, May 14, 2017 at 10:06:06PM +0100, Ben Hutchings wrote:

> $ for type in arch bzr cvs darcs git hg mtn svn; do
> >     printf '%s: ' $type
> >     grep-dctrl -FVcs-$type -sPackage 'debian.org' /var/lib/apt/lists/httpredir.debian.org_debian_dists_unstable_*_Sources \
> >     | wc -l
> > done \
> > | sort -k2 -nr
> git: 18907
> svn: 2377
> bzr: 71
> hg: 27
> darcs: 22
> arch: 7
> cvs: 2
> mtn: 0
thanks for this useful stats, Ben!

cvs is also used by the Debian website, which migration to GIT is
tracked at https://wiki.debian.org/WebsiteGitTransition by Laura.

(just wanting to say that we don't wanna shutdown cvs.debian.org while
www.debian.org still needs it to be build…)


--
cheers,
        Holger

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

Re: Moving away from (unsupportable) FusionForge on Alioth?

Sergio Durigan Junior-2
In reply to this post by Boyuan Yang
On Sunday, May 14 2017, Boyuan Yang wrote:

> 在 2017年5月14日星期日 CST 下午3:04:26,Pirate Praveen 写道:
>> As far as I understand, the only thing that is blocking is non
>> availability of pagure package.
>>
>> So helping fix this would help move this forward (currently pagure tests
>> are failing).
>>
>> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829046
>>
>> After we have the package, then DSA standard processes for new service
>> would follow, I assume.
>
> I'm a little bit confused. The bug forwarding address in #829046 points at
> http://git.sergiodj.net/, however I couldn't find packaging for pagure
> anywhere. Seems all deleted sometime before.
Hi guys,

I have recently-ish moved my private things to another server, and I
think the pagure repo got lost somehow.  I'm currently out of town but
I'll fix this as soon as I get back, next weekend.

> The repository on collab-maint stops at September 2016 and lacks the work
> around December 2016.

I wasn't really using the collab-maint repository because I haven't
created it, but I can move the latest version of my repo there.

On Sunday, May 14 2017, Pirate Praveen wrote:

> On ഞായര്‍ 14 മെയ് 2017 08:20 വൈകു, Boyuan Yang wrote:
>> I'm a little bit confused. The bug forwarding address in #829046 points at
>> http://git.sergiodj.net/, however I couldn't find packaging for pagure
>> anywhere. Seems all deleted sometime before.
>
> I don't know why Sergio does not want to create a stable repo at alioth.

It's not that I don't want.  It's that this is my usual workflow when
packaging things on Debian: I do everything on a local git repo, and
then move to collab-maint when the package is ready.

>> The repository on collab-maint stops at September 2016 and lacks the work
>> around December 2016.
>
> Sergio,
>  Can we finalize on collab-maint and not resetting history for every change?

Sure.  I'll move everything to collab-maint as soon as I get back home,
as I said earilier.

>> Could you tell me where can I find the proper packaging repository?
>
> I have pushed my copy here
> https://git.fosscommunity.in/praveen/pagure
>
> It was originally at git://git.sergiodj.net/debian/pagure-new.git

Thanks for doing that.

--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

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

Re: Moving away from (unsupportable) FusionForge on Alioth?

Alexander Wirt-2
In reply to this post by Boyuan Yang
On Sun, 14 May 2017, Boyuan Yang wrote:

Hi,

> I am worried about the status of FusionForge (and thus the development workflow
> around Alioth) for Debian.
>
> Recently I had a discussion on #alioth @OFTC asking for the possibility or
> plan of upgrading alioth.debian.org from Wheezy to newer Jessie or Stretch. We
> know Wheezy *is* EOL now with extended LTS support till 2018/05. One of the
> admins ("formorer") said things won't change till Wheezy LTS EOL since
> upgrading will surely break fusionforge and **no one** can fix fusionforge
> after that. The last person who touched FusionForge is Roland Mas (in CC
> list). In my understanding that means fusionforge is already in an
> unmaintained state even for now.
>
> Wheezy LTS EOL will arrive within one year. After that the unavailability of
> Alioth will surely break everything around Alioth: the Alioth account system,
> Git/SVN/CVS repository and web interfaces, alioth maillist and so on. Debian's
> development workflow will just break down. And I believe people will not accept
> a platform with security holes as one of Debian's basic infrastructures.
>
> As a result, I'm writing to suggest we find an answer to such a problem soon.
> Migration to Jessie or Stretch with new FusionForge version might be possible.
> Or we should just drop outdated FusionForge and move to some modern platforms
> like GitLab (with an alternated workflow possibly).
>
> There are much room for discussion but we should start evaluation without
> delay, since migration would take much time and the time left is pretty
> limited.
Here are my two cents and current plans:

I don't think alioth as it is has a future. It is too overloaded, a bad
software base and not well maintained (I am sorry for that).

I think that we should move the relevant services into new hosts/services. In
the first step that would be:

Must have:

- Account management - I am thinking about using freeipa for that
- Git Hosting - we want to give pagure [1] a try, which uses gitolite, which is a
  nice git solution. Regarding Hooks, no, we don't want anyone to use
  arbitrary hooks. This is just opening a (security) can of worms. But we
  want to provide hooks as a service. Pagure also has issue tracking.

Nice to have:

- SVN / CVS Hosting (SVN as there a still a lot of users and CVS for webml)
- Mailinglists

Things I/we don't want in the future:

- Shell Hosting
- More or less obsolete Version Controlsystems, like Darcs, Bazar and so on.

We should strip down the future set to a working and maintainable minimum.

Just my 2 cent

Alex - Alioth Admin

[1] https://www.freeipa.org/page/Main_Page
[2] http://pagure.io

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

Re: Moving away from (unsupportable) FusionForge on Alioth?

Boyuan Yang
In reply to this post by Sergio Durigan Junior-2
在 2017年5月14日星期日 +08 下午6:39:22,Sergio Durigan Junior 写道:

> On Sunday, May 14 2017, Boyuan Yang wrote:
> > 在 2017年5月14日星期日 CST 下午3:04:26,Pirate Praveen 写道:
> >
> >> As far as I understand, the only thing that is blocking is non
> >> availability of pagure package.
> >>
> >> So helping fix this would help move this forward (currently pagure tests
> >> are failing).
> >>
> >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829046
> >>
> >> After we have the package, then DSA standard processes for new service
> >> would follow, I assume.
> Sure.  I'll move everything to collab-maint as soon as I get back home,
> as I said earilier.
That would be great.

> >> Could you tell me where can I find the proper packaging repository?
> >
> > I have pushed my copy here
> > https://git.fosscommunity.in/praveen/pagure
> >
> > It was originally at git://git.sergiodj.net/debian/pagure-new.git
>
> Thanks for doing that.

I took a look into pagure packaging (both upstream latest version 2.14.2 and
Debian packaging version 2.6+dfsg from the git repo above) and things look
like a nightmare. Under Debian Testing and Debian Unstable, current packaging
did not create a working database for unittests. If we create db manually
(before dh_auto_test) and run unittest again, things can fail severely (around
60+/290+ units fail, not just 5).

Hence it would be great if anyone familiar with Python2 and Flask could help
improve the status of pagure packaging.

--
Boyuan Yang

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

Re: Moving away from (unsupportable) FusionForge on Alioth?

Jonathan Dowland
In reply to this post by Holger Levsen-2
On Sun, May 14, 2017 at 10:29:10PM +0000, Holger Levsen wrote:
> If we had this GR in say, a month, projects would have almost a year to migrate
> their stuff away nicely, and 18 months to do it a bit more painfully.

I can see the attraction of this, and it would certainly be easier to get
project consensus around factual stuff like that than the issue of having a
single, project-blessed, infrastructure-hosted replacement, but without such a
replacement being in-place, we will have a diaspora of projects and packages
going to all sorts of different places, which would be a disaster IMHO from
a contributor-complexity POV.

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

Reply | Threaded
Open this post in threaded view
|

Re: Moving away from (unsupportable) FusionForge on Alioth?

Jonathan Dowland
In reply to this post by Ben Hutchings-3
On Sun, May 14, 2017 at 10:06:06PM +0100, Ben Hutchings wrote:
> git: 18907
> svn: 2377

^ how many of these are from teams (like pkg-gnome, at one point at least) who want
to switch to git but lack the time or person-power or motivation to perform the task?

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

Reply | Threaded
Open this post in threaded view
|

Re: Moving away from (unsupportable) FusionForge on Alioth?

Jonathan Dowland
In reply to this post by Alexander Wirt-2
On Mon, May 15, 2017 at 09:13:11AM +0200, Alexander Wirt wrote:
> Nice to have:
(snip)
> - Mailinglists

I've always thought it a bit weird, unfortunate (and possibly a historical accident)
that we have lists.debian.org and lists.alioth.debian.org. Could this be an opportunity
to move to one Debian mailing list service?

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

1234 ... 9