[Top][All Lists]

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

Re: Guix package incubator (later a channel)

From: ng0
Subject: Re: Guix package incubator (later a channel)
Date: Tue, 7 Feb 2017 20:37:16 +0000

On 17-02-07 12:59:22, Christopher Allan Webber wrote:
> Pjotr Prins writes:
> > On Mon, Feb 06, 2017 at 09:44:48PM +0000, ng0 wrote:
> >> Just a reply on the notabug question (I don't have much time otherwise):
> >> Notabug will eventually move to an instance of, you can read
> >> about this in their own issues where I asked about some question back
> >> then (no link, sorry .. my name was 'ng0' back on there). Developing
> >> with pagure might be easier (fedora and surrounding communities)
> >> compared to the situation they describe in the issue.
> >> I started packaging pagure for this reason, which is about ~85% done
> >> (services + pagure itself left to wrap it up ... pagure itself is more
> >> or less done, just the service are needed. I'm more than happy to pass
> >> this on (could rebase the pagure patch), as I know I have taken on some
> >> tasks which would be better handled by different people :)
> >> That is in case you want to use a GuixSD as a host, otherwise you should
> >> not have many problems.
> >
> > That would be a great result :). Also pagure looks very interesting -
> > simpler than gitlab. I like simple.
> It does look good:
>   Open data: Sources, doc, ticket and pull-requests meta-data are
>   available in the web interface but also in git repos which can thus be
>   cloned and changed locally.
> That's really appealing.

The only thing we found (not answered, but I didn't check so far with
pagure development team) is that issues and pull requests are read-only
git repositories. Maybe our short trip into pagure was too short to
answer this, but it looked like read-only, no push. One reason why I
want an local instance to play with so I can check wether my
feature-issues are really issues or just instance
configuration settings.
Also no trace of the "pull requests" across different hosted
instance of it, but that can be solved aswell later.

I agree with Pjotr, doesn't matter for now, might matter later.

ng0 --

reply via email to

[Prev in Thread] Current Thread [Next in Thread]