On 6/4/19 10:16 AM, Ivan J. wrote:
> On Tue, Jun 04, 2019 at 02:50:21PM +0200, Evilham wrote:
>> On dt., juny 04 2019, katolaz@??? wrote:
>>
>>> On Tue, Jun 04, 2019 at 08:18:54PM +0900, Olaf Meeuwissen wrote:
>>>>
>>>> Devuan has a GitLab instance. Why not use its issues? With a
>>>> suitable
>>>> set of priority labels and people assigning issues to
>>>> themselves, the
>>>> workflow would be pretty much the same as below.
>>>>
>>>
>>> I probably shouldn't intervene on this, but I guess past
>>> experience is
>>> useful in making decisions: the usage of gitlab issues to signal
>>> bugs
>>> and things to do was what effectively stalled and delayed Devuan
>>> Jessie release by more than one year and a half. The few
>>> developers
>>> had to cope with issues scattared all around the place, with no
>>> idea
>>> of what needed to be done in order to have the release ready.
>>> The
>>> turning point there was to have all the issues manually
>>> collected from
>>> all the different gitlab projects and collated (and tagged) into
>>> bugs.devuan.org. At that point we knew what needed to be done
>>> and
>>> worked for it. Jessie was released three months after that
>>> collation
>>> work was completed.
>>>
>>> IMHO gitlab issues work well only if you have many developers,
>>> each of
>>> them supervising just a couple of projects, and only those. In
>>> that
>>> case it is clear who should take care of which issue. If you
>>> have only
>>> a handful of people who need to do whatever needs to be done,
>>> all over
>>> the place, then a pad would be much more efficient, IMHO.
>>>
>>> Sorry
>>>
>>> KatolaZ
>>
>>
>> I mostly agree with this, which is why my original reply to parazyd was
>> going to be "LGTM" (quotes included).
>>
>> The quotes were because: yes, it solves some issues.
>> But Devuan is at a stage where organisation beyond that is needed, as
>> evidenced by Ralph's suggestions re: timestamps and so on.
>>
>> Quoting the relevant bits of one of my previous attempts that died in a sea
>> of silences:
>>
>>

>> #### Workflow, accountability and transparency
>>     [ ] Foster more availability/(close-to) real-time
>>     communication
>>     [ ] Create next week's pad immediately after finishing a
>>     weekly meeting
>>         --> This means we can use the pad over the week as a
>>         "brain-dump" space
>>         - (gl) This has not worked to date
>>     [ ] It has to be possible to know what is being worked on, by
>>     whom and which deadlines are not met
>>         (Evilham): I am very tempted to propose setting up
>>         redmine for the project...
>>                    It can help with many of these things. Better
>>                    alternatives are welcome.
>>     [ ] Discoverability of knowledge is an issue.
>>         Even a pad prominently linked from the main IRC channel
>>         can be missed:
>>         https://pad.dyne.org/code/#/1/edit/YakleTpFfQ9KHXt+ggqgSQ/BJYL0QHRoy9LmLEObTTKmzAH/

>>
>>
>> None of that is addressed in a "let's centralise tasks in a pad" approach.
>> But since it is better than the 'nothing' that there is right now and no
>> interest was shown in even debating something else, I go back to my original
>> "LGTM".
>>
>> Just stressing that accountability and communication of work on infra should
>> be priorities.
>>
>> All of this is of course just my opinion, take into account or don't; in the
>> end *something* gets done *somehow*.
>
> With regards to discoverability,
>
> it's why there is a single pad which should be checked periodically and
> takes a lot less effort than reading IRC backlogs, *various* mailing
> lists, forum boards, and scouring through different Gitlab projects.
>
>

A pad works well for a checklist of tasks. It fails for discussion.

Meanwhile, what should I be telling people who are having problems with
the repo?

Here are some notes I made yesterday, with links to prior discussions in
some of the various places you mentioned. Some of the problems have been
fixed, and there may be some that I didn't list.

Currently:

Using "stable" in sources.list stopped working a couple weeks ago
(according to EHeM in #devuan)
Using "ceres" no longer works. Using "unstable" does work.
There are differences in the directory structure between pkgmaster and
packages.devuan. I don't know if it's significant or not.
- The /merged dir in pkgmaster has no stable or testing but does have
unstable.
- The /merged dir on packages does have stable and testing, but they're
in a directory above the codenames. (or something like that.)


prior discussions:

March-May: No ascii-security updates.
https://dev1galaxy.org/viewtopic.php?id=2702

April 20: No updates in beowulf or ceres.
https://dev1galaxy.org/viewtopic.php?id=2800

April 22: Beowulf not updating:
https://lists.dyne.org/lurker/message/20190423.010257.c7732165.en.html

May 3: jessie-security not getting updates.
https://lists.dyne.org/lurker/message/20190507.110559.ecd37daf.en.html

May 6: In jessie, no updates with deb.devuan, yes updates with
auto.mirror. https://dev1galaxy.org/viewtopic.php?id=2831

May 27: Missing testing & ceres:
https://lists.dyne.org/lurker/message/20190527.072915.2cfceb79.en.html

May 28: Ceres has no Release file.
https://dev1galaxy.org/viewtopic.php?id=2877