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
>>