Joshua Ferraro a écrit : >> imho, we need a "Release Maintainer" that will be responsible for >> deciding wether a patch has to be backported or not. > I like the idea proposed by someone, of having the release manager > 'retire' and take over as release maintainer; stepping aside for the next > release manager. So that would mean I'd be the release maintainer for > 3.0 ;-).
I've nothing against that personnaly. I'm just wondering whether you'll have the time needed for that. In fact, I think you're already doing too much things (LibLime CEO, translation manager, Release Manager, ...). sometimes, we need 4 or 5 days to have a patch applied (or rejected). Even if the amount of time needed will decrease, I just wanted to ask. Note that I don't apply for this role, as we (BibLibre) are already overwhelmed. We (BibLibre) hope that hdl will be able to dedicate a little bit more time in the next months for community role. For instance, the role of QA manager means almost nothing in real life. I'm sorry about that, we should speak of how to introduce the QA role in the git process. > This leaves open the question of who should be release manager of > 3.2. I believe Galen would be in the best position of all of us to take over > the role right now: > 2. he knows the code inside and out I agree > 3. he's demonstrated over the past months that he's very careful and takes > both MARC21 and UNIMARC concerns into consideration I agree > 4. he has vast experience with library standards I agree You can add 5. he's a nice guy always available on #irc & very community oriented. > 1. he only works on programming Koha, doesn't have to worry about any > business or other concerns That's the only point I have questions about. (see later in this mail) > Certainly up for more discussion, but those are the top reasons I believe he'd > be the best candidate for 3.2 RM. I don't see anyone else to propose atm anyway. >> As I said, 6 or 7 libraries here are running 3.0 live. All of them are >> happy with it. > Perhaps. However, do they use authority control? yes > Do they use IndependentBranches? yes > Do they use LDAP and SIP2? no. >> > e. a change to borrowers to support alternate IDs - RFC to come >> >> I definetly would not add that to 3.0 > well, if not added to 3.0, it will force us to put it live for several > customers, > who can't wait for 3.2 to have it. This will mean that LibLime customers won't > be running the exact code as the release. It's a lot of extra overhead for us > to maintain two branches, but perhaps it's necessary. > > Since the code is already mostly written, and will be heavily tested, I don't > see any harm in adding it. my experience show me 2 things : - there are *always* consequences you don't imagine when you code something. - that's the best way to never have a stable release. Look at your mails 5 months ago. You've announced that you'll just ad "this and that" (mail on koha-devel when releasing alpha or beta). Now you must add another feature for another customer. In 2 months, there will be another one. And you can be sure every addition will result in a new unstability. I bet whatever you want (for both new customer need & unstability) Some months ago, you told me "LibLime has decided to deploy only official version of Koha to hit customers". I was very happy with this news. I'm not sure anymore that i'm so happy. The risk, with this decision and the pressure your customers put on you will be to have no more a time based release or a feature based release, but a "LibLime Customer needs" based release. Which would be a real problem for our (BibLibre) business, and for the community as well. And, to say my deepest thought, I think this will result in never releasing a stable version at all. Releasing a stable version means "stop running". Another way to say that : you wrote you planned to release 3.0 in march, and 3.2 in june. aren't you planing in fact to release directly the 3.2 in june (I mean a version numbered 3.0 with all the features you planned to include in 3.2 previously) On the other hand, having a LibLime version of Koha and an official version will be a shame as well, as I understand you don't have so much ressources to put on doing things twice & maintaining 2 releases. My feeling (as BibLibre CEO), is that there are 2 cases : - very time pressuring customers : have a specific release with the feature they want without waiting for an official release. And include in the proposal the fee to reintroduce the feature in official version later. - other consumers : be cheaper, and tell them the feature will be available in version X, that will be ready in Y months. That's how we plan to do for our 3 large projects I spoke of in my previous mail : the features will be in an independant git branch, that we will synch in koha official asap, but after the customer deployment. (and the git repo being available to anyone interested. The git repo with the new acquisition module -announced here in january- should have been opened for weeks now, but I couldn't find time to do it. sorry & shame on me) >> > f. changes to support linking icons to authorized values >> I definetly would not add that to 3.0 > Done already. It was the counter to the itemtype icons added a while back. > Most > US libraries find item-type icons to be useless. They are more > interested in linking > icons to bib-level information like audience, format, etc. I agree it has already be done... And it has broken something !!! Authorized_valued can't be edited anymore. hdl has submitted a patch yesterday if I don't mind. sorry to be hard on that, but almost everytime we add a feature those times, we introduce some kind of unstability ! >> > g. cleaning up names of system preferences, to do as a single DB update >> I definetly would not add that to 3.0 > I think we could negotiate on this point. However, I'll just point out > that if we > delay this change until 3.2, all of the 3.0 libraries will have to > learn a whole new > set of vocabulary for system preferences -- it could be pretty confusing. I agree on the point you point. But I think it's less important that going to stability. And i'm also really sure it's impossible to fix that without introducing many problems. Really sure -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
