Hi Jaromil

PPA's are not a focus for Release, but ensuring that decisions we make
now would support being able to easily add them later is something I do
believe is important - particularly because it broadens our reach as a
distribution via derivatives and also as a potential way to produce an
income.

but yes point taken.

Regards,
    Daniel.

On 16/05/16 01:00, Jaromil wrote:
> hi,
>
> please do not consider open PPA service a todo item now!
>
> we have enough todo before serving random people an hard to maintain service for free. using our infra may be also a viable offer for paid membership
>
> however our priority is ship a stable 1.0.0 ASAP.
>
> ciao
>
> On May 9, 2016 4:31:56 PM GMT+02:00, Daniel Reurich <daniel@???> wrote:
>> On 10/05/16 02:17, hellekin wrote:
>>> On 05/09/2016 11:55 AM, Daniel Reurich wrote:
>>>>>
>>>>> I'd go for 2. as it keeps the milestone and progress history.
>>>>
>>>> Agree'd
>>>>
>>>
>>> To keep a bit of consistency, I'd like to stick to <version>
>> milestones,
>>> e.g., use: 1.0.0-beta2
>>>
>>> This way we can automate watchers, release notes, statistically
>> reports
>>> and such at each release. If that's fine I'll create (or rename) the
>>> existing group milestones.
>>
>> Great. Do that ;-)
>>>
>>>>>
>>>>> 1. developer packages program in their own git (maybe on git.do).
>>>>
>>>
>>> I'm thinking of a scenario with PPA, for which I think
>> devuan-for-review
>>> makes sense, as a community one-stop-shop for new packages. If
>> enough
>>> people want it and a package maintainer person or team can organize
>> from
>>> there it will make devuan-packages more solid in the long run. What
>> do
>>> you think?
>>
>> PPA's will be tied to user accounts - and they'll be able to build
>> against which ever suites take their fancy. Searching user accounts
>> will be easy enough to do, and Derivatives will be like PPA's but with
>> amprolla merge and mirrors as a bonus.
>>>
>>> Following up on your thought...
>>>
>>>> It's better for existing debian packages to be forked directly into
>>>> gitlab. And currently they can't build in our gitlab which is a big
>>>> part of the work.
>>>>
>>>
>>> Certainly the user build issue is important. Archlinux User
>> Repository
>>> is a great part of their success, apart from their genius wiki.
>> Forking
>>> Debian packages directly into devuan-packages make sense. There
>> needs
>>> to be a clear way to determine which package is part of which
>> release.
>>> Until now I had seen devuan-packages as the release group. But you
>>> suggest we make it more like a central repository for everything that
>>> make it to any suite, including experimental, if it comes from
>> Debian.
>>> I understand that the branches will hold information about release
>> and
>>> suites.
>>>
>> I see devuan-packages as the canonical source of all official devuan
>> packages in our distribution. Other groups beginning with "devuan" are
>> for non-package projects like policy and web stuff.
>>
>> For a derivative we'd have a group named <deriv-name>-packages and
>> probably a <group-name>-project for there non-package stuff like
>> websites.
>>
>>>> If it's a fork of a debian package it should go straight into
>>>> devuan-packages. New as in not in debian packages should go to
>>>> devuan-for-review. However only archive maintainers can build into
>>>> jessie, ascii, *-updates and *-security. Package maintainers can
>> build
>>>> into *-proposed, *-proposed-updates and *-proposed-security
>>>>
>>>
>>> This is great information that should go straight into the Devuan
>>> Maintainer Guide.
>>
>>
>>>
>>>>> Anything related to Refracta's live CD scripts?
>>>> Nope. That's FSR's baby and if he want's to package it that's cool,
>> if
>>>> not that's fine too. It's nice to have a remix/derivative out there
>> as
>>>> well.
>>>>
>>>
>>> It wouldn't hurt to encourage him :)
>>>
>>>>>>
>>>>>> Infrastructure additions/upgrades:
>>>>>>
>>>>>> mirror master and push mirror scripts [centurion_dan]
>>>>>>
>>>>> Package mirror scripts?
>>>> yeah it will all be push mirror based. Those not wanting to
>> participate
>>>> in official mirrors can do what they like, but official mirrors will
>>>> need to use our mirror setup - we will have a feedback chain so we
>> can
>>>> track which mirrors are working.
>>>>
>>>
>>> Sweet. I'm working on a Devuan Mirrors page to instruct about
>> setting
>>> up Devuan Release Mirrors (files.do), Devuan Web Mirrors
>> (devuan.org),
>>> and Devuan Package Repository Mirrors (which depends on what you
>> wrote).
>>>
>>> WIP is at https://devuan.org/os/mirrors
>>>
>>> It will link to officially supported mirrors (as in: a provider
>> opened
>>> an issue and gave enough information to be listed there, and
>> follow-up
>>> with the issue--which is currently not the case for about half the
>>> mirrors listed on the homepage.)
>>>
>>>> Most likely will end up as a package.
>>>>
>>>
>>> :)
>>>
>>>> First get reportbug working and then worry about integration.
>>>>
>>>
>>> We need the email part of reportbug working first, right? Anyone up
>> for
>>> the taking?
>>
>> It needs to receive both email and http(s) reports (they're gpg
>> encrypted against our yet to be created popcon keyring)
>>>
>>>>>
>>>>> A Devuan-specific frontend for popcon?
>>>>>
>>>> Yup - Debians source should be easily reused for this purpose. I
>> think
>>>> the processing scripts are provide as examples in the
>> popularity-contest
>>>> package already - so it's just the frontend that needs to be
>> provided.
>>>>
>>>
>>> Let's follow up in popcon issues.
>>>
>>> Cheers,
>>>
>>> ==
>>> hk
>>>
>
> _______________________________________________
> devuan-dev internal mailing list
> devuan-dev@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-dev
>


--
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722