On Wed, Jul 18, 2018 at 1:30 PM Paul Belanger <[email protected]> wrote:
> I'd actually like to hear more thoughts from the SF team here, so far > we've only > gotten TristanC and mhu. Please take a moment and reply within the next > week. > I'm not part of SF team but I wanted to share some *personal* experience. It's a bit long but my TL;DR is "I see a lot of good things in this thread and I believe you're going into the right direction". I've only seen good intentions in this thread and it's a pretty good sign that things will move on in the right direction. I've been working on OSP (OpenStack productized by Red Hat) and things haven't been always green on our side... I remember a few years ago when most of the repositories had a bunch of custom patches whereas now we are nearly close to zero for most of them (at least on the projects I'm working on now). I also remember the reasons why we had these patches, and how we changed ourselves, please let me share it: 1) Most of the time a bug or a feature has to be fixed / implemented for "yesterday". Deadlines are what they are, the only thing we can do sometimes is say "no, we can't do it for this release". I believe over time we have improved on breaking down the features, prioritizing the bugs, so we could do a better job at planning, based on the capacity and the things that need to be done. 2) Downstream patches are expensive to maintain. I've seen a bunch of times where people saying "It's quicker to prototype downstream, ship it and then figure out how upstream wants to do it". (Note that I don't say SF is doing it right now, this is just an example related to this thread that I've experienced.) By doing this way, it creates a technical debt to maintain (and only ourselves can maintain it since it's downstream), while things are being figured out upstream to see how this feature can be implemented. A waste of time and resources, just to ship something quick. 3) Upstream-only developers only are unicorns! IMHO we can't be either downstream-only or upstream-only etc. We are building a product, based on Open-Source projects that we agreed to use and contributed to. Our job is to make sure we can sell this product therefore bring the features into the projects that we use. It involves: - Planning with Product Management (downstream mostly) - Discussions, Design, Planning with the project team (upstream community) - Implementation (upstream) - Productization (packaging, containerization, custom testing, etc) (upstream + downstream) - Ship to customers (downstream). I've learnt that to work in a successful team, everyone in the team can be involved in these different areas and spread the load. I also believe that we are all able to wear different "hats" when it comes to doing X or Y to achieve a goal. 4) Knowledge is the key, share it. Encourage individual mentoring, pair programming, collective bug triage, regular reviews/demos, etc. Share your knowledge with your co-workers, we should have SPOFs in the team, I think anyone is able to contribute when training happens. I hope this was useful, at least I wanted to share that. Feel free to ignore this email though. Good luck for your discussions and I sincerely hope you'll find ways to solve your problems, we all love Software Factory :-) Cheers, -- Emilien Macchi
_______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
