Le 25/02/10 22:33, Alexandro Colorado a écrit : > > > On Thu, Feb 25, 2010 at 11:56 AM, Charles-H. Schulz > <charles-h.sch...@laposte.net> wrote: > > Hi, > > > > > > > Ok honestly I am not sure what is the big issue. 3.1 was also > > > released > > under Pavel builds (#101415) and nobody really issue any flags. So > > 'switching' arrgument doesn't really apply here. > > that's the point: you either release it under Pavel's builds or under > the vanilla one. Pavel's builds are also fine, but they're not the same > and you need to be consistent. > > > > > I also don't see the bigger issue whenever we used pavel's build or > > vanilla. Most of the previous QA requirements was only about > > providing an MD5 which we did for at least the mylinuxclasses.com > <http://mylinuxclasses.com> > > windows build (since pavel don't provide them anymore). > > You don't see an issue with having people downloading the official OOo > version (at least that's what they think they're doing) from > "mylinuxclasses.com <http://mylinuxclasses.com>"? > > > mylinuxclasses.com is not a mirror, this was used so they could take the > build to the mirrors. Only one using this was for the release to the new > bouncer. No user will be dealing with this server. I am not sure why you > will think this.
OK, I understand now. > > > > > > > Most of the locale builds are also done in Pootle so there is really > > no fork or duplicate of efforts here, except maybe for a second build > > which didn't apply any updates to begin with. > > That IS be the problem. And the second build as you call it, which is > OOo's build, set the resolution of the bugfix to the 3.2.1. > > > So 3.2.1 will be ready for release, right now 3.2.0 is NOT. > > > > > Ihi decision to wait > > until 3.2.1 as opposed to apply them right for RC5 would have been > > the best answer here. But we work too much too quickly to end up with > > no build for 3.2.0. > > > look, you can't have everything for free all the time. Sometimes things > do not work exactly the way you want. In this case, I think you were > too late in proposing a fix or even alerting the release team about the > problem. It was at RC 5 level, not at beta stage. Don't expect > > miracles at that moment if you haven't done the least before. > > > > Are you saying I can't patch things myself? That is a ridiculous > statement for a FLOSS project. No I'm not saying this at all. You are free to patch pretty much everything in Free and Open Source Software. In fact you're even free to patch the Linux kernel, but it does not mean that 1) your patch will be accepted 2) the patch will be integrated as fast as you want if it is accepted. What we have here now is rigorously identical. You released a patch somewhere around the RC 5 (RC 5, again, not beta nor RC 1) and then you are surprised when you're being told your patch came in too late and that it will be included in the next micro-release (2.3.1). But that is not enough for you so you decide to switch builds. So in short, it's not about freedom: it's about following a community process. Not following such a process is ridiculous for a FLOSS project. Charles. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@native-lang.openoffice.org For additional commands, e-mail: dev-h...@native-lang.openoffice.org
