[oi-dev] Discussing maintainers visibility in oi-userland

[n]

I know this sounds ridiculous, from a security researcher who has had 
every version of dropstat and dropttdb.c for the entirety of archs and 
os's running them:

CDE is back and re-released with a (better but likely still broken 
codebase).

Grab the source maybe if you can afford to just firewall all RPC and X, 
etc...

I always liked the exploit lurid found in sadmind, not one of the silly 
overflows, but the AUTH_UNIX bug.  I counted several overflow exploits 
during the time that was private.

n at mod.net



On 2017-05-12 01:10 AM, Till Wegmüller wrote:
> If we talk bigger components like XFCE i would say that this is pretty
> much how we are handeling them right now. We only take in these when
> we know that a Contributor is able to support them over a period of
> time. Otherwise we leave try to put stuff like this into SFE or pkgsrc
> where there are people (and buildservers) providing packages for many
> things.
> I would say that this seems the way to go with the bigger Components.
> 
> 
> ---
> Greetings
> Till
> 
> On 12.05.2017 09:27, Dariusz Sendkowski wrote:
>> In my opinion, the current system looks fine.
>> Having a maintainer per component could be a nightmare for both 
>> maintainers and contributors. Maintainers are usually bottlenecks for 
>> various reasons no matter how hard they try not to be.
>> It could slow down the whole process significantly. Right now, it 
>> seems to run pretty flawlessly.
>> 
>> But how does it work for big and complex components (like desktop 
>> environments)? Should they be rejected due to the lack of the 
>> contributor's maintenance guarantee?
>> When I look at the contributors' list I see that people appear and 
>> disappear and that's a natural process.
>> This implies that nobody can guarantee that they will maintain 
>> components they add (I mean the bigger ones).
>> 
>> 
>> 
>> 2017-05-12 6:22 GMT+02:00 Alexander Pyhalov <alp at rsu.ru 
>> <mailto:alp at rsu.ru>>:
>> 
>>     On 11.05.2017 22:13, Peter Tribble wrote:
>> 
>>         On Thu, May 11, 2017 at 6:56 PM, Aurélien Larcher <
>>         aurelien.larcher at gmail.com 
>> <mailto:aurelien.larcher at gmail.com>>
>>         wrote:
>> 
>> 
>>             The question raised is whether we should formalize a
>>             maintaining process
>>             for some important components or groups of components.
>> 
>>             At some point I joked about a campaign going like "Adopt a
>>             package".
>> 
>> 
>>         There are downsides to having a formal owner: they can become 
>> a
>>         bottleneck, and it might discourage others to contribute in an 
>> area
>>         where there's an individual (or individuals) listed. Also,
>>         people may be
>>         reluctant to contribute if there's a prospect of being 
>> lumbered with
>>         the responsibility going forward.
>> 
>>         But, if you can avoid that, then there are benefits to having
>>         what we
>>         would call "Subject Matter Experts" for components or groups. 
>> Having
>>         someone who is reasonably familiar with the component, 
>> preferably
>>         someone who uses it, is useful as a source of help and advice, 
>> and
>>         having a list of such people and their specialities would be
>>         useful to
>>         other contributors.
>> 
>>         Putting such a list on display would also show that OI wasn't 
>> just a
>>         one or two person effort, which would be good.
>> 
>> 
>>     Yes, this idea seems reasonable. BTW, recently github started
>>     suggesting reviewers
>>     and it does it rather well.
>>     ---
>>     System Administrator of Southern Federal University Computer 
>> Center
>> 
>> 
>> 
>>     _______________________________________________
>>     oi-dev mailing list
>>     oi-dev at openindiana.org <mailto:oi-dev at openindiana.org>
>>     https://openindiana.org/mailman/listinfo/oi-dev
>>     <https://openindiana.org/mailman/listinfo/oi-dev>
>> 
>> 
>> 
>> 
>> _______________________________________________
>> oi-dev mailing list
>> oi-dev at openindiana.org
>> https://openindiana.org/mailman/listinfo/oi-dev
>> 
> 
> _______________________________________________
> oi-dev mailing list
> oi-dev at openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev