Hi, On 06-03-18 23:27, Hector Oron wrote: > Sorry for my late reply, I took me a while until I bumped into your > email today. No worries, I am still quite busy with my other Debian project: autopkgtest integration in britney, although that is nearing its deployment. > 2018-02-26 14:28 GMT+01:00 Paul Gevers <elbrus@debian.org>: >> On 22-02-18 10:12, Paul Gevers wrote: >>> Technically my half year sabbatical leave has started last week. One of >>> the projects I put my mind to is to work on materializing bikesheds. > > Yay! The problem is not only technical, but it carries with it some > initial FUD or design proposal. > Some of the questions to answer with such FUD are: > - Who has access to bikesheds? The documentation that is already out there³, aims at DD/DM's. I don't have a reason yet to change that. > - What do we want bikesheds for? That document³ also gives multiple uses of bike sheds. My (not exhaustive) intentions are: - Library transition preparations (albeit experimental can be used for the same purpose, but now in isolation, thus enabling less conflicts and more time). Due to the isolation it can also benefit a lot from my autopkgtest/britney project. - Volatile packages that (for whatever reason) become obsolete well within a full release support period (and thus should not go to testing), but could be supported by multiple uploads during the support period of a release. Debian backports doesn't work for this purpose, as it only takes packages from the next release. - Staging area for security uploads that can receive a full fledged autopkgtest coverage run before moving to the real archive (requires the autopkgtest/britney project to be finished). > - Given the above replies, do we want as a project support that idea? My impression is that there is quite a bit of support within the project. (I acknowledge that that is not the same.) >>> I hope you can help me to get started, such that I can help you to get >>> this long standing idea into a working state. > > Which benefits bikesheds bring to you as individual? Do you mean *me*, or rather *the individual*. My main interest here is Debian as a whole. I believe there are quite some people interested in this feature. I like to work on these kind of items more than on individual packages as there is more of the eat-your-own-dogfood in it than my packages. The main purpose of my own computer is to work on Debian (as a hobby). >> @wanna-build team: Neil suggested that instead of hacking on >> wanna-build, you may be interested to switch to e.g. OBS²? Not sure how >> I can help with such a task, but I am willing to dive into it. > > I am among official OBS package maintainers and obs.debian.net DNS > owner, so I would not mind to push forward such idea with your > support, that'd be probably awesome. However I do not yet see official > Debian adopting OBS as their main wanna-build service, which does not > mean it cannot be done, but it is a lot of work and it also impacts on > several teams workflows. I absolutely don't want to push any solution. It is just something that Neil mentioned. I haven't looked into OBS (and wanna-build or pybuildd/buildd-py) to see what it does exactly. I merely wanted to point out that I don't want to shy away from fundamental changes if we *together* believe it will bring quality improvement or feature improvements that are worth it. > In summary, I see three different projects you could focus on: Great counting ;) > 0. Implementing bikesheds in current infrastructure > 1. Design bikesheds and discuss it's requirements I think that ¹ and ³ show that there is already an extensive design and a (partial?) implementation in dak. I think reviewing that to the current ideas and understandings is necessary, but let's assume it was well thought thru. > 2. Overhaul current infrastructure (leaving bikesheds out of scope) If this is a requirement for 1, I am more than willing to help. I assume you put the bikesheds in parenthesis due to your estimation of time (taking my sabbatical into account). Just to be clear, for me it is no requirement that the project is finished by the end of my sabbatical. To be fair I don't belief it will, whichever way. I am taking my learning from autopkgtest/britney into account (which also covered code over multiple places). That project is far easier as most code was already there from Ubuntu and still it takes 1.5 years. > 3. Setup and maintain OBS as debian.net service Can you elaborate a bit what you want to achieve with this if we are not going to replace wanna-build with it? > 4. Study and propose a design on how to replace wanna-build with OBS 3. as a requirement for this? > 5. Find something else and enjoy sabbatical As mentioned, I am still working on autopkgtest/britney integration, but that seems to be nearing completion. We are in the phase that we are already drafting the communication. After deployment, no doubt there will be issues, but my sabbatical has 2 purposes, and one is Debian. Rather these kind of impact projects than just updating my packages. Paul ¹ https://ftp-master.debian.org/users/joerg/dak.git/ ² http://openbuildservice.org/ ³ https://lists.debian.org/debian-devel/2013/05/msg00131.html
Attachment:
signature.asc
Description: OpenPGP digital signature