On Thu, 5 May 2016, Kus wrote:
My original thought was to allow us to grant many people commit access.
This is a good policy question to bring up.
Linux Kernel, with MANY more contributers than OpenWRT/LEDE has one person with
commit access.
Admittedly, Linus is paid to do kernel work full time, so there is a good
argument that if you don't have someone doing the merges full time, you need to
have a small group of part-timers instead.
But with git, why do you need to have a lot of people with the ability to update
the core? they can all run (and publish) their own tree(s) with whatever work
they are doing.
The kernel has various people who do this, and they have someone running a tree
that combines all the pending work until the next merge cycle starts, etc.
Which also brings up the question, what is the workflow that LEDE is planning?
is it to merge patches continually until close to release time? or do you plan
to have regular cycles where you merge patches for a bit, stabilize things, and
repeat?
I'm a huge fan of the latter. It doesn't need to be a strict time-based approach
like some projects do, but everywhere that I've seen take this approach has seen
both more stability and more change.
David Lang
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
