Salixmeetfeb2013

Salix Online Meeting (17 Feb 2013)

Proposed agenda

(Or rather what we tried to address in this first session. What is left of the original proposed (huge) agenda has been moved to Salix next agenda)

• fredg : All decisions have to be taken by a vote. If and only if there is a trouble the final decision has to be taken by gapan
  (natural leader by meritocracy)
• fredg : Need of a "road map" (what - goal - who - when - ...)
• fredg : How to better balance workload
• fredg : New team members introduction (mimosa, jaysaye, ...)
• mimosa : Testing department / coordinator; a graphical tool based on Lilosetup to configure fstab
• akuna : Also, we don't have to work out everything in one single big meeting, better to have more regular get-together with some
  common short term goals and meet more regularly. That way if someone cannot make it one time, it doesn't really matter
  since he can probably be there the following time. So could we work on some short term goals: What do we want/need to
  accomplish this next coming month/weeks ?
• jrd : No more than 200 packages (or another number determined together) by packager. Limit responsibilities per person for not putting all the eggs in one only basket. If, at one point, we have more packages that packagers can handle, I propose those to be put in hour source repository as SLKBUILD waiting for other packages to take the responsibility on them later.
• akuna : To build on the idea of a maximum number of packages, what about a minimum number of packages too? It is no secret that I do not relish packaging and have tried to stay clear of it as much as I could. Nonetheless, if all members of the team, no matter what else they do, could be responsible for a minimum of say: 10 packages or even 15 packages, it would be sustainable for each one while still account for an important chunk of the packaging when put all together.
• mimosa More frequent meetings (or more regular, not quite the same thing) seems a very good idea. Have the meeting before there is trouble not after. Any rules shouldn't be too rigid. There is room for one or two contributors who create no packages or loads. It could work as an informal guideline: if someone's packages creep up, delegation could be encouraged; those with none could be offered help. You don't want a situation where someone wants to do Maté or whatever and can't because of a rule; or if you have 199 packages and want to meet a user request. In particular, Salix currently has two packagers over 200 and needs all hands on deck. By the way, I bet Akuna is better at packaging than me ;) Some mechanism for transferring packages to a new maintainer? Otherwise new recruits will generally just add more new stuff. Not that that's a bad thing ...

Participants

Active participants

• Akuna
• didier_spaier
• djemos
• fredg
• gapan
• JRD
• laprijns
• mimosa

Meeting minutes

• It showed we had not met in a long time... we were quite a lot of people, many talking about different subject at the same time. Therefore it will be difficult to resume it perfectly and some bits may be missed. If you were there and you notice an important point has not been transcribed, do feel free to correct and/or complete.

We did not quite follow the original agenda...

• At the very beginning of the meeting, we decided not to follow the original agenda but rather clear the air immediately so that we could move on and be able to work on our priorities for the next few weeks until we meet again.
• It was decided to forgive and forget the harsh words that were exchanged after the 'repo incident' while not forgetting the lessons we could learn from it so that such a situation wouldn't happen again.
• We basically agreed that if anyone (and that means everyone) wanted to implement some important change, they should first inform the rest of us on the ML. If no consensus would form, as last resort gapan would take the final decision.

Our organization - How to better balance Salix workload

• Akuna pleaded for more defined and structured departments that would clarify and decentralize the workload.
• Mimosa suggested a deputy in each area, so that if someone is out of the picture, someone else could step in.
• Fredg remarked that if someone failed on a job, it didn't automatically meant that gapan had to take care of it.
• Gapan objected that it was all talks and talks (again) but than nobody was doing the work.
• Quite a few voices from our user base were heard on the ML recently, when they realized that Salix needed help, and they offered their contribution. If some, like before, may not act on their words, some others, like before also, may prove to be a great help.
• As a first step we invited laprjns and mimosa (who both accepted) to join the team in a more official capacity. laprjn who is already largely invested on the packaging front will help fredg and gapan to test and push packages and slkbuilds on the repos while mimosa, will help setup some testing procedure for our isos and utilities, he will also get involved with LiloSetup development as a learning process.
• Akuna will try to recruit more volunteers and setup some departments to further spread the workload and structure some routine (like the new ISO and utility testing, but also the translations)

Packaging

• Djemos reminded us that the repo and the packaging came first, without the repo and the packaging there would be no Iso, then no LiveCD and so on.
• JRD asked whether in some instances we could allow binary packages to be added to the stable repo...
• gapan: you don't mess with it, unless you have to
• laprjns98: i can understand being closed for version upgrades, but i don't understand why it closed to new packages
• fredg: for packaging, I think that we have to advertise that the slkbuild repo is not close
• So the status quo ATM is that new packages can always be added, even after the stable binary repo has been closed, but not as binaries, only in the form of slkbuilds. Let's not forget (that bit was not actually said during the meeting) Sourcery manages slkbuilds with basic dependency management.
• Of course, the binaries used in official Salix versions that are still to be released (like the KDE version...) will be added to the official stable repo (That is obviously a case of 'have to').

Our priorities for the next few weeks

• Testing the KDE beta that djemos is working on releasing.
• The Live CD, JRD is putting the finishing touch on an alpha iso featuring the updated installer which will both need plenty of testing.
• Rework LiloSetup (Akuna) which must be finished to be included in the coming Live CDs, it will also need plenty of testing.
• Set up the 'isos and utilities' testing procedures (mimosa)
• Clarify some slackbuilds vs slkbuild policies (fredg and laprjns)

Noteworthy quotes from the evening

• gapan: What went wrong? nobody does what he says he'll do
• didier_spaier: (Well... shared by Didier but really from Ann Landers)This is a story about four people named Everybody, Somebody, Anybody, and Nobody. There was an important job to be done and Everybody was sure Somebody would do it. Anybody could have done it, but Nobody did it. Somebody got angry about that because it was Everybody's job. Everybody thought Anybody could do it, but Nobody realized that Everybody wouldn't do it. It ended up that Everybody blamed Somebody when Nobody did what Anybody could have done.
• mimosa: Salix will solve its bottleneck/workflow problem by i) recruitment ii) more management structure NOT by cutting anything

Other points of interests

• tsuren has provided JRD with some Mac hardware so that progress can be made on the EFI booting
• didier_spaier is working (unofficially) on internationalizing Slackware's installer.

In conclusion

• gapan: My thoughts are: we'll see. If any of that works out, it would be nice.

And that sums up our February meeting. Let's see how much of this 'talk' will be put into practice within the next few weeks. We have agreed to have more regular work meetings so we should meet again in March, at least some of us. It won't be possible for all of us to always free ourselves at the same time, but we can all contribute to what will be discussed at the next meeting.