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.

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

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.

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

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

-- 
 _ _     We are free to share code and we code to share freedom
(_X_)yne Foundation, Free Culture Foundry * https://www.dyne.org/donate/