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
>


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