On Tue, Jun 04, 2019 at 04:29:11PM -0400, fsmithred wrote:
> 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.
Therefore I included that when a task is to be picked up by someone, or
if someone wishes to discuss it, they should simply start a thread on
devuan-dev@.
> Meanwhile, what should I be telling people who are having problems with the
> repo?
Currently, it's my fault that I am not reporting all the things I do. I
understand this and I'm trying to create a workflow that will help us in
avoiding this in the future.
When all is said and done, all of us should easily be able to find
enough information on the mailinglist.
> 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
I will try to go through this tomorrow. It's getting late in this part
of the world.
::
Re: [devuan-dev] Request for organi…
