On 09/05/16 23:10, hellekin wrote:
> On 05/09/2016 01:58 AM, Daniel Reurich wrote:
>> Hi,
>>
>> I just want to start setting some targets for the Beta2 release and
>> a timframe. (I have some requirements that related to other
>> projects I am working on, but nevertheless will be welcome in
>> Devuan anyway as they will solve issues for other people).
>>
>> This list is my personal wishlist, so feel free to suggest other
>> changes or deferrals, add your name where you'd like to help.
>>
>
> I can't think of any additions besides completing already open
> issues.

Cool
>
> We need to choose how to handle milestones:
>
> 1. Either we reuse existing 1.0.0-beta milestone 2. Or we create a
> new one: 1.0.0-beta2 and reassign issues from beta milestone to the
> new milestone as needed.
>
> I'd go for 2. as it keeps the milestone and progress history.

Agree'd
>
> The new milestone must be created as the group level so it cascades
> to all projects. The following groups should have this milestone:
> devuan-packages, devuan-for-review, devuan-infrastructure,
> devuan-editors, devuan.
>
> Probably the open issues not reassigned shouldn't be closed either.
>
>>
>> Packages to be forked:
>>
>
> Should we setup a protocol for this? I would think the following:
>
> 1. developer packages program in their own git (maybe on git.do).
It's better for existng 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.

> 2. package builds successfully. Developer opens an issue in
> devuan-for-review pointing to their repository
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

> 3. package release team and users review the new package
and release into jessie & ascii [-updates][-security]

>
> (would it make sense to overlay the devuan-for-review packages into
> experimental?)
I see devuan-for-review as being somewhat superfluous...
>

>> sane-utils     [centurion_dan] lightdm        [unassigned] gvfs
>> [centurion_dan] - needs workflow for importing from svn

>>
>> network-manager [centurion_dan]
>>
>> Packages to be updated/fixed/completed
>>

>> desktop-base            [centurion-dan] clearlooks-phenix-purpy-theme
>> [centurion-dan]

>
> I still have a leafy green "Jessie" boot screen after grub has
> kicked in. Is this covered by these two packages?
hmm no need slim fixed for this too so adding...

slim [centurion-dan]
>
>> devuan-cd (forked from debian-cd) [centurion-dan]
>>
>
> 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.

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

Most likely will end up as a package.
>
>> amprolla to use diff changes to avoid re-processing the entire
>> packages [nextime]
>
>> bugtracker server [unassigned]
>>
>
> I think the task here would be to integrate Gitlab and Reportbug.
> I'd like to talk with the Gitlab people and see if they share this
> interest.
First get reportbug working and then worry about integration.

>> popcon server - website [unassigned]
>>
>
> 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.


> == hk
>

D

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