:: Re: [devuan-dev] Devuan Releases - …
Góra strony
Delete this message
Reply to this message
Autor: Jaromil
Data:  
Dla: devuan developers internal list
Temat: Re: [devuan-dev] Devuan Releases - discussion on policy and process

quick checks on points raised:


On Mon, 24 Apr 2017, Daniel Reurich wrote:

> * we had not agreed on the set of minimum viable product requirements
> for the release nor assigned the responsibility for who should make the
> call on each of those requirements state of readiness.


we did, in weekly standups. but its true there is a certain difficulty
in getting everyone to share the same priorities, so this can be
definitely improved.

> a) amprolla needs 24 hours to merge latest changes from /devuan
> b) apt-mirror runs 4 times a day, but should be run again just before
> building the iso.
> c) iso building needs to happen after a) and b) are verified to have the
> neccessary changes.
> d) populating the iso mirrors takes about 6 hours.


perhaps we should streamline this so that once a) is triggered then b)
c) and d) cascade without any interference and the release is declared
ready.

> We also need to consider a process that:
> a) identifies release critical issues


we have that. we may want to have devuan specific weekly standups.

> b) allows sufficient time to develop a resolution or mitigation for each
> of the release critical issues.


or have a clear process to transfer the issues when they cannot be
processed by the same person, which I suspect will be a major effort
coming up with new developers. of course we are talking about critical
issues, as non-critical can be postponed or made low priority


> c) ensures that their is consensus on whether proceed with the next
> stage in the release process.


this needs to be more structured, yes


> d) verify the output of each stage to ensure that we haven't lost any of
> the work on the way (ie: making sure that the packages have reached
> /merge before running apt-mirror and building the iso images.


also this was done but not in a structured way and things slip

> e) validate the built iso's before mirroring.


we have tested them all of course, but validation of the signatures
and shasums is missing . I'm already working on a server-side script
for this.

> f) mirror the iso's & seed the torrents etc


parazyd is in charge of torrents and can do them well, yet I have
repeated to everyone we don't make torrents for RCs as I agree we'll
come out with a new one soon and a final release also.
The torrent will be there for the final release.

> g) Make the release announcement.


this was done properly this time. its a very good announcement

> There are other issues, like who should be involved in the release
> decisions and on what areas of responsibility.


another one is to map all the infrastructure and responsibilities and
access on that. I can do that as well. it will follow also a mapping
of standing issues with migrating infrastructure services, we have
quite some planning ahead and that should be fun. many lessons were
learned and as usual... less is more (yes i'm referring to gitlab..)

also do we want a central place where to keep a kanban board with
tasks? we can setup a new odoo installation dedicated to devuan. I
think that may be beneficial to keep track of what and when.


thanks,
ciao