~alpine/devel

[alpine-devel] answers on commits to aports

Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20170915101742.36f47db8@ncopa-desktop.copa.dup.pw>
Sender timestamp
1505463462
DKIM signature
missing
Download raw message
Hi,

Some answers on the questions I got on IRC.

> 17:36 <foxkit> 1) what is the process when there is a version bump or
> fix required for a package that has a Maintainer: that is not one's
> self?  do you poke them first, send an email / message?  is there a
> timeout (after x time, just do it anyway)?  do they need to be
> Signed-off-by or Reviewed-by or Acked-by or similar?

The original idea was to have an acked-by like process for those, but
for minor fixes or minor upgrades we can just push.

What I would like is a way to tag pull requests (or email patches) with
a "maintainer update" tag or similar. That way we could fast-track
those patches.

> 17:37 <foxkit> 2) is there a 'staging' branch or similar where
> packages can built for all arches before being sent to master?  I'm
> especially concerned about arm (which danieli is going to help with)
> and s390x, and I don't think there is even qemu for s390x that
> functions (at least, not last I checked).  I do not want to submit
> packages to master that break on any arch.

The only thing we have is travis. You can create a PR on github and
travis will build it for you. However, it will only build on x86_64 so
its not that helpful. There is work in progress to get a ppc64le CI
hooked up to github.

What we have done is keep an eye on http://build.alpinelinux.org and
#alpine-commits on freenode to see if the build breaks on some arch.

I want avoid a staging build before pushing to master because some of
the builds take long time (gcc, kernel, llvm etc), specially on armhf.
I don't want to slow down the process by building those twice.

> 17:38 <foxkit> 3) is there a QA process or review, where someone else
> is required to review a commit to master before it is pushed?  i.e.
> it takes two devs to commit?  are there times where this is
> unnecessary (like security fix)?

We only review non-committers pull requests, and we are struggeling to
keep up. Most commits are trivial, minor version bumps, and those can
just be pushed.

For more complicated changes you can create a pull request on github or
send a patchset to alpine-aports@lists.alpinelinux.org ans ask for a
review.

> 17:40 <foxkit> 4) do we have clear guidelines about the movement of
> packages from testing to community?  maximum time in testing looks to
> be 6 months; is there a minimum?  if it passes build on all arches,
> and runs correctly on some selection of them, is that when it is
> moved?

The original idea with testing repo was to prevent "it works when I
build it on my machine" situations. So you could create a new package,
have the official builder build it for you, and then you could test
that it actually works. If it is verified to work when build on the
build server, and it is verified that it is packaged the way it should,
then it is fine to move it to community (or main).

The testing repo has also served as a "wip" repo. A user may have
requested some server package. A developer have packaged it, but not
tested it. By pushing to testing repo the user who asked for the
package can verify that it actually works. I have pushed "early"
packages there, which miss init.d scripts and similar.

Before moving to community or main the following needs to be verified:

- the packaging is done correctly. (files are installed where they
  should and not in something like /usr/usr/lib/)

- there are working init.d scripts if needed (is the name of the init.d
  script good?)

- reasonable subpackages are done if needed (are the subpackages naemd
  properly?)

- there is a maintainer specified in the APKBUILD

- the package as been verified that it actually runs on at least one
  architecture

- verify that dependencies are met. Things in community can not depend
  on things in testing. Things in main cannot depend on things in
  commuity or testing.

- there is a working (or almost working) default config 


When it comes to the default config, this is what I want from a default
config:

- Use upstream default config if possible

- If not possible, then try keep it close to upstream

- Use patch against upstream default if possible instead of shipping
  your own config file. This makes its easier to track changes in
  upstream default config on upgrades.

- Use a safe default config. For example, its good to listen to
  localhost only as default. Use common sense. For example, it would
  not make sense to ship default sshd which only listens on localhost,
  but it may make sense to disable password logins in default config
  and require ssh keys.

- the default config should make it easy to verify that a service
  works. For example, it should not be needed to spend an hour to
  configure a service to be able to debug a broken init.d script.

> 17:41 <foxkit> for instance, let us take simple package xpdf.  let us
> say it isn't packaged, and I put it in testing.  it builds on all
> builders and I read a book on x86 and armhf and ppc64le.  is it ready
> for community at that time?

yes, as long as it does not have any dependencies in testing and have a
maintainer.

> 17:42 <foxkit> 5) I know that commit msg standard is "repo/pkg: what
> happened".  but is there any other standard formatting to note?
> integration with redmine?  does a commit "Fix #xxx" or "Fixes #xxx"
> or "Close #xxx" or "Closes #xxx"?

fixes #xxx

If the issue has target stable (target 3.6.3 for example) and you push
the fix to git master, then use:

ref #xxx

Otherwise it will be marked as resolved in issue tracker and we will
forget to cherry-pick it to the stable branch.

When we do the cherry-pick we change the "ref #xxx" to "fixes #xxx".

Thank you!

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Reply to thread Export thread (mbox)