Posted here: http://pandorawiki.org/Firmware_governance
We need to get a backup for djwillis (atc?) and notaz (urjaman?) .. we've already suckered in Ivanovic and sebt3 for libpnd (the fools!)
I'm rather thinking that we're all overloaded, but spreading things out will make all our lives better.. while also making submissions easier and faster. Win win!
This is a early cut of the page; let me know or just make changes as you see fit :)
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
On Tue, Feb 22, 2011 at 5:46 PM, Jeff Mitchell skeezix@skeleton.org wrote:
Posted here: http://pandorawiki.org/Firmware_governance
We need to get a backup for djwillis (atc?) and notaz (urjaman?) .. we've already suckered in Ivanovic and sebt3 for libpnd (the fools!)
Well I think I can deal fine with < 1 patches per month, if you don't mind I'll keep kernel keys to myself (for the time being at least).
Gražydas
Posted here:
http://pandorawiki.org/Firmware_governance
We need to get a backup for djwillis (atc?) and notaz (urjaman?) ..
we've already suckered in Ivanovic and sebt3 for libpnd (the fools!)
Well I think I can deal fine with < 1 patches per month, if you don't mind I'll keep kernel keys to myself (for the time being at least).
On the same line,
As I have never actually had a patch for the firmware outside of the core team I am not in a rush to hand commit access out. Esp. as I am trying to find the time to work on things again.
That said, I have no problem with building up the teams but I would rather look to spread the maintainer load with do'ers in time not just for the sake of it or based on a small number of patches, esp. when you take into account the burden of pushing things up to mainline and reworking accordingly (something Grazvydas and I often do).
With the caveat that I am not sure we need lots of maintainers, just a core maintainer/gatekeeper for each area (after all we are not exactly talking about a massive upswelling of developers all of a sudden) I am broadly happy with the governance page.
I would like to expand it suggesting that patches are send to this mailing list as GIT style diffs but that may just be me (I find mailing lists, patches and something like that combined with Patchwork http://ozlabs.org/~jk/projects/patchwork/ can work very well). Maybe that is just me however, forums and the like are a burden to review off-line, emails are not ;). Comments?
Regards,
John
Hi,
The problem here was, that you 2 was hard to get in touch. Sure notaz had only a few patches and was fairly reactive with them. But John, you were unavail for more than 3 months. No offence here : RL is by far more important, but still, that holded a bit the project. (I do have softwares waiting to have eglibc to be packaged up. I asked you for direction to help you getting the merge in shape earlier and got no response :( ) Now that the pandora is finally shipping, we will have a greater audience. A large part of the current/futur owners are linux geek, so I expect to get more patchescoming than we had until now. The idea of having a backup is to allow everyone to have a real life while not holding the project. I greatly respect your abilities, and I agree that the champion of each area should be the gatekeeper (when he is available).
So in that respect, even I get git commit right, I wont commit a .bb files, but will send them to you (DjWillis) for reviews (and dont expect me to ever touch the kernel : far away of my league :D)
We had many flame war about the project gouvernance on irc, and many though it was hard to get patches in. For sure having a mailling list for that is a good step in the right direction.
Cheers, sebt3
2011/2/23 John Willis John.Willis@distant-earth.com
Posted here:
http://pandorawiki.org/Firmware_governance
We need to get a backup for djwillis (atc?) and notaz (urjaman?)
..
we've already suckered in Ivanovic and sebt3 for libpnd (the fools!)
Well I think I can deal fine with < 1 patches per month, if you don't
mind I'll
keep kernel keys to myself (for the time being at least).
On the same line,
As I have never actually had a patch for the firmware outside of the core team I am not in a rush to hand commit access out. Esp. as I am trying to find the time to work on things again.
That said, I have no problem with building up the teams but I would rather look to spread the maintainer load with do'ers in time not just for the sake of it or based on a small number of patches, esp. when you take into account the burden of pushing things up to mainline and reworking accordingly (something Grazvydas and I often do).
With the caveat that I am not sure we need lots of maintainers, just a core maintainer/gatekeeper for each area (after all we are not exactly talking about a massive upswelling of developers all of a sudden) I am broadly happy with the governance page.
I would like to expand it suggesting that patches are send to this mailing list as GIT style diffs but that may just be me (I find mailing lists, patches and something like that combined with Patchwork http://ozlabs.org/~jk/projects/patchwork/ can work very well). Maybe that is just me however, forums and the like are a burden to review off-line, emails are not ;). Comments?
Regards,
John
Firmware-dev mailing list Firmware-dev@openpandora.org http://openpandora.org/cgi-bin/mailman/listinfo/firmware-dev
Yes, I agree, we don't want to throw anyone out or replace him, just trying to get something organized so users can help with development as well. Also, some users complained they want to help but can't - this should now be history. Whether many will help out now is a different question, but we'll see that :)
aTc is now working on OpenEmbedded stuff, so he might be able to help out with some recipes if need be, but of course, he should do that together with DJWillis, who should stay the main here :)
Someone is also working on an enhanced xf86-tslib-input driver for the Pandora, supporting pressure and fixing the remaining bugs (since right click, i.e. still is terrible on the current OS :D)
It should make things for them and us easier to supply us with patches or even recipes :)
The problem here was, that you 2 was hard to get in touch. Sure notaz had only a few patches and was fairly reactive with them. But John, you were unavail for more than 3 months. No offence here : RL is by far more important, but still, that holded a bit the project. (I do have softwares waiting to have eglibc to be packaged up. I asked you for direction to help you getting the merge in shape earlier and got no response :( ) Now that the pandora is finally shipping, we will have a greater audience. A large part of the current/futur owners are linux geek, so I expect to get more patchescoming than we had until now. The idea of having a backup is to allow everyone to have a real life while not holding the project. I greatly respect your abilities, and I agree that the champion of each area should be the gatekeeper (when he is available).
So in that respect, even I get git commit right, I wont commit a .bb files, but will send them to you (DjWillis) for reviews (and dont expect me to ever touch the kernel : far away of my league :D)
We had many flame war about the project gouvernance on irc, and many though it was hard to get patches in. For sure having a mailling list for that is a good step in the right direction.
Cheers, sebt3
2011/2/23 John Willis John.Willis@distant-earth.com
Posted here:
http://pandorawiki.org/Firmware_governance
We need to get a backup for djwillis (atc?) and notaz
(urjaman?)
..
we've already suckered in Ivanovic and sebt3 for libpnd (the fools!)
Well I think I can deal fine with < 1 patches per month, if you don't
mind I'll
keep kernel keys to myself (for the time being at least).
On the same line,
As I have never actually had a patch for the firmware outside of the core team I am not in a rush to hand commit access out. Esp. as I am trying to find the time to work on things again.
That said, I have no problem with building up the teams but I would rather look to spread the maintainer load with do'ers in time not just for the sake of it or based on a small number of patches, esp. when you take into account the burden of pushing things up to mainline and reworking accordingly (something Grazvydas and I often do).
With the caveat that I am not sure we need lots of maintainers, just a core maintainer/gatekeeper for each area (after all we are not exactly talking about a massive upswelling of developers all of a sudden) I am broadly happy with the governance page.
I would like to expand it suggesting that patches are send to this mailing list as GIT style diffs but that may just be me (I find mailing lists, patches and something like that combined with Patchwork http://ozlabs.org/~jk/projects/patchwork/ can work very well). Maybe that is just me however, forums and the like are a burden to review off-line, emails are not ;). Comments?
Regards,
John
Firmware-dev mailing list Firmware-dev@openpandora.org http://openpandora.org/cgi-bin/mailman/listinfo/firmware-dev
On Wed, 23 Feb 2011, Michael Mrozek wrote:
# Yes, I agree, we don't want to throw anyone out or replace him, just # trying to get something organized so users can help with development as # well. # Also, some users complained they want to help but can't - this should # now be history. Whether many will help out now is a different question, # but we'll see that :) # # aTc is now working on OpenEmbedded stuff, so he might be able to help # out with some recipes if need be, but of course, he should do that # together with DJWillis, who should stay the main here :) # # Someone is also working on an enhanced xf86-tslib-input driver for the # Pandora, supporting pressure and fixing the remaining bugs (since right # click, i.e. still is terrible on the current OS :D) # # It should make things for them and us easier to supply us with patches # or even recipes :)
chris_c seems a bit like squidge -- no focus, got a dozen hacks on the go at once, but throw the man into a mess and he'll come out with a nifty little solution in short order. Is that 'stop charging when pull' going to come to anything? Likewise, he's doing the ts pressure investigation .. I like him :)
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
Hi Sebastian/All,
The problem here was, that you 2 was hard to get in touch. Sure notaz had
only a few patches and was fairly reactive with them. But John, you were unavail for more than 3 months.
No offence here : RL is by far more important, but still, that holded a
bit the project. (I do have softwares waiting to have eglibc to be packaged up. I asked you for direction to help
you getting the merge in shape earlier and got no response :( ). Now that
the pandora is finally shipping, we will have a greater audience. A large part of the current/futur owners
are linux geek, so I expect to get more patchescoming than we had until
now. The idea of having a backup is to allow everyone to have a real life while not holding the project. I
greatly respect your abilities, and I agree that the champion of each area
should be the gatekeeper (when he is available).
So in that respect, even I get git commit right, I wont commit a .bb
files, but will send them to you (DjWillis) for reviews (and dont expect me to ever touch the kernel : far away of my league :D)
We had many flame war about the project gouvernance on irc, and many
though it was hard to get patches in. For sure having a mailling list for that is a good step in the right direction.
Sorry, I think you misunderstood what I was getting at, I have absolutely no problem with more people getting involved (it's REALLY great to see) and the project needs to grow without undue bottlenecks.
I am just a little unsure about creating a commit free-for-all in the main trees in the name of governance and moving the project forward when GIT lends itself to cheap branches and merges (and people are free to clone to things using services like GITHub and hack away and ask for public review of a branch or feature via this list). It's not like it is hard to see the origin of work with GIT and proper credit for work done is such a key tenant of open source.
OpenPandora was never about creating a massive fork from its mainline origin's and settling for long terms in-tree hacks (well never how I saw it), if that is the way we want to go we may want to clarify that. The project as it stands has a reasonable reputation for pushing stuff upstream, that is very time consuming (in-tree hacks are cheaper in resource terms I agree ;).
The public mailing list is a great step forward; it makes it so much easier to keep in the loop (IRC etc. is not really the place to make project decisions IMHO, just discussion). That said, I am sure I am subscribed to other OP mailing lists I thought public already ;). For the record I lump forums in the same place as IRC as they are difficult to consume when you're involved in a lot of projects (and our forums can be hard to consume in ideal conditions ;)).
I just favour getting people doing things and working on the project before we rush to expand commit access and add additional maintainers etc., I except we will need to grow and things will have to change but growing before we have actually seen the areas we need to grow and what does not work seems a little daft ;). Let's take this as a bit of a fresh start and see how we get on. Still, it's not really my call. I got involved in the governance debate when I stumbled across it by accident yesterday on IRC ;), no mails dropping hints that I may want to get involved or the like. I'll fall in line with the needs of the project and the way the majority wants to take it forward but I am sure has hell going to get my 2p down in black and white ;).
Regards,
John
On Wed, 23 Feb 2011, John Willis wrote:
# OpenPandora was never about creating a massive fork from its mainline # origin's and settling for long terms in-tree hacks (well never how I saw
here here :)
# I just favour getting people doing things and working on the project before # we rush to expand commit access and add additional maintainers etc., I # except we will need to grow and things will have to change but growing # before we have actually seen the areas we need to grow and what does not # work seems a little daft ;). Let's take this as a bit of a fresh start and # see how we get on. Still, it's not really my call. I got involved in the # governance debate when I stumbled across it by accident yesterday on IRC ;), # no mails dropping hints that I may want to get involved or the like. # I'll fall in line with the needs of the project and the way the majority # wants to take it forward but I am sure has hell going to get my 2p down in # black and white ;).
I don't think anything is actually changing per se (cepting my asking sebt3 and Ivanovic to be more formally involved, as opposed to winging it on the side) -- its a point of clarifying the documentation, to be more public, to help erase any perception that we're an old boys club sitting her jerking peoples chains. Now we can be sure -- yes, we are jerking peopels chains, but not about the firmware :)
Opening up wide commiters is not ideal; opening up a process so people can find the commiters is important. And if we need more, we can find qualified ones from those with proven track records in the patches.
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
Hi,
Opening up wide commiters is not ideal; opening up a process so people can find the commiters is important. And if we need more, we can find qualified ones from those with proven track records in the patches.
We should definately NOT open the GIT to ANYONE to commit. The core team should do that - that is the same team we currently had, though sebt3 should be added for scripting here in my opinion, as he's helping out and I doubt he will break something.
The remaining devs should send us the patches (or put them up on the bugtracker), unless we have someone where we really know he won't bork things (i.e. urjaman could be helpful here).
I think once .next has its first FINAL release (so, end of this week, muahaha ;)), we should stop developing for the old Zaxxon release, leave the GIT as is and .next should be the current official one.
On Wed, 23 Feb 2011, John Willis wrote:
# As I have never actually had a patch for the firmware outside of the # core team I am not in a rush to hand commit access out. Esp. as I am # trying to find the time to work on things again.
*g*
Warning, worked till 2am last night again; pager hell at work, no sleep here :) And now that we're being logged, have to speak nicer.. hmm :P
There've been a handful of patches for libpnd; not a lot, and not a number I can't manage.. but RL has kicked my ass in peeks on and off and a couple patches during those times had to sit around for a few days... which is fine; but strikes me that as we need more blood across the board, if we make the process 'more clear' and 'more efficient', its just a more welcoming experience. We always just assume everyone knows who we are and how to reach us, since we've been around so long loitering about; but with so many new faces to the fold, they actually don't, so maybe it seemed an impenetrable thing. So while things are 'fine', maybe we can make 'em easier.
Now we have 'a page' (woopee!), but hopefully we can get it or related to show up on seaches of the right type, so people will find more a simple process, names to contact, a place to discuss. And, with a bit of jobs spread out, maybe things will be easier for us, so we might be able to enjoy life a little more :P
# That said, I have no problem with building up the teams but I would # rather look to spread the maintainer load with do'ers in time not just # for the sake of it or based on a small number of patches, esp. when you # take into account the burden of pushing things up to mainline and # reworking accordingly (something Grazvydas and I often do).
If some tasks can be delegated, so you can work on the harder or more interesting bits? Or someone can work on the ugly challenging or tedious bits (like some of the moving to .next)? Just thinking if your time can be used for good bits you want to do, maybe it makes your life easier? Gotta admit, you've been burnt out for awhile now; I hope you've been to the pub and got some rest now though :)
Theres often quite a bit of discussion of 'pnd format 2', for next official firmware, so we can gab over stuff like that here, too; quite a bit of flamage in that arena. iso+zip (in addition to iso+raw+optional-raw), or bin-headers, or bin-loaders in kernel, etc; we've bandied them all around, but our conversations are all in IRC and lost, so new blood is asking same old questions etc.
# I would like to expand it suggesting that patches are send to this # mailing list as GIT style diffs but that may just be me (I find mailing # lists, patches and something like that combined with Patchwork # http://ozlabs.org/~jk/projects/patchwork/ can work very well). Maybe # that is just me however, forums and the like are a burden to review # off-line, emails are not ;). Comments?
git diffs, or regular per-file diff is fine in my books; git is pretty clever, so just whole files sent over can work as well (ie; git will figure out the diff plenty fine of course), so I'm not too worried. If theres lots of patches a hard definition woudl be needed perhaps.. orperhaps we need one early, so to get the ball rolling there. Doesn't matter to me.
jeffwreck
-- If everyone would put barbecue sauce on their food, there would be no war.
Hey Jeff,
If some tasks can be delegated, so you can work on the harder or more interesting bits? Or someone can work on the ugly challenging or tedious bits (like some of the moving to .next)? Just thinking if your
time
can be used for good bits you want to do, maybe it makes your life easier? Gotta admit, you've been burnt out for awhile now; I hope you've been to the pub and got some rest now though :)
Agree 100%, if we can get a team hacking on all this that is fantastic. Any comments I was making did not mean to belittle that. Making things easier and more transparent is always good (something OP has never really got right but in fairness a lot of other projects struggle as well).
To be honest the fact we are all ranting about this on a mailing list speaks volumes about the types of communication that seem to work ;).
Theres often quite a bit of discussion of 'pnd format 2', for next official firmware, so we can gab over stuff like that here, too; quite a
bit of
flamage in that arena. iso+zip (in addition to iso+raw+optional-raw), or bin-headers, or bin-loaders in kernel, etc; we've bandied them all around, but our conversations are all in IRC and
lost,
so new blood is asking same old questions etc.
Get that sort of talk here and just link wiki pages and forums to the mail list archives :). Also easier to point IRC newbies at a mailing list archive and tell them to read up.
This probably brings us round to the second major subject we need to tackle, what should be going into what, goals for .next, kernel, libPND etc. and when we want them to come together to form a nice release, should we have cycles or a 'when it's done' approach etc.. I'll send another mail on that so we can all start to flesh it out.
# I would like to expand it suggesting that patches are send to this #
mailing
list as GIT style diffs but that may just be me (I find mailing # lists,
patches
and something like that combined with Patchwork # http://ozlabs.org/~jk/projects/patchwork/ can work very well). Maybe # that is just me however, forums and the like are a burden to review # off- line, emails are not ;). Comments?
git diffs, or regular per-file diff is fine in my books; git is
pretty
clever, so just whole files sent over can work as well (ie; git will
figure out
the diff plenty fine of course), so I'm not too worried. If theres lots of patches a hard definition woudl be needed perhaps.. orperhaps we need one early, so to get the ball rolling there. Doesn't
matter
to me.
Yep, something is better than nothing, thinking about this over coffee, mandating anything other than 'use the mailing list for patches' seems overkill at this stage. Hell, if we get patches in any format it is better than none :D.
The GIT formatted ones are easier to forward around and CC etc. mind you as they are the conventions followed by the majority of the upstream projects we work with.
Regards,
John