[Dev] Goals/direction for the coming year

[Luke]

On 03/31/2017 09:50 AM, Luke Shumaker wrote:
> Hi guys,
>
> I though we should maybe have a conversation about where we want
> Parabola to go.  What goals we have.
>
> 1 year is an arbitrary length of time that is long enough to
> accomplish bigish things, but is still short-ish term.
>
> These are things burning a whole in my head
>
>  - Reproducible builds
>

+1. For a slew of reasons. As you already mentioned, there are packages
with missing dependencies. However, there are also packages from Arch
where the maintainer is a non-responsive shill and admits to not having
the current PKGBUILD match the current build, packages that only
download from HTTP and have 'SKIP' as the hash check in core, etc. It's
a complete disaster.

I'd like to think that once we get a build server we can actually try to
see if it is possible to get a working/functional system using packages
built entirely by ourselves. This will involve compiling the compiler as
well, something I tried to do and gave up when I figured out all the
dependencies have to be built essentially at the same time, which means
trusting untrust from upstream, not just trusting trust.

>  - Build server
>
>    This is important for reproducible builds, and for i686 support
>    after November.
>
>    In addition to all of the normal build server things, I think this
>    should borrow techniques from reproducible-builds.org; use
>    disorderfs and such.
>
>    It is my understanding that we have one physical server being
>    dedicated for this task.

Hardware portion of the build server is in the works, but we really need
well-documented software / automation tools to do this.
If anyone wants to take this seriously and work full-time I think we
should be able to use Parabola funds to make it happen, this needs to be
professional work if we're going to maintain a quality build server.
>
>  - Code reviews
>
>    So this one is tricky.  It requires community buy-in.  I'd love to
>    see "mandatory" code reviews on every code and infrastructure
>    change we can viably do that for.  This is NOT primarily to catch
>    mistakes.  This is more to make sure that at least 2 humans know
>    about every change that is made.

+1. We need more eyes on the code. I don't like blindly trusting new
developers, and I don't like most of the PKGBUILDs from upstream either.
I've seen some pretty undocumented hackish stuff. Thusfar most (all?) of
the core team we have is solid and has had other devs vouge for them,
but if we're going to grow this needs to be made a priority. We also
don't need to be giving newbie weekend warriors access to sudo, I was
under the impression this was not happening. =-O

>
>  - Better bug tracker 
>

I'm a big fan of GitLab and Bugzilla, both are fairly simple to figure
out and work well in self-hosted environments also.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20170331/653dfc02/attachment.sig>