A new skein - reason and rationale
Clint Savage
Last night after troubleshooting a github issue for the nth time related
to skein's import functionality, some thoughts started popping into my
head. Ivan and I got to talking about the flow and functionality of what
skein is currently doing and how that really doesn't align with what
we'll be doing a year or two from now.
While this discussion was prompted by the inability to allow non-owners
to assign the newly created repo to a team, a support request later
confirmed that this functionality would not be coming to github anytime
soon. Even though I sent the request for more granularity (I think it's
a good thing for github at some point), I figured it wasn't something
they would be able to fulfill right away anyhow.
So Ivan and I started tossing around a new way of thinking about skein.
One that would allow for growth within the community, flexibility and
scalability for building packages and the ability to easily build a
trust mechanism. Essentially, the new skein is not only a longer term
goal for the distro, but a better way to help build community meritocracy.
That said, I would like to explain the new skein. While this is still in
draft form, I thought it important to get written down so we could use
it as a good starting point. So here goes:
1) skein request <repo> - For each new bit of source from upstream,
skein will create a new repository. In addition, skein will file a
github issue within this repository requesting access to push to the
repository. An email will be sent with the initial filing of an issue
along with daily emails to the administrators (owners on github) of any
outstanding requests.
2) skein admin query - Searches a list of repositories (or all) in the
organization and returns any outstanding requests for access. This can
only be performed by users who are considered owners of the gooseproject
organization on github.
3) skein admin grant - Upon a successful query for outstanding requests,
repositories will be added to certain teams. At the moment, the teams
will be 'Admin' and 'Builders' to allow easy management and the ability
to push updates for future building.
NOTE: An additional 'query-grant' (aka cary-grant) functionality may be
useful to find and interactively grant access as appropriate.
4) skein extract - This will extract all of the sources, patches and
.spec file from the srpm and place them in an appropriate location on disk.
5) skein upload - The source archive (tar.{gz,bz2}, zip, etc.) can be
pushed up to pkgs.gooselinux.org for use in our lookaside cache.
Essentially saving space in our git repository, and following good
practices of not putting binaries in repositories. Previously, sources
could be uploaded at anytime, however, I'd like to restrict access until
repository push access has been granted.
6) skein push - The spec file, patches and any scripts (which might be
included as sources in the srpm) will be committed to a local repository
and pushed to the now-writable remote github repository.
7) skein import - This is actually a combination of skein extract, skein
upload and skein push described above.
It is possible that most of this could be turned into a web interface,
with a simple dashboard to show the state of any repo, builds and allow
for requesting and granting access to repos and the lookaside cache.
This process will likely slow down our current progress but will improve
our workflow overall. As a user requests and imports more and more
repositories, they will gain trust with the administrators. An
administrator can then grant desiring users the ability to 'cary-grant'
other users. This helps to provide the 'build a path and get out of the
way' concept, which enables less resistance in accomplishing goals.
In the meantime while the new skein is being built, I think it justified
to allow all those who are importing srpms to be able to accomplish this
goal. With permission from Derek, I'd like to promote both Ivan and Mike
to owners of the organization (temporarily) so they may do the work
needed to get imports working.
As I consider things that need to go into skein, there are many
corollaries to Fedora's fedpkg. I think though, that there is still
enough difference for us to cherry-pick functionality as needed, and
still have a very strong codebase.
There are other components of skein which also need to be completed,
such as the 'build' functionality to simplify the koji build process.
I hope the motives are clear and well thought out, but I'm sure there is
room for improvement. During my short discussion with Ivan regarding
this, he came up with a few things that made these tasks clearer and
more complete. If you have something to contribute, please, please,
please, reply and make your desires (aka feature requests) known.
Cheers,
Clint
Derek Carter
> In the meantime while the new skein is being built, I think it justified
> to allow all those who are importing srpms to be able to accomplish this
> goal. With permission from Derek, I'd like to promote both Ivan and Mike
> to owners of the organization (temporarily) so they may do the work
> needed to get imports working.
+1
Awesome idea for the new skien(2.0?)
--
Derek
Clint Savage
> On 8/3/11 2:17 AM, Clint Savage wrote:
>> In the meantime while the new skein is being built, I think it justified
>> to allow all those who are importing srpms to be able to accomplish this
>> goal. With permission from Derek, I'd like to promote both Ivan and Mike
>> to owners of the organization (temporarily) so they may do the work
>> needed to get imports working.
>
> +1
>
> Awesome idea for the new skien(2.0?)
Glad you like it. Currently we're at 0.2 and 0.3 is hot on it's heals,
but I think it's probably appropriate to have a 1.0 branch and keep this
code separate since things are going to be very different for skein in 2.0.
Thanks for the encouragement!
Cheers,
Clint