Re: let me help you with progressing bikesheds
Hello,
2018-03-07 18:25 GMT+01:00 Paul Gevers <elbrus@debian.org>:
>> - 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).
Fair enough
>> 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
Sorry, I would not qualify an extensive design one email wishlist³ and
some code¹ to publish packages.
Let's look at this from other angle, there is a working technology,
can wishlist³ fit there? Which changes are needed?
> 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
I rather meant "overhaul wb/buildd/dak architecture", it would be like
starting from scratch here, with modern technologies, modern
languages, etc.
Which kind of bring us up the next point, as something already exists
in this line of thinking.
> 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
right
> 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?
Heh... isn' it too early to replace wanna-build? Maybe in the long
long term, it can be considered.
When I am saying "OBS as debian.net service" I try to think that:
* OBS
+ It provides enough technology to be able to support some if not
most of bikesheds scenarios.
+ It reduces development time to nil.
+ It has enough flexibility to try to fit most of bikeshed dreamlist³
+ It does not involve debian.org FTP archive, nor DSA
infrastructure, nor wb database.
+ It already exists, let's try not to re-invent wanna-build to be
wanna-be-obs.
* debian.net
+ Service does not put more burden into official teams which IMO
are quite loaded.
+ Service maintainers are responsible for the server administration
and service maintenance.
+ Gives a pre-view of upstream OBS, which enables users.
+ We get some code running, users using it, then teams can focus on
using it and fit their workflows.
+ This would be the initial development, testing phase.
+ Later, we can discuss on how to proceed further into merging it
as debian.org
* service
+ Easily deployable code base
+ Codebase is easy to extend or adapt to Debian needs (or wishlist³)
In summary, I think OBS deserves a chance to be evaluated and worked
on. Nowadays it should be quite easy to setup and configure.
Blog posts (a bit outdated) if you are interested:
- http://collab.debian.net/portal/planet-debian/riku-voipio-deploying-obs
- http://collab.debian.net/portal/planet-debian/hector-oron-martinez-open-build-service-in-debian-needs-you
- http://collab.debian.net/portal/planet-debian/hector-oron-martinez-build-a-debian-package-against-debian-8.0-using-download-on-demand-dod-service
Presentation on OBS at FOSDEM 2018 if you want to have a look:
- https://fosdem.org/2018/schedule/event/debianopenbuild/
>> 4. Study and propose a design on how to replace wanna-build with OBS
>
> 3. as a requirement for this?
Exactly!
> Paul
>
> ¹ https://ftp-master.debian.org/users/joerg/dak.git/
> ² http://openbuildservice.org/
> ³ https://lists.debian.org/debian-devel/2013/05/msg00131.html
>
I do not want to drive you one way or the other, but if your ultimate
objective is support bikesheds, why not try if what's already out
there (OBS) can be made use (fit Debian workflows). Think on
maintenance costs (as in people/teams workload), think on
administration costs, think on QA costs, etc.
So, are you able now to propose a task list on which you would like to
focus and work on?
[ Consider adjusting CC line if you reply ]
Regards,
--
Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
Reply to: